Hmm, I had thought it was already discussed that having Add and Remove buttons is mandatory, for accessibility and discoveribility. I guess I misread something.
Anyway, based on that assumption I was thinking about simple and straightforward transformation of the old dialog. Get rid of the entries and buttons except for 'Remove' and change the '...' to 'Add'. Clicking Add would show the existing dialog from which you just pick the signal. Selecting OK will add the signal in the treeview, and begin editing the handler name in place. Pretty much like the following. (Buttons are just to show the required elements, their actual placement is open.) Signal Handler After GtkButton clicked on_add_clicked [ ] clicked on_add_clicked_after [X] GtkWidget map on_add_map [ ] unmap [ ] [ ] -------------------------------------------- [Add] [Remove] The above should be clean, and show all and only the relevant information. Also the use of normal buttons should be familiar for everyone. It is slightly slower than your mockup since you need to go through the dialog (three clicks, always) instead of just clicking on the treeview directly (one click, best case.) I just don't believe adding a signal is done often enough that saving the two clicks compensates enough for the issues I've mentioned. On Fri, 2004-01-16 at 16:20, ext Joaquin Cuenca Abela wrote: > --- Tommi Komulainen <[EMAIL PROTECTED]> wrote: > > The added benefit is that you are saving one click > > when adding a signal > > from the topmost class, but that's all. Adding a > > signal from ancestors > > requires you to expand the class first, no help > > there. > > I don't follow you, here. We're saving one click > relative to what UI? (Actually two clicks, see above. My mistake.) The current one, or I think anything that only shows signals with handlers in the treeview. > > I don't think adding a signal from the topmost class > > is that often used > > that you need to optimize away one click, making > > other things harder in > > the process. > > Again, I'm lost. We're making things harder relative > to what? > > Btw, I think that adding a signal to the topmost class > is the most used operation on the signal's dialog. I'd argue the most used operation is to see what signals already have handlers. Before you add a handler you probably take at least a cursory glance to see that the handler isn't already there. With new widgets you'll probably skip that step, but the longer the widget has been in the model, the more likely I think you need to refresh your memory. We can, of course, agree to disagree on the matter. :) -- Tommi Komulainen <[EMAIL PROTECTED]> _______________________________________________ Glade-devel maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/glade-devel
