syncany-team team mailing list archive

[Philipp Heckel <philipp.heckel@xxxxxxxxx>]

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)
  connectToDaemon()
  guiStartedDaemon := false
else
  startAndConnectToDaemon()
  guiStartedDaemon := true

*At shutdown:*
if (guiStartedDaemon)
  stopDaemon()


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

@Root(name="application")
class ApplicationTO {
  @Element(name="watchedfolders")
  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:
https://github.com/binwiederhier/syncany/commit/b30be7e07acb98b503157cd4efa52a2ba72317a2

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

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:
http://i.imgur.com/EpScmuI.png

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

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.

Best
Philipp