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



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 <tommi komulainen nokia com> 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 <tommi komulainen nokia com>




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