syncany-team team mailing list archive

[Philipp Heckel <philipp.heckel@xxxxxxxxx>]

Hello again,

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

So it's just another dependency in the build.gradle file? And the SWT
JAR contains the DLLs and SOs for different platforms? No need for any
extra Gradle fiddling?
If not, do you have example projects?

Looks like it though: http://stackoverflow.com/a/292799/1440785

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

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

Hm. To be honest, I don't see as part of an extra screen. It could be
part of the settings dialog, but the information shown in the dialog is
nothing that you cannot add to a tray menu, right?

Regarding the "realtime :)" hint: The latest WatchOperation does
realtime watching. It uses the Java7 WatchService to watch the folders
and triggers a sync. When the sync is done, it notifies other clients
via the pub/sub server. Or did you want more than that? :-)

> You get latest file updates .... and info on update status ... 
> (Screenshot)

Windows people always get the good stuff :-D
I'm just happy that my Dropbox syncs correctly ...

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

Oh I meant "Pencil", the wireframing tool. Here's a link:
http://pencil.evolus.vn/

It can do "native" windows, GTK stuff and also the "sketchy"
pencil-style windows. I like the "sketchy" style best because it really
focuses on the screenflow and what goes where -- rather than focusing on
the components and how they look.

Here's a screenshot I took: http://i.imgur.com/ZE5Agtb.png
>  
>
>     - 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.
I'm not sure either. I've asked a couple of people and there does not
seem to be a good technology for that. Gregor suggest WebSockets which
allow true two-way communication and I think it's a very elegant
solution too. The messages could be JSON-based. And it WebSockets are
supported by many languages already (inkl. pure JavaScript). WebSockets
Java library with examples: https://github.com/TooTallNate/Java-WebSocket

However, I'm not sure if that does destroy the clear contract of a REST
based API ...

Any thoughts?

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

You mean adding a FtpPanel to the syncany-plugin-ftp? This doesn't work
if we want to include it in a CLI-only deployment, because then the
plugin project must depend on syncany-gui, right?

> 2/ create add-hoc projects syncany-plugin-XX-gui ==> clean but these
> project will only contain 1 or 2 classes ....

I think that's the way to go, even though it's really odd ...
Let's do that.
 
> 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.
Interesting. I think we should definitely keep that in mind. Right now,
we have enough things to do :-)

Best
Philipp