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