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

[e98cuenc yahoo com (Joaquin Cuenca Abela)]

--- Tommi Komulainen <tommi komulainen nokia com>
wrote:
> 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.

AFAIR, I was just wondering if they were need for
accessibility and discoveribility.  Later I though
that adding the <Type...> label makes editing in place
so easy to discover as with a button.

I've got no feedback from the accesibility guys, but
even with a button, you have to browse a tree view in
the dialog that opens with all the signals, and in
place editing has been used before.  So I guess that
accesibility wise it's ok.

[snip]
> 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.

So, in short, the issues are:

* discoverability
* accesibility
* familiarity
* shows more information than need

As I said, I think discoverability got addressed with
the <Type...> label, even if it's yet a bit too
visible.  I'm playing with several alternatives to
make the label less ubiquious, and yet make it easy to
see where can you type the handler.

Accesibility wise, I think we're ok, but I'm ready to
be proved wrong :-)

For the familiarity, in place editing is used in any
RAD tool I can think of, and the concept has been with
us for a long time across any OS.  We're also
targetting developers, which are usually a bit more
computer savvy than the mean.  So I don't think that
any glade user can honestly say that he had problems
grasping the concept.

The "shows more information than need" problem is only
real if you define the "need" as remove/modify
handlers.  As soon as you add the "add" a new handler
operation, then the dialog shows just the information
you need.

So I guess the question is if easing the adding of a
new signal handler is worth the space taken by the
signals without handlers + the unused classes.  In my
opinion, yes, it is, as there is indeed a very little
number of signals on a widget (usually 5-6) and you
will rarely use a signal on a parent class (usually
people connect to "pressed" signals and such).

And I don't consider a list of 5-6 signals to be a
problem at all when you're looking for your signal :-)

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

You can see if your signal has a handler at a glance. 
If you're going to take that as an "operation", then
the new design also frees the user from 1 additional
search when adding a new handler, as with the old
design you should first see if your signal has a
handler, and then search your signal in the dialog
box.

But again, the first search is just a glance, you see
clearly what are the signals with a handler as those
without a handler have the <Type...> label with a
different colour (gray instead of black).  We can put
the signals with a handler in bold to make it still
clearer, though.

Thank you for your comments!

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