Subject: Re: Bug fix for 522
sterwill@abisource.com
Date: Mon Feb 14 2000 - 20:08:56 CST
Daniel Weber wrote:
> I'm working on a perfect solution to 522 (key strokes activate toolbar
> combo boxes). I think I've gotten a working solution, which works as
> follows:
I checked in a quick fix for #522 last week. It didn't actually
solve the hard problem of dealing with focus (and doesn't get us
closer to letting the user type in the dialog), but it should have
fixed #522 as many people were seeing it. It was a numlock problem,
which was being caught by the top-level frame and being passed down
to the combo.
> 1) Signals are attached to the combo using s_register_signal. This
> function saves them, but doesn't connect them.
> 2) Whenever the combo button is pressed, signals are connected
> 3) When the hide event is triggered, the signals are disconnected
> again.
Is this all signals, or just keyboard signals? Blocking all signals
might get your mouse caught up in weird places, and blocking all
key signals might make other weird things happen (or it might not, I
haven't tried that before).
> 1) Why is the key-press event attached to the combo box? Is there a
> key combination it should respond to? I'm doing my testing with the
> signal not attached.
I don't believe there is a key handler for the combo box. What happened
that caused #522 is that the top-level frame got a key, we handled it,
and said "ok, we're done, pass this one on GTK," and GTK looked at
all our children widgets that had registered to receive key strokes,
and behold! the combo box _had_ registered (it had recently received
focus through a click or selection with the mouse). So GTK gave these
keys to the combo box.
I think an easier solution might just be to immediately drop the
focus from the combo boxes whenever the box is "done". "done" means
whatever signals would be thrown when the user has selected a value.
There is most likely already a hook (callback) for this, because we
should throw it right after we do our action (for the Zoom combo,
this would be right after we tell the main frame to change its zoom;
for the font size, it's right after we tell the layout to change
font sizes, etc.).
> 2) Are the above errors experienced by anyone else? Are these known
> bugs or am I creating them?
I haven't seen those errors at all, but I think it may have much to
do with blocking events or signals to the combo, and I think simply
throwing away the focus would be the safer thing to do.
-- Shaw Terwilliger
This archive was generated by hypermail 2b25 : Mon Feb 14 2000 - 20:08:57 CST