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 : [email protected] Unsubscribe : https://launchpad.net/~syncany-team More help : https://help.launchpad.net/ListHelp
