<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Hello Arnaud,<br>
    <br>
    On 01/05/11 15:26, Arnaud Versini wrote:
    <blockquote
      cite="mid:BANLkTinvEa4iGyO0HQnQa_hXoheW488K4A@mail.gmail.com"
      type="cite">I've tried this system with some problems :<br>
      <ul>
        <li>I can't build it, it needs some notable modifications before
          being usable with wxWidgets 2.8.</li>
        <li>this solution needs wxWidgets, I dont know if it's a problem
          but LibO download size increase with.</li>
      </ul>
      Is it the good way?<br>
    </blockquote>
    <br>
    Thanks for looking into it. Some points:<br>
    <br>
    1) I'm not at all sure WinSparkle is the way to go, given that it
    only works on Windows. Even if the work is relevant to Mac as well,
    given that WS is 'heavily inspired' by Sparkle, if it doesn't do at
    least *nix as well we're going to end up with parallel update
    systems. I think we should continue looking for a cross-platform
    solution for this.<br>
    <br>
    2) OTOH, I haven't looked into how Sparkle / WinSparkle work,
    particularly how they package updates. The appcasts concept sounds
    simple and elegant, which makes it smell technically attractive to
    me as well, so my only question mark is how updates as actually
    packaged / applied. IF, through study of the Sparkle / WinSparkle
    systems, it turns out that the same packaging / patch applying
    method could work on *nix as well, then maybe this could be a
    fruitful direction to go in.<br>
    <br>
    3) From my extremely limited knowledge of Wx, I know that it's far
    from monolithic. There are umpteen shared libraries that all do
    various bits and pieces. The problem Wx might pose would depend on
    what bits we need. I know there are 'low-level' Wx libraries that
    abstract system utilities-type stuff, which can be used entirely
    separately from any graphical libs. Depending on what WinSparkle
    needs one might be (should be?) able to do the GUI part using GUI
    components already in LO.<br>
    <br>
    4) There have been proposals of refactoring all GUI components out
    of LO and using a third party GUI library. Some people recommended
    Qt, for a variety of reasons I'd recommend Wx instead. It would be
    an ungodly huge job of course, but maybe the experience of tinkering
    with incorporating an external GUI lib with LO code would be
    profitable for future development.<br>
    <br>
    5) The other way to go is just examine how the (Win)Sparkle system
    works and emulate it using LO components. It'd be cross-platform
    because LO components are already. Again, the magic would seem to be
    in how updates are packaged and applied.<br>
    <br>
    ... make of that what you will :-p<br>
    <br>
    -r<br>
  </body>
</html>