syncany-team team mailing list archive

[Vincent Wiencek <vwiencek@xxxxxxxxx>]

On Tue, Dec 10, 2013 at 1:30 PM, Philipp Heckel <philipp.heckel@xxxxxxxxx>wrote:

> 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".
>

That's what I thought and I'm OK


>
> - 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?
>

Yes, native libraries (DLL+so) are included at root of swt jars.


>   + If so, can we compile them ourselves or do we have to put them in our
> repo?
>

No, natives libraries can be downloaded from mvn repositories through
gradle.


>
> - 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?
>

Fully means "no native lib" for me :)
For mobile GUI, I think we'll need dedicated iOS/Androids devs .... that's
why REST client is a good idea.


>
>
>> 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.
>

Ok great :)


>
>>  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 ]
>

Sure ; the idea of "floder watching panel" is to get a status of all
watched folders
ex :

       __________________________________________________________
       | home/userA/privateStuff     | watching (10 seconds)    |
up-to-date    |
       | home/userA/publicStuff      | watching (real time :) )    |
up-to-date    |
       | home/userA/projectAlpha   | manual sync                  |   *new
files*   |

 ------------------------------------------------------------------------------------------------------


>
>
>>  - 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.
>

Yes of course, wizard is a good 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?
>

You get latest file updates .... and info on update status ...

[image: Inline image 1]

>
>  Here is a quick example of a java swing GUI under windows, with jgoodies
>> look and feel.
>>
>
[image: Inline image 2]
This screen is pure Java / Swing for example


> 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?
>

Sure, do you know tools to do that ? screens drawing could then be added to
github


>  - 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?
>

Sure, it was a quick test to get update from daemon. Long polling could be
achieved through basic java threading. Not as elegant as callback .... but
I d'ont see how to do it an other way.


>  - 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?
>

Many options :
1/ in each plugin project, create a dedicated JPanel with getParameters()
function and instanciate it via GUI directly
2/ create add-hoc projects syncany-plugin-XX-gui ==> clean but these
project will only contain 1 or 2 classes ....

1/ or 2/ are OK for me.


>
> 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.
>

Yes, we should select "portable" LnL. Agree on Metal (had been designed for
sun workstations ....)


>  -  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" :-)
>

sorry ..... :(


> - I like the idea with the socket / port lock. Clever :-)
>

Thx, better than file locks.


>  - 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.
>

Yes, should do refactoring.


> - 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?
>

Google Event Bus (or other kind of bus) is a mecanisme to :
- send any kind of serialisable objects to the bus
- get notified when objects are received

example of code:

// Class is typically registered by the container.
class EventBusChangeRecorder {

  @Subscribe public void recordCustomerChange(ChangeEvent e) {

    recordChange(e.getChange());

  }
}
// somewhere during initialization

eventBus.register(new EventBusChangeRecorder());
// much later
public void changeCustomer() {

  ChangeEvent event = getChangeEvent();

  eventBus.post(event);
}

It is a very convenient pattern which allows to bypass callback/listener
pattern.

For example, we could define a WatchEvent object which could inform GUI of
status changes for a folder (pause / watching ....)

How can that be implemented ? syncany-core could have a EventBus class for
handling :
- creation of EventBus for the whole application
- registering / unregistering of listening classes
Then listening classes should just have to have @subscribe method for a
dedicated type and register to global eventbus.

 - I suppose the use of commands instead of operations was easier for now,
> but we shouldn't rely on any CLI-only stuff.
>

Yes sure, I realised that too :)



>
> Keep up the good work!
>

Thx

>
> Best
> Philipp
>



-- 
Vincent Wiencek
vwiencek@xxxxxxxxx