← Back to team overview

syncany-team team mailing list archive

Re: GUI Feedback


Hello again,

... might be linked to SWT gui thread. Just like swing, SWT uses a
> dedicated ui thread to update UI independently of your business logic. But
> this works differently between osx/windows/linux. I've managed to make it
> work under mac osx through specific jam arg.
> I've installed virtual box with ubuntu to test it under linux.

Our first SWT issue :-)
I tried the -XstartOnFirstThread option under Linux, but it does not seem
to work (unknown option).

It sometimes happens under windows when an other instance of the
> application is still running.
> More globally I need to figure out best practices to work with Shell and
> Dialog .....
> I'm not as familiar with SWT than I am with swing, I still need to
> discover best practices.

Ok, cool. I just wanted to let you know that there might be an issue.

> - isn't it dangerous to run daemon on pure background ? we could imagine
> an other tray icon just indicating "sync any daemon running" + menu command
> to launch gui.

For pure user desktop experience its certainly not what a user expects, but
some people might want to use Syncany "headless" on a server, i.e. without
GUI. So both options must be possible.

So I think the GUI should (*at startup*, pseudo code):

daemonRunning := Check if the daemon is running (SocketLock?)

If (daemonRunning)
  guiStartedDaemon := false
  guiStartedDaemon := true

*At shutdown:*
if (guiStartedDaemon)

> - but sure if GUI starts dameon, then it should stop it / if daemon is
> already launched, gui shouldn't terminate it, or at least ask user to ?

No asking necessary, I think.

>>  *3.3. Storing settings: *"properties.txt": You're storing the watched
>> folders in ~/.syncany/properties.txt; it's probably easier to do it like
>> the the lib is storing the config (ConfigTO, RepoTO, etc.)
> - aren't gui application parameters linked to the application and not to
> the repository ? example : proxy settings if client is behind a proxy ?

Yes, of course. Maybe I wasn't clear. I meant you can use the SimpleXML
framework to store the application specific settings, because it's more
uniform to what the lib does with the repo settings. Something like:

class ApplicationTO {
  private List<String> watchedFolders;


- instead of property files, we can imagine dedicated h2 database with
> cyphered parameters (in order to hide proxy passwords for example).

I don't think we need a database for the global application settings. And
besides: One of Syncany's assumptions is that the local machine is a safe
place. Otherwise we couldn't store the master key or even the files we're
syncing/protecting unencrypted.

If the local machine was not secure/safe, we'd have to store everything
(including the actual user files) encrypted. And that wouldn't be practical.

 *3.4. SWT dialogs: *You always do a shell.dispose(); when switching to a
>> new dialog. Is this best practice? Because it creates a flickering on Linux
>> when showing the new dialog. Also, if the old dialog was moved, the new one
>> always appears in the middle of the screen. I know that's kind of a big
>> change, but is it possible to switch the panels inside a dialog instead of
>> the dialog itself? Or is that not best practice with SWT?
> Yes, flickering to on windows :) Need to find best practices to do it.
> I'll probably be ending replacing "items" in already built dialogs.

Isn't it best to just do one "WizardDialog" and put everything else in
"Panel" classes. Then the actual window stays the same, but you can
create/destroy the panels when you click next/prev/cancel...

>  *3.6. Gradle module "syncany-plugins-gui"*: Is there a reason for this
>> module? Couldn't you just move it to the main gui package? Anything I'm not
>> seeing?
> Yes sadly, the idea is the following to get clean design :
> - syncany-gui doesn't down anything about syncany-plugin-xxx and
> syncany-plugin-gui-xxx

Ok, at compile time, syncany-gui does not know anything, but at runtime it
could call Reflections.getSubTypesOf(..)

> - but to be able to query plugin panels, and get dedicated
> arguments/parameters, we need to have plugin panels implement a specific
> interface, contained in syncany-plugin-qui.

The PluginInterfacePanel (or whatever it's called :-)) could be included in
syncany-gui. Like so:

However, this "solution" does not compile the syncany-plugin-xxx in the
distribution, which is not what we want ...

- then syncany-gui and syncany-plugin-xxx-gui only depend on
> syncany-plugin-gui

I think I just realized what the separate plugin is for: to avoid circular

syncany-gui -> syncany-plugin-xxx
and syncany-plugin-xxx -> syncany-gui

This is not possible.. That's why you created the 'syncany-plugin-gui'
module. I get that now, and I think that your solution is better ...
Although it's a bit odd.

If you have any other ideas let me now. But for now, I think the
syncany-plugin-gui option is the best ...

> true. Linuw specific item:
- idea would be to have already resized clean png

I think resizing is not necessary for Linux (normal tray). All the other
icons are the same size and don't change when I change the tray size is
changed. Here's a screenshot with panel size 50:

Why should we adjust the size if the others don't :-)

However, at some point we need an Ubuntu-specific tray, because they
removed the tray support a while back (no tray visible). They now have "app

ok great.
> Idea : we should have a "passwordStrenghChecker" with all password
> constraints in util project no ?

Maybe. I think as long as we do not allow anything < 8 or < 10 we'll be
fine. No need for a special checker. But if you want this in the GUI,
there's no reason why you shouldn't show it.


Follow ups