syncany-team team mailing list archive

[Vincent Wiencek <vwiencek@xxxxxxxxx>]

On Thu, Dec 26, 2013 at 2:25 PM, Philipp Heckel <philipp.heckel@xxxxxxxxx>wrote:

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

I'm on it.

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

Fine for me, that's what I had in mind.
socket locking mechanism is a good portable way to detect whether an
application is already running.
Problem : probing port should be available ....

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

ok


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

Ok I understand.


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

Ok it makes sense :)

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

Yes I'm now using StackLayout to "switch" panels when user clicks on
previous/next button

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

We could avoid this 'in-between' project by using reflection to access
parameters stored in syncany-plugin-xxx-gui ....


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

I'll look at it


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

Vincent


>
> Best
> Philipp
>



-- 
Vincent Wiencek
vwiencek@xxxxxxxxx