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



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]