[Gossip-dev] re-design of new account assistant

[Xavier Claessens]

Le lundi 25 septembre 2006 à 11:20 +0200, Xavier Claessens a écrit :
> Le jeudi 21 septembre 2006 à 09:13 +0100, Martyn Russell a écrit :
> > On Thu, 2006-09-21 at 10:01 +0200, Xavier Claessens wrote:
> > > Hello,
> > > 
> > > Now that we depend on GTK 2.10 we can move to GtkAssistant instead of
> > > GnomeDruid. I propose here to think about a re-design of the assistant
> > > with Telepathy in mind.
> > 
> > Sounds like a good idea. I want to get into GTK+ 2.10 as much as
> > possibly while Edgy has not been released, since things freeze at that
> > point and releases are less included in released Ubuntu distros (at
> > least that's how it has been in the past).
> > 
> > > With the rework of GossipAccount proposed [1] we will have an unknown
> > > number of parameters to config. All those parameters shouldn't always be
> > > displayed to the user. So what I suggested to Eitan for the TELEPATHY
> > > branch is having one GtkAssistant page for each known protocol to
> > > display only useful information with a nice UI specialised for this
> > > protocol (MSN, jabber, IRC, whatever is possible with telepathy). If the
> > > protocol is unknown (Gossip should work with unknown protocols available
> > > for free thanks to telepathy) we can make a special page which displays
> > > all parameters available but sorted with the GOSSIP_ACCOUNT_PARAM_FLAG
> > > to hide optional parameters. So the first page of the assistant should
> > > ask for the protocol and next pages should depend on the user's choice.
> > > 
> > > Like that we'll have one page for each known protocol (plus one for
> > > unknown). This means we should create one GtkWidget for each, containing
> > > all we need to display to the user. This GtkWidget can be append to the
> > > GtkAssistant because gtk_assistant_append_page() takes a GtkWidget as
> > > parameter (that differs from GnomeDruid). It will be then very easy to
> > > reuse this same widget for the accounts_dialog window. This avoid
> > > current code duplication between the GnomeDruid pages and
> > > accounts_dialog.
> > > 
> > > I think all this can be implemented in HEAD even if we have only one
> > > protocol (and none unknown) because with GossipAccount's rework it's
> > > possible to implement all that in HEAD and would facilitate the
> > > migration to telepathy in the future.
> > > 
> > > Of course this is only suggestions waiting for comments.
> > 
> > This all sounds good.
> > 
> > Can I make a suggestion though, can we get all OTHER druid pages done
> > first so it gives me time to properly commit and review the new account
> > work? I think there are only 2 or 3 in all of Gossip. The add account
> > druid and the add new user druid. I can't think of any others.
> 
> 
> I already ported add contact to GtkAssistant:
> http://bugzilla.gnome.org/show_bug.cgi?id=357457
> 
> For add-account I have some implementation questions. We want one
> GtkWidget for each known protocol plus one for unknown. Those widgets
> must be used in the GtkAssistant AND in the account-dialog to avoid code
> duplications. How to implement that using Glade ? What I have in mind
> (but not sure it's the right way):
> 
>   - For each GtkWidget we needed, making a GtkWindow containing it in
> the glade.
> 
>   - A new Class GossipAddAccount inheriting from GtkWidget (or
> GtkContainer, like that it can contain the GtkWidget readed from the
> glade). We can put this object in a page of the GtkAssistant and it
> provides a signal like "complete" which says when information are filled
> by the user. It will also keep a GHashTable with pairs param_name and
> value. And having a function gossip_add_account_param_foreach() like
> that we can get values filled by the user and put it in the
> GossipAccount.
> 
>   - Add one module for each protocol, like
> gossip-add-account-<protocol>.[ch]
> This module will have one public function like
> GossipAddAccount *gossip_add_account_<protocol>_new (void);
> Which will read the widget from the glade, pack it in the
> GossipAddAccount widget and return it. It will also connect all needed
> signal from the childs of this widget to fill the hash_table with
> parameters. It will also emit the "complete" signal when not-optional
> information are filled.
> 
> 
> Is that a good design ?
> 
> Thanks,
> Xavier.

Any comment on this ? I'll try to begin the implementation this
afternoon.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.imendio.com/pipermail/gossip-dev/attachments/20060927/faf96223/attachment.pgp