On Tue, Dec 10, 2013 at 9:21 PM, Philipp Heckel <[email protected]>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 [email protected]
-- Mailing list: https://launchpad.net/~syncany-team Post to : [email protected] Unsubscribe : https://launchpad.net/~syncany-team More help : https://help.launchpad.net/ListHelp
