Signal editor (was Re: [Glade-devel] small patch)

[Paolo Borelli]

On Wed, 2004-01-14 at 14:46, Joaquin Cuenca Abela wrote:
> Hi!
> 
> --- Paolo Borelli <pborelli@katamail.com> wrote:
> > 
> > For adding a handler it looks good since you have to
> > type the function
> > name anyway, but have deleting as the only way for
> > removing the handler
> > is a bit weak... I's like to have a "remove handler"
> > item in the popup
> > menu.
> 
> I don't understand your concern.  Why is a bit weak to
> remove the handler when you remove the name of the
> handler?
> 
> It seems quite natural to me.
> 

I find it natural too and I'm all for it, just I'd like it not to be the
*only* way to remove a signal handler. Two reasons mainly:

1) discoverabilty: I expect that when you select a row to add an hadler,
the "handler" cell switch immediatly to edit mode so that it's clear you
should type the function name, but when you select a row which already
has an handler name I'd expect it to simply be selected and to switch to
edit mode only if you click again on the cell.

2) ease/rapidity of use: when you add a handler you have to type the
function name anyway, but to remove one it would be nice to just have to
click a button and/or press the DEL key instead of deleting the function
name character by character.


> We should anyway show the handler's names in the tree
> view, maybe as Archit suggests making the signal's
> name the parent of handler's names on the tree.
> 
> Then we can have a "<Type your signal handler name>"
> that will add a new handler when the user types the
> name of the handler.  Something like:
> 
> Name             Handler          After
> =======================================
> - Activate       
>    |______       on_activate1      [x]
>    |______       on_activate2      [ ]
>    |______       <Type your ...>
> + Realize
> 

I generally like this solution too, note however that we end up with a
three level tree, since signals are also grouped by class. That could
make things slightly more painful. Maybe the nodes containg the signal
name should be expanded by default.

> The disavantage of this method is that you have to
> expand the signal before being able to add a signal
> handler.
> 
> I also don't know if it has accesibility problems.
> 
> I'll consult the usability folks on this issue.

Agreed, some advice by the "experts£ would be great, especially because
there aren't many examples of this kind of UI in gnome


ciao
	paolo