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

[Joaquin Cuenca Abela]

--- Paolo Borelli <pborelli@katamail.com> wrote:
> 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

That may make keyboard driven selection uncorfortable
to use, as you will be entering/leaving edit mode all
the time.

> 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.

That's the current behaviour

> 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.

when you enter the "edit" mode, the whole signal's
handler is selected, so you're just a DEL away from
deleting the whole signal handler.

> > 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

yes, that's the main problem that I foresee with this
approach.

> class. That could
> make things slightly more painful. Maybe the nodes
> containg the signal
> name should be expanded by default.

At the very least, the signal names of the current
widget class (as the original patch from Sridhar did).
 
Cheers,


=====
Joaquin Cuenca Abela
e98cuenc at yahoo dot com

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus