[Gossip-dev] [Telepathy] rework of the UI

[Martyn Russell]

On Mon, 2006-09-11 at 09:40 +0200, Xavier Claessens wrote:
> Le dimanche 10 septembre 2006 à 19:14 -0700, Eitan Isaacson a écrit :
> > On Sun, 2006-09-10 at 23:33 +0200, Xavier Claessens wrote:
> > > Hi,
> > > 
> > > I'm working on the telepathy branch. I think the UI for accounts
> > > displays too many information to the user. I don't understand why we
> > > can't keep the normal user interface. So I'm cooking a patch which
> > > removes
> > > 
> > >   src/gossip-accounts-dialog-telepathy.[ch]
> > >   src/gossip-new-account-window-telepathy.[ch]
> > >   ui/telepathy.glade
> > > 
> > > and merge changes in the normal code. I think there is not too many
> > > changes to justify a fork of those modules.

It is important to make sure you update this at least weekly
Eitan/Xavier, since there are always changes and fixes being implemented
on HEAD.

> > I chose to put telepathy ui stuff in separate files because the user
> > experience will change fundamentally when the account parameters are not
> > known ahead of time. It is probably possible to put ifdefs in the
> > original UI, but I am afraid it will be hard to maintain and understand.
> 
> Yeah I understand the problem, but for an user point of view it's
> impossible to put all options like it does now. I think there is no
> other solution than having a common UI with basic options and having
> special code for some protocols. We can't have a good UI if it's shared
> for all exotic protocols.
> 
> There is 2 raisons I suggest to come back to the normal dialogs:
> 
> 1) Let's say we only support gabble for now, other protocols will
> certainly need spedial UI. So there is no reason to have a different UI
> for the same protocol whatever is the backend. Except the protocol
> chooser itself.
> 
> 2) If Gossip HEAD moves to GtkAssistant, 

We are planning a release this weekend and then we will start porting
all widgets to use GTK+ 2.10.

> having those modules forked
> will make the move by far more difficult because we would have to make
> the move on both modules. In general I think having forked modules will
> be difficult to keep the telepathy branch in sync with head. And Having
> those modules forked removes some #ifdef in it but add lots in
> gossip-app.c for example, so I don't know if we have a real benefit...

I have to agree actually.

It makes sense to me to have all the telepathy specifics in
gossip-telepathy-*.[ch] files somewhere and make the UI changes minimal
(if there are too many to warrant #ifdef statements). What is vitally
important when writing any UI is that you try to keep the backend and
technical aspects of what your application delivers functionality to as
separate as possible, otherwise it makes UI updates and fixes
increasingly problematic.

To some extent this work was needed anyway, since Jabber does the same
sort of thing with transports and services with their forms/disco JEP.
It has XML detailing what type of UI you should present the user with
what values are needed to register/setup a new protocol.

> For account parameters in a GHashTable I understand the problem which is
> we don't know what kind of informations should be saved in the account,
> but ignoring GossipAccount's properties will certainly lead to many many
> bugs. What I suggest:
> 
> Removing all GossipAccount's properties and add this API:
> 	gossip_account_get_property (GossipAccount* account, gchar *property)
> {return g_hash_table_lookup (params, property);}
> 	gossip_account_set_property (...) {...}
> To keep the actual API gossip_account_set_*() should uses the hash
> table. For example:
> 	gossip_account_set_resource(account, resource){g_hash_table_insert
> (account->params, "resource", resource)}
> So we should convert all actual account properties to the corresponding
> Telepathy hash table element.

This is no small task. If you look at all the places that use the
gossip_account_() API using:

	grep -ir --include='*.c' gossip_account_ ./

You will see that there are quite a few changes that would need doing.
Also, there are some parameters of GossipAccount which do not need
removing, like "name" and "auto_connect" which are more user preferences
for an account than protocol specifics. Perhaps to some extent "id" too?

> I'll try to continue my patch to reflect this idea and see if it can be
> implemented easily.
> 
> Those are just suggestions, what do you think about ?

Thanks Xavier ;)

-- 
Regards,
Martyn