[EMAIL PROTECTED] wrote:
> 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.
>
Yup, I added your fix to my tree. It clears up the num lock issue. I'm
trying to fix the larger issue with
>
> > 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).
>
I only deal with "changed" and "key-press". I don't connect "focus-in" or
"focus-out". I connect a handler to the combo->button."pressed". No other
signals are attached.
>
> > 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.
>
Your fix only corrected the numlock keys from getting in. A lot of other
keystrokes did get through (like back space). Mouse clicks trigerred the
handler as well.
>
> 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.).
>
I've tried every way to get rid of the focus. GTK does not handle focus
well, to say the least. My current fix has some success in dumping focus
by sending a "focus-out" event to the combo->entry, but for some reason
when you alt-tab back, why, there's the focus again! I haven't found any
function, anywhere, to dump the focus. GTK has been very insistant - by
God, that damn entry control has the focus!!!!
>
> > 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.
>
I'm beginning to think the focus-change may have something to do with it.
However, I need to get rid of it if I'm going to get the entry working
properly....
