If i have an action registered with the application or window, how do i get the window from inside the activate callback. The window is required to position a “dialog window” relative on top of the invoking window via “gtk_window_present” ?
You can’t. You have to include the window in the user_data parameter when you connect the callback.
I feared that this is impossible.
Thats VERY VERY BAD design, an invocation context (or at least the triggering event - but an action shouldnt be restricted to only envent triggers) is required. Microsoft new this in 1989 already.
Lets put it on the Gtk 5 feature list please.
Passing as user_data is impossible when reusing the menu in multiple windows.
Static description of the menu and dynamic invocation need to be separated concerns.
So i have to add boilerplate code to track which window was last activated.
I can’t see any API for this.
Thats VERY VERY BAD design
An EVEN WORSE design would be to include “window handles” in non-GUI platform code (note how it is GAction and not GtkAction).
Not to mention that GAction can be used in GUI-less processes or be associated with a GApplication as a whole rather than a particular window.
Or that there is no restriction on adding the same action to multiple action groups, so “does this action group contain this action” has an unambiguous answer, but “get me the action group for this action” does not.
But now sure why I’m bothering, you clearly think that after thinking five minutes about a particular API, you know better than the people behind that API (disclaimer: not me).
If you really want actions that are tied to a particular window instance, then you can either
- implement a custom GAction type (it’s not a complex interface)
- use
g_object_set_data()to associate a pointer to the window with the action, andg_object_get_data()to read it from the callback
No. I looked at GAction already a few years ago. I’m sure i’m in this Unix GUI game much longer than you.
First i still can’t see any huge need why we bother with non GUI code for this things. But ok, it just has absolutely nothing to do with the basic problem.
Just making the “activate” callback receiving an additional invocation parameter of an GActionInvocation type, which can have a pointer to the window is absolutely breaking nothing but you could query for many more options. If you have a action registered in a shared library for example you could also have a way to query which application is invoking the action. There is a real need to have an invocation context.
It does not mix GLib and Gtk more than GApplication and GtkApplication. You should reread my posting and try to understand what i’m taking about and think more than 5min about my feature request.
I explicitly said, but maybe not clear enough, i agree we dont want actions bound to a window.
We all know that the actions are designed the way to create them all at the begin of a program lifetime as part of the setup and they usually never change. Only getting enabled and disabled based on the program flow but that is a program state context, not the invokation context. The invocation context is like a GEvent.
The reason why we have GAction is, if you don’t remember, we had to serialize it and provide the GUI shell an out of process access for the Mac like menubar (the MacOS design always sucked but thats left not to discuss here). But this is also legacy now and we all have given up. The second purpose is to make enabling and disabling of actions better. And inverse of control the way to check if menu items are grayed out. Not testing program conditions on each menu display but changing the action enable state when the program state changes. This was a good idea but it never worked because the implementation sucks.
Third the way action groups are attached to widgets and lookup could travel up the widget hierarchy was GTK’s idea of implementing the famous Cocoa Responder Chain. This implemenation doesn’t work well anymore or didn’t ever. It especially lost it’s usefulness once we switched to window embedded sidebars instead of panel keywindows. And in GTK it never worked well for bad implementation.
I could go on and explain why GAction shouldnt have an enable state either but instead have a condition test system sitting above it. But doing int a forum post is like “Perlen vor die Saeue werfen”. Needs at least a 10 page long RFC.
This is, quite frankly, adorable, but not the best way to ask for help in a user support forum. Actually, it’s very much the opposite of the best way.
quick snip on a bunch of random assertions
Okay, if you ignore everything in the context of how this API was conceived and implemented, and the API stability guarantees under which it exists, then: sure, you could reimplement GAction in a different way to make it possible to support your own use case.
I guess that’s why you’ve been in this Unix GUI game for a while.
And this is how you get your account flagged and suspended for a week, while you think about how to properly behave like a person, instead of being an asshole.
1 Like
Fine, I’m sorry I was trying to help you. You can rest assured that I won’t commit the same error again.