When I detach menus from Gimp or open some other toolbar windows, alt+tab will not show them… and there’s no way to move to those windows unless I minimize/lower all other windows to reach it…
have default settings:
Anyway to include those windows? pressing alt+backtick also doesn’t help.
found that icon-only-task-switched panel applet do find those windows, so using that as a workaround instead of minimizing everything.
gimp have an option to manage those tool windows. I tried to set them to be hinted to the WM as “keep above others”. But alt+tab’ing from gimp and back, will still keep the tool windows behind gimp, and still with no way to select them by kwin.
Hi - I’m not personally experienced with Gimp, but just for context there has been some previous discussion in a KDE Bugtracking System report on how that program’s windows should be handled: 172615 – Gimp 2.6 utility windows do not stay on top of the main window
From my experience keeping above for Gimp windows can get quite…busy. Especially since tabs in the toolboxes are windows when disconnected. If you have one of them like, say, the text editor ( not the text toolbox) set to above, the workflow gets …messy imo. Max,min etc…messy. As far as gimp goes, I stick to grouped tasks and fixed gimp tabs. It just makes more sense to me.
That one is debatable. Let me give you an example.
In this case, the text editor ( not the semi-transparent text toolbox) is set to “above all windows”. If you want to do some text stuff that window will show. Of course, if you switch to, say, the brush tool, that window is not needed, right? It will not show. There’s no point of having a floating tab ( as window) if you switch to another tool. That would be crazy and completely clutter Gimp.
But, if I take a screenshot of all that, spectacle will be behind the toolbox editor. So, in this case, the text editor window will act as “told”…on top.
That’s why I mentioned in the previous post that the “keep above” function in Gimp is not really…helpfull. Fixed gimp tabs and grouped tasks prevent you from Gimp ptsd imo.
Are you using X11 or Wayland? (also, pasting the details from Info Center / output of kinfo is often helpful in support requests).
Generally the task manager / alt-tab do not “see” tool windows - it is up to the application to manage their visibility.
Which version of GIMP are you using? I remember it was a thing back in early GTK days, but I can’t do it on my instance of GIMP 2.10.
Are GIMP’s menus meant to be detached in that way or is it a bug? I haven’t noticed the ability to intentionally detach menus.
GTK has (used to have?) this feature were you could “tear off” menus to make them sort of semi-permanent “action toolboxes”. Here’s a screencap demonstrating it: https://i.imgur.com/Bb1zw4d.mp4
I haven’t seen this used in a long time and my installation of GIMP 2.10 doesn’t do that, to the best of my knowledge.
It still does you know. Click on the, how you call it, striped lines on top of those submenus. However, those “standalones” don’t show in tasks. Floating tabs do. Those things don’t.
I don’t have dashed lines in my GIMP menus.
That’s odd. I’m on 2.10 so…
Those things identify as detached menus ( not sure in English) so I guess you could assign some kind of rule to them.
i think they removed the dashed lines in gtk but some applications decided to implement it back? not sure, but in gimp, even if you don’t have the lines on regular menus: right click and it will show the same menus but with the dashed lines!
my bad. i will do the full about info when I’m back on that machine. but its plasma 6.2, wayland. all latest versions (arch Linux)
Or rightclicking the menuitem in the context menu should also detach it.
Ok - now I understand. It wasn’t very clear to me that the way to get tear-off menus was by using the RMB menu from the GIMP canvas, and not the menu bar - it has been quite a while since I’ve used the RMB menu on GIMP (I was never a fan of twm 
).
So one thing that is weird, is that if you get a torn-off menu, and go Window Operations Menu → More → Configure Special Window Settings, in the window rule it lists the “Window type” as “Torn-off menu” - which is what you’d expect (though I’m surprised the KWin has this category, but apparently it knows):
But if you then click Detect Window Properties and select the torn-off menu window, it says the “Window type” is “Dock (panel)”:
(and it is already selected, supposedly, though what is actually selected is the “torn-off menu” window type).
Now if you open the kwin debug console, you can see that the torn-off menu is an XWayland window (as expected) - where such windows can ask KWin to skip taskbar and other things that Wayland window cannot - but the GIMP torn-off menu doesn’t:
But it does lists its window type as NET::Menu - which according to the above linked kwin code means “torn-off menu”, though I’m pretty sure all menus are windows with type NET::Menu. And here lies the problem - the plasma task manager ignores windows that don’t have specific types - and NET::Menu isn’t on the list. This actually makes a lot of sense, and likely @alex didn’t think about torn-off menus at that point (KDE developers’ unawareness of this “feature” has been demonstrated in this thread).
The thing that annoys me is that this is obviously where KWin windows rule should come to the rescue: you can target those windows and there’s a “Skip Taskbar” property - set it to “Force: No” and you’re done. But it doesn’t work that way - window rules whose value is “No” mean “don’t affect”, not “turn off said behavior”. For example if you have a CSD window, you can’t use the property “No title or frame” set to “No” to force kwin to draw window decorations. And at this point one has to ask oneself - what is even the meaning of a “Yes/No” property where “No” is equivalent to not having that property in the rule at all?
It’s a weird thing, that torn off menu. I really think this is up to the Gimp folks to implement a setting for this.
Like I previously said, you can have detached tool tabs to show in tasks. Gimp has a setting for this under window management. Set those things as normal windows.
As such they’ll have a task for it.
But that torn off menu doesn’t have a setting. And, for the life of me, I can’t get those things to show in tasks. It’s recognized by kwin alright, but the moment you switch to another tool or canvas, it’s gone. There’s no way to invoke it. It’s there alright, because, as far as I can tell, it shows when you do “minimize all”.
Minimize all ( all get minimized except that d…n menu):
Doesn’t show in overview, grid…nowhere except…where it shouldn’t show really. Maybe I missed something in the rules for the thing but I can’t change this behaviour. Again, I don’t really use those floaters but this one has a weird limbo -ish behaviour.
It’s all because GIMP sets its window type as “menu”, even though it behaves nothing like a menu: it doesn’t grab the mouse, it is persistent (it doesn’t go away when you click outside), it has window decorations, etc. As such - it confuses the heck our of Plasma: it’s a window that is a menu that is also not an actual menu but definitely not a regular window.
Regarding the task manager - it maybe can be fixed by identifying “torn-off menus” as a valid task, regardless of its window type - maybe task manager can see that it has decorations, though I haven’t investigated the code enough to see if that is possible.
Well, no rush from my side. I use detached toolbox tabs at most so…
Besides, like I said, this is Gimp folks’ stuff. Don’t have a gtk DE around right now but I wonder if those non-yes menu/non-yes windows appear in tasks on those.
To be honest, i lost track of the number of times I thought that, spent some time fiddling with detecting windows and could never solve any annoyance ever with window rules.
If I could have gimp menus as permanent “tool” blocks on the side bars I would be a happy gimper… But out of all the investigation from gus77, that the windows are actually “menus”… I would say:
kwin have a bug of not placing all “menus” belonging to an application, on top of said application when it is moved to the front.
(IMO this is the most obvious and expected behaviour, and i cannot think of any argument against it no matter how contrarian I try to be. I don’t even think it requires special type translations as suggested. Jut treat as a menu and behave as a menu.)
