syncany-team team mailing list archive

[Vincent Wiencek <vwiencek@xxxxxxxxx>]

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

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

I'm just saying that native libraries could a priori be downloaded as a
gradle dependency (I'll try to test it ...)

>
>

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

No sure, i'm just thinking that tray menu is not necessarily a basis pop-up
menu with menu items / separators. It can easily be a complex panel (see
previous dropbox screenshots)


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

no it's exactly what I though ... leverage on java7 file system hooks ....

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

great ...


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

or something like Hazelcast, which proposes observable maps / lists .....
You just need to register to map/queue changes ....


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

sure ...


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

ok


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

ok again :)


>
> Best
> Philipp
>



-- 
Vincent Wiencek
vwiencek@xxxxxxxxx