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

[Joaquin Cuenca Abela]

--- Tommi Komulainen <tommi.komulainen@nokia.com>
wrote:
> On Fri, 2004-01-16 at 01:52, ext Joaquin Cuenca
> Abela wrote:
> >  Tommi wrote:
> > > 
> > > On Tue, 2004-01-13 at 23:11, ext Joaquin Cuenca
> Abela wrote:
> > > > Hi!
> > > > 
> > > > I've been hacking a bit on the signal editor.
> > > > 
> > > > What do you think of an interface like that
> one:
> > > > 
> > > > http://e98cuenc.free.fr/signals.png
> > > 
> > > Hmm.. that feels unnecessarily crowded to my
> taste.  It's 
> > > showing all possible signals for every widgets,
> and yet you 
> > > usually only ever use one or two.  Keeping
> signals like 'map' 
> > > always visible makes the dialog pretty
> cluttered.
> > 
> > The plan is to make the divide the signals by its
> class, opening only the
> > topmost class. That leaves only 4-5 visible
> signals by default.
> > 
> > It's still a work in progress, but you can see a
> more recent screenshot
> > here:
> > 
> > http://e98cuenc.free.fr/signals2.png
> 
> That's better, but I think it still has the same
> problem.  (I was
> actually thinking you should show the widget class
> as header even if you
> did show just the signals that have handlers.)
> 
> The basic problem with having all the signals in the
> same tree is that
> you're repeating useless information (<Type signal
> handler here>) over
> and over again, making the relevant information
> (which signals actually
> have handlers) more difficult to find.

Of course, with the current mock-up the <Type signal
handler here> is too inconvenient.  I was thinking
that I should display it on a light gray, and probably
don't display it at all if there are no signals
handlers attached to a signal (leaving it just as a
clue to people that want to add several signal
handlers to the same signal).

More or less like this:

Signal          Handler               After
v GtkButton
  v pressed     on_press_button       []
                <Type signal...>      []
  > released    on_release_button     []
    clicked                           []
    enter                             []
    leave                             []
> GtkContainer                        []
> GtkWidget                           []
> GtkObject                           []

Another idea that I want to test would be to mark
connected signals in bold, but I fear too much
"colors" in the same window (some signal handlers
bold, other signals normal + maybe some <Type...> in
light gray).

>  You can't be
> certain which
> signals have handlers unless you expand all classes
> and scroll the list
> around.

Good point.  Alternatives are:

1) to expand all the classes with signals that have
handlers by default + always expand the top-most
class.

2) to show in bold the classes that have at least a
signal with a handler.

I prefer alternative 1.  For a casual user, it just
means to expand the top-most class, and users with
handlers down in the hierarchie will be able to see
them at a glance.  But I have to see it in live to
take a decision.

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

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

> > > Can anyone make an educated guess whether or not
> the ability 
> > > to add multiple handlers for the same signal is
> actually used 
> > > in practice? 
> > > It's obviously making the UI more complicated,
> but is the 
> > > feature useful enough to warrant that, I don't
> really know...
> > 
> > I'm still not sure that it will make the UI more
> complicated. There are
> > several ways to leave multiple handlers per
> signal, and still share the same
> > UI with the "only 1 handler per signal"
> alternative.
> > 
> > For instance, you can say that the handler is
> instead a comma separated list
> > of handlers.
> 
> Showing more information pretty much always results
> in more complex UI. 
> There are degrees of complexity, though...
> 
> Comma separated list would be hard to discover,

But it will not interfer with those using the dialog
box as if it was only possible to have one handler per
signal.

It was just an example of a way to handle this problem
that doesn't makes life harder to those using it with
only a handler per signal.  The "hard to discover"
problem is why I'm experimenting with <Type...> labels
instead.

> and
> to see all handlers
> for a signal you'd either need to scroll
> horizontally (even worse than
> vertical scrolling) or have quite a wide window.

True, but it will not penalize
"one-handler-per-signal" users.  Thus we can still
have several handlers per signal, without complicating
the common only one handler per signal use-case.

Again, I'm not favoring the comma separated handlers
approach, it was just an example.

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