I call gtk_window_is_active(wnd) and always receive 0, even when I know for sure that window is active and receiving keyboard input. What is the cause and where is the remedy for this?
We’re going to need more context to give you a meaningful answer.
Which version of GTK? Which platform? If you connect to the GtkWidget::focus-in-event and GtkWidget::focus-out-event signals, do you observe them being emitted when the window acquires and loses key focus?
Gtk2 on Linux, I do connect focus-in-event to my windows and do process it in a handler that returns 1. What does my handler have to return for gtk_window_is_active() to work adequately?
If you return 1 (or TRUE) then you’re telling GTK that you have handled the event, and the signal emission chain will stop.
Try returning FALSE (or 0), which means “continue the signal emission” instead.
Additionally, I’d strongly recommend you moved to GTK 3—which has more readable constants, like GDK_EVENT_STOP and GDK_EVENT_PROPAGATE.
Emmanuele, thank you very much! Returning 0 from my handler of focus-in-event did the trick, and now gtk_window_is_active() works as expected according to the documentation. This makes me think of several issues:
-
It would be great - in fact, I think it’s a must-do - to have some mention of this in the documentation. If it is already there, maybe it needs to be made more obvious. Like, in the description of gtk_window_is_active() add a line 'This function’s proper behavior depends on you letting GTK run it’s focus-in-event handlers, so make sure to return GDK_EVENT_PROPAGATE from your focus-in handlers". Actually, I have (now) found quite a bit of similar questions on StackOverflow, where the not-so-experienced go down the same road and make my mistake.
The same holds true for configure-event handler and maybe some others. The words “The value returned from this function indicates whether the event should be propagated further by the GTK event handling mechanism” do not make it clear what “further” is, and that the standard behavior of standard GTK widgets is included in this “further” -
In my case, though gtk_window_is_active() returns 1 for the active window, it didn’t help do my task. Because the correct value is only returned AFTER the whole activation process has been completed - and that is in another handler, and way later than I need it. Well, I guess this is ingrained into the asynchronous architecture of GTK, whereas my project has a synchronous architecture, so I had to figure out other ways to do my task.
Actually, here’s what the documentation says:
When widgets receive an event, they frequently emit one or more “signals”. Signals notify your program that “something interesting happened”
This gives (me) the impression that signals are an interface between the widgets (GTK) and my app, from which I derive that widgets proper functioning does not depend on my app. All this to say, Please extend the documentation!
I’m sorry to say, but the behaviour of the focus-in-event is documented.
Returning TRUE means “you handled the event”, so you’re overriding the default widget behaviour. We don’t document the internals of the toolkit because that would prevent us from changing the code at any point in the future. Returning TRUE will stop the signal emission chain, and prevent the default handler of provided by the widget class to which you’re connecting your signal handler; this is intentional, and has been for the past 20 years.
That’s something that generally holds true for all signals that do not have a return value that controls the signal emission chain—an accumulator, in GObject terms.
You need to be familiar with the concepts of GObject and signal emission when using GTK.
Emmanuele,
I’m very thankful for your aswers and for the work you and others have done in GTK. Just to make sure: I’m not filing a complaint, I’m suggesting an improvement.
Yes, the general things and priciples are documented. But the connection between gtk_window_is_active() and focus-in-event handlers is not. It is not documented, and it is not obvious; It is the missing link in the docu that caused my question and that I suggest to add into the documentation.
Here’s what is says:
Returns: [
TRUE] to stop other handlers from being invoked for the event. [FALSE] to propagate the event further.
Talks about other handlers, nothing about default handlers and overriding the default widget behaviour. Even taking your words that I quoted into the docu would be helpful, without disclosing any internals.
Making this connection more obvious in the function’s reference would save poor GTK newbies like me a lot of time and frustration. On Stackoverflow, it took a poor lad a week’s time to figure out the connection of his configure-event-handler’s return value and his widgets not responding to window size change.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.