--- Paolo Borelli <[EMAIL PROTECTED]> wrote: > On Wed, 2004-01-14 at 14:46, Joaquin Cuenca Abela > wrote: > > Hi! > > > > --- Paolo Borelli <[EMAIL PROTECTED]> 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 _______________________________________________ Glade-devel maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/glade-devel
