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

[Xavier Claessens]

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.
-------------- 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/20060925/e499d21b/attachment.pgp