genesis-devs team mailing list archive
-
genesis-devs team
-
Mailing list archive
-
Message #00031
Re: Account management [was: gtk.Builder migration]
Hi!
Am Mittwoch, den 02.12.2009, 23:17 +0100 schrieb David Castellanos:
> > I think it should be save to leave the title blank.
>
> Finally I've put it the title "Auto sync", because otherwise the user
> wouldn't know about the purpose of this column. It's a short title,
> the problem could be the different translations. Perhaps there isn't a
> title as compact as in English for some languages.
Hm, but I think one could live with the column getting a bit wider. So
we should go for that title.
> But I'm very very
> frustrated becaused I haven't found a way to center the checkbox in
> its column from Glade/GtkBuilder ¬¬. I know it's possible, because
> other apps like Pidgin has done it, but none of them uses Glade for
> that. I think it's going to be necessary to create the columns by
> hand...
I think (at least in theory) I found the place to activate that setting.
I attached a screen shot. It should work by editing the properties of
the cell renderer and setting the horizontal align to a fixed value
(instead of getting it from the model) by unchecking the checkbox.
In the glade view, it seems to work, but sometimes the actual result
behaves a bit different.
> > But I got one question concerning the effect of that checkbox: Does this
> > only affect automated syncs? Or does it also affect manual syncs using
> > the status icon?
>
> Mmm, no. My idea was to enable/disable the automatic synchronization
> of the account through this checkbox.
>
> > I currently had this behaviour in mind:
> >
> > * Clicking the status icon syncs all active (i.e., checkbox
> > checked) accounts.
> > * Automated syncs sync all active accounts.
> > * Sync button in the account manager only syncs the selected
> > account in the account list.
>
> It's seems fine for me, and quite reasonable. There are basically two
> ways to synchronize accounts, (1) via manual synchronization selecting
> the account in the 'Account Management' screen, and clicking in one of
> the 'sync' buttons, and (2) automatically. An automatic
> synchronization happens when the sync timer expires, or the user has
> explicitly requested an automatic synchronization by clicking the
> tray-icon or selecting the option 'Synchronize' from the tray-icon
> pop-up menu.
I got the impression that we only had naming differences: You call syncs
triggered by clicking the status icon also automatic syncs, I only had
timer-based sync in mind. :-)
But I think we agree regarding the desired bahaviour: The check box
affects the syncs via timer and status icon, the direct syncs in the
account manager are unaffected (because they only affect the currently
selected account, anyway).
> > But I’m not sure if this really is the best way to go. I might also be
> > worth thinking if one should be able to configure automatic sync
> > (intervals etc.) separately for each account.
>
> That would imply a timer for each account, and perhaps this effort is
> pointless when we will migrate to the new DBUS based backend. It is a
> very good idea, but it might be better to wait a little.
Yes, we could keep this in mind, but wait how things evolve.
I think the switch to D-Bus will make some things easier, but I tend to
wait until things really settled on SE’s side. Also, with the latest
changes the D-Bus API seems to be quite a bit more complicated.
> > Then the checkbutton in
> > the account manager would only affect the manual syncs via status icon.
>
> Mmm, I think I didn't understand you know :-S. At least for me, I
> think that a click on the button should always force an automatic
> synchronization for all accounts with automatic synchronization
> enabled.
See above, we have the same things in mind, only different naming.
> > GenesisConfig is sort of hackish, I agree. My idea was to access the
> > autostart settings like all other configuration properties, but that
> > turned out a bit tricky. Maybe that’s all not worth the trouble, and we
> > completely dump GenesisConfig. We could the go with a raw config object
> > and move the autostart methods/property to the Genesis main class.
>
> In lp:~davidcaste/genesis-sync/account-management I've extracted the
> GenesisConfig and PreferenceDialog to a new file, because genesis.py
> is too long, and was difficult to maintain because there were too many
> classes doing very different things.
Yes, that probably makes sense.
> While implementing support for
> automatic synchronization of multiple accounts I had a problem with
> ConfigObject, because when using two different instances of the same
> configuration file I wasn't able to store in the first one the value
> of the accounts with the automatic synchronization value, and read the
> same value with the second one. Probably there is a way to call
> something like 'refresh' from the second instance, but I used the
> design pattern Singleton to share the same instance. I had problems
> with the dictionary-like access to configuration values, so I use
> instead a get(config_key) and set(config_key, new_value) methods. I
> don't think it's too pythonic, but for know it works. About the
> 'autosync_servers', I created two more methods, for adding and
> removing a server from the autosync list respectively.
Sounds reasonable. I’ll have a look how you solved that, but it probably
makes sense to move away from the dict-like interface. One could think
about using properties to hide the getter and setter methods, but
technically, this would be no difference, It’s just a bit more pythonic.
> Other things. Recently we had two bugs reports (#490822 and #490825),
> the first one was about an invalid en_GB translation (WTF, there was
> an Russian string in the en_GB gettext file!!), and the second one is
> more serious and we have to think a little about it. It's called "Bug
> #490825: Multiple Genesis synchronization clicks start multiple
> syncevolution process" and it's about a behaviour I've seen before,
> but I thought it wasn't important. The user advised us about the
> possibility of multiple SE synchronization threads at the same time,
> and probably it isn't desirably because we don't know would happen in
> that case. I commented it in the bug report, but I think in two
> alternatives:
> 1. Only allow one synchronization at once, discarding the other ones.
> 2. Only allow one synchronization at once, and the other ones waiting
> for its turn to synchronize.
>
> I really prefer the second one, and I've done a very little
> proof-of-concept attached as file 'prueba.py'. What do you think about
> it, do you have another ideas? We can disable too the sync buttons
> while a synchronization is in process. I could implement it with the
> multiple account synchronization support intermediately.
Thanks for caring about the bug reports. I’m not sure queuing sync
requests is really worth the trouble, but thanks for fixing it! :-)
> And the very last thing I wanted to comment with you. Could we create
> another branch named for example '0.5.X' or 'future' or something like
> that? We could keep doing bugfixes in the 0.4.X branch, while working
> for the next major release. I'm implementing so much things in
> lp:~davidcaste/genesis-sync/account-management which are not directly
> related with account-management (like the multiple sync support
> thing).
Yes, that sounds reasonable. Then we could also set up a milestone for
this, and assign bug reports to it. trunk would then be for the 0.4
series, and after the first 0.5 release, we would merge 0.5 into trunk.
Thanks for your effort,
Cheers,
Frederik
Attachment:
column-alignment.png
Description: PNG image
References
-
gtk.Builder migration
From: Frederik Elwert, 2009-11-07
-
Re: gtk.Builder migration
From: David Castellanos, 2009-11-15
-
Re: Account management [was: gtk.Builder migration]
From: David Castellanos, 2009-11-15
-
Re: Account management [was: gtk.Builder migration]
From: David Castellanos, 2009-11-15
-
Re: Account management [was: gtk.Builder migration]
From: Frederik Elwert, 2009-11-16
-
Re: Account management [was: gtk.Builder migration]
From: David Castellanos, 2009-11-16
-
Re: Account management [was: gtk.Builder migration]
From: Frederik Elwert, 2009-11-17
-
Re: Account management [was: gtk.Builder migration]
From: David Castellanos, 2009-11-22
-
Re: Account management [was: gtk.Builder migration]
From: Frederik Elwert, 2009-11-23
-
Re: Account management [was: gtk.Builder migration]
From: David Castellanos, 2009-12-02