genesis-devs team mailing list archive
-
genesis-devs team
-
Mailing list archive
-
Message #00009
Re: Account management [was: gtk.Builder migration]
Hi Frederick!
It's me again. I've been thinking about the buttons thing, and 'add',
'remove', 'properties' and 'sync' are too many buttons for a
horizontal or vertical layout. I had a look at other programs like
Seahorse[1] and Tomboy[2], and I've thought it would be a good idea to
add a menubar, a toolbar and a statusbar. A toolbar isn't strictly
necessary, but it won't do harm anyway. This way, the screen wouldn't
be so overloaded, and the special sync methods makes more sense.
I've attached you a Glade file with my file, please tell me what you
think about it.
Cheers!!! :-)
[1] http://projects.gnome.org/seahorse/screenshots.html
[2] http://projects.gnome.org/tomboy/
2009/11/15 David Castellanos <davidcaste@xxxxxxxxx>:
> Hi Frederick!
>
> I've just uploaded to Launchpad a very first implementation of account
> management. There are some things to improve, but for now it's able to
> add, delete and modify accounts.
>
>>> I have a
>>> screen called "Account Properties", which is used to modify the
>>> settings of an account. I just realized that "Account Properties" and
>>> "Account Wizard" share most of the source code, and its functionality
>>> is almost the same. What about if we get rid of the "Account Wizard"
>>> screen? "Account Properties" could be used instead, just like Mail
>>> Notification[1] does.
>>
>> I’m not sure about this. The benefit of a wizard/assistant is that it
>> ensures that all necessary fields are filled out. If you just use a
>> dialog with several tabs, people could fill out only the first tab and
>> omit the rest.
>
> Good point :-)
>
>> Wouldn’t it be possible to re-use code and ui definitions to implement
>> both? I’m not sure this is practically doable, but maybe one could split
>> the several pages (assistant) and tabs (properties dialog) into separate
>> ui files and create the assistant/dialog from the same UI information.
>
> Mmm, I'm not so experienced in PyGTK to do that, but it's be a great
> idea. Undoubtedly both screens share most of the elements and
> functionality. I'll add it to my TODO list.
>
>> How does one select the active account? If we include a radio button as
>> one column, we could get rid of the “select server” menu. Once syncing
>> multiple accounts is implemented, we could change this into a checkbox,
>> like it currently is in MS.
>
> My idea was to implement multiple account synchronization altogether,
> because I have it already implemented in MS11 and it isn't too
> difficult to backport it to Genesis. I'm not satisfied with the way I
> implemented 'enable/disable account' in MS11 because SE doesn't offer
> a clean way to disable an account. I considered an account as
> 'enabled' if at least one of its sources were synchronized, and
> 'disabled' otherwise. The 'enabled' to 'disabled' transition was clear
> because it was only necessary to disable the account origins, but the
> 'disabled' to 'enabled' transition wasn't as simple. What sources
> should be enabled?, there is no simple way of remembering what origins
> where previously enabled. I implemented this feature because the
> original MS had it, and one of the development requirements was to
> support at least all the features that had the old client.
>
> IMHO, this feature isn't as important because if an user doesn't want
> to synchronize an account, he can delete it or manually disable its
> sources. If in the future SE adds support for easily enable or disable
> an account, we can add support for it.
>
>>> Another option I thought about
>>> was to automatically create account names of the form 'XXX@YYY', where
>>> XXX is the username and YYY the service. For example, 'david@Google'.
>>> But I haven't implemented this, it's just an idea.
>>
>> Yes, that sounds good. Do you think it still should be possible to
>> change the account name? There might be situations where one wants to
>> have two or more accounts with the same service (e.g., syncing more than
>> one calendar). In Evolution, the name of the account is asked for at the
>> last step of the assistant. One could do this similar, and pre-fill that
>> field based on the given information.
>
> I had not thought of that. My first idea was to do something similar
> to Mail Notification (I really love this program!! :-P). In MN you can
> manually change the account name, or accept the 'XXX@YYY' proposal.
> Right now, we're able to change the name of an account... although the
> way I've implemented it is somewhat tricky because SE doesn't support
> renaming accounts: I delete the old account and create another with
> the new name. About the account name in the last page of the wizard,
> it could be implemented too when the assistant is refined. I'll also
> add it to my TODO list :-)
>
>> Just one more comment on the account properties in MS sync: There you
>> added a third tab allowing to sync accounts in a different mode. While
>> we should definitely allow this (and the current “special sync” menu in
>> Genesis really is far from being optimal), I think this is not the best
>> place for this. In a properties dialog, I as a user would expect
>> permanent settings for an account, not running single actions.
>
> You're right, it's very weird. It's for the same reason I've said
> before, the original MS had that feature... I didn't find a better
> place for it :-S
>
>> My suggestion would be to add a button to the account manager with
>> something like “synchronize”. This button should pop up a menu that
>> allows to select the mode of sync for this single sync (like a ComboBox,
>> but it shouldn’t actually change its label).
>
> That's a great idea!! It makes much more sense.
>
>> Since four buttons next to each other, it might be worth thinking about
>> using a vertical layout for these.
>
> Personally I prefer the horizontal layout, but it's a matter of making
> two mockups and choose one. With GTK/Builder is very easy to build a
> prototype for this kind of things.
>
> It won't give me time to finish in this weekend, but I'll try the next one.
>
>
> Cheers!!! :-)
>
> P.D. One little thing! Please watch out to send to CC the genesis-dev
> mailing list, because by default GMail sends the email to only one of
> us. Thank you!!! :-)
>
Attachment:
accounts_window_2.ui
Description: Binary data
Follow ups
References