syncany-team team mailing list archive

[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