syncany-team team mailing list archive

[François-Xavier Michaud <fx.michaud@xxxxxxxxxxxx>]

Hi,

Perhaps should you study a solution like the Kivy framework for programming
the GUI ?
Kivy uses a easy and simple language (Python) and you can build real
applications for a various systems (Windows, OS X, Linux, iOS, Android...).

Best regards.

François Michaud.



2013/12/10 Philipp Heckel <philipp.heckel@xxxxxxxxx>

> Hi Vincent,
>
> thanks very much for taking the time so look at GUI options, and for
> prototyping a bit :-)
>
> As for today we've identified the following constraints for Gui creation.
>> The library we are going to use should be :
>> 1/ nice (obvious no ? :) )
>> 2/ as portable as possible
>> 3/ well integrated into a maximum number of environments (windows, linux
>> and OSX)
>> 4/ easy to use (as a developper)
>>
>
> All true :-)
>
>
>> - Java FX :
>>       * pros : new library, portable
>>       * cons : few components, not easy to integrate into existing build
>> systems (gradle / maven)
>>
>
> I don't have any GUI experience -- well with Swing a bit for the original
> Syncany client -- so please correct me if I'm wrong or I'm saying stupid
> things ...
>
> I remember Fabrice mentioning that JavaFX is not (yet?) fully open source,
> so that would be an additional con. However, I think the major issue is
> that it's not easily integrable with Gradle. So I vote "ney".
>
> - Eclipse SWT :
>>       * pros : nice (see eclipse), easy to use
>>       * cons : portable via dedicated os libraries (not too hard to
>> integrate into gradle/maven
>>
> - Eclipse Swing :
>>       * pros : nice (with extra Look And Feel), fully portable, easy to
>> use
>>       * cons : default System tray hugly (but can be overriden with
>> dedicated panels)
>>
>
> - From what I've seen so far, I like SWT a bit better than Swing, but
> that's not a strong opinion and can be easily overridden. What I like about
> SWT is that it actually uses the native components wherever possible while
> Swing draws its own components. For the user, that makes SWT feel more like
> a native application than a Swing application will ever do.
>
> - The system tray on SWT looks nice on my Linux Mint with Gnome3, but it
> there is no icon at all for Ubuntu with Unity (-> Unity needs special
> handling with its "appindicator" thing ...).
>
> - Obviously, that also means having to have native libraries with SWT, but
> you wrote that they are not too hard to integrate. Can you elaborate on
> these libraries?
>   + Do we have to ship DLLs/SOs in the final JARs?
>   + If so, can we compile them ourselves or do we have to put them in our
> repo?
>
> - You wrote "fully portable" with Swing? Does that mean "no native
> libraries" or "also on mobile"?
>    If it's the former, see above; if it's the latter, don't we need a
> dedicated GUI for mobile anyway?
>
>
>
>> I've not yet started to look at other non-java graphical libraries, and
>> any input on this subject is welcome !
>>
>
> Let's not make it more complicated than we already have and stick to those
> three (two) options :-)
> Unless someone suggests a Wunderkind, hehe.
>
>
>> Besides, we should have the following screens for the application :
>> - a "settings panel"
>>
> Yep.
>
>
>> - a "folder watching panel", from which we can "watch", "stop watch" any
>> local folder
>>
> Do we need this? SparkleShare does this entirely from the tray menu, and I
> actually like that idea. Something like:
>
> [ Private stuff ]
> [ Work stuff -> ]
>   [ Edit ... ]
>   [ Pause ]
>   [ Remove ]
> [ --- ]
> [ Settings ... ]
> [ Help ]
> [ Quit ]
>
>
>> - a "init" panel, with dedicated UI for each plugin
>> - a "connect panel"
>>
>
> Agreed. I initially designed it as a "wizard" (see screenshots on
> syncany.org). Do you think that's not necessary? Having all options on
> one panel might scare people away and not allow any explanations. Just an
> idea.
>
>
>> - a "main screen" accessible when right-clicking in icon tray (like
>> dropbox)
>>
> Hm? What happens when right-clicking the Dropbox icon? What should appear
> in this main screen?
>
>  Here is a quick example of a java swing GUI under windows, with jgoodies
>> look and feel.
>>
>
> General code / GUI stuff:
> - You've already done a lot of work, even though you call it "quick
> example". Do you think we should do some screen design with pencil first? I
> think that's crucial to good user experience, right?
> - Also: I think we should first talk a bit more about the GUI <-> daemon
> architecture and how they interact. I think the REST server in the daemon
> is fine, but I don't like the REST server in the GUI. I think the GUI
> should subscribe (long-polling via REST?) to the daemon, and the daemon
> should fire events. What do you think?
> - The Local/FTP/S3 panels are hardcoded in the gui package, shouldn't they
> be in separate modules? Like syncany-plugin-ftp-gui, etc.? Or is that
> overkill?
>
> To your example code:
> - The jgoodies stuff looks quite good on your screenshot, but really
> aweful on my Linux :-) It falls back to the ugly old Swing "metal" LoF. I
> realize this is just an example, so that's obviously not a big issue.
> -  It took a while until I realized that the "init screen" is not a
> working example, the getParameters() of the individual panels always
> returns "null" :-)
> - I like the idea with the socket / port lock. Clever :-)
> - I also like the general handling of the DaemonServer/Handler, handing
> off actions to "handle*()" methods. These methods could also be
> externalized in their own classes.
> - Can you elaborate on the Google Event Bus usage? As I understand, it
> just replaced regular Listener interfaces within a JVM, but it's not for
> communication between GUI and daemon, right?
> - I suppose the use of commands instead of operations was easier for now,
> but we shouldn't rely on any CLI-only stuff.
>
> Keep up the good work!
>
> Best
> Philipp
>
> --
> Mailing list: https://launchpad.net/~syncany-team
> Post to     : syncany-team@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~syncany-team
> More help   : https://help.launchpad.net/ListHelp
>
>