https://bugs.kde.org/show_bug.cgi?id=450582
--- Comment #36 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Hans-Peter Jansen from comment #35) > Of course, we also need to take session management into account. Not being one that uses session management (per se, I use startup scripts and window rules to do the configuring I need) much, I hadn't thought of that. Good call, altho I'd suggest an initial implementation wouldn't need it due to the complexity. > The X11 > protocol does provide the shaded flag for this task. > I even hacked a related tool to handle my firefox setup. FF failed to handle > the geometry and shaded state for some time: > > https://github.com/frispete/wm-win-tool What about other gtk3-based apps? Firefox only or anything gtk-based? As for your tool, I was thinking wmctrl as well, and sure enough it's a dep. But I'm a shellscript guy so that's what all my wmctrl/xprop/etc stuff is, not the python you used. Well, that and kwin window rules. There was also the khotkeys GUI app that allowed dynamic/triggered action invocation, back in the day, but last I tried it, even on X, while the configuration GUI still ran and actions could still be configured, I couldn't get them to actually work as configured. I strongly suspect that it had lost a proper maintainer even by the time of the kde4->kde5 port, and while it was "ported" by others in terms of made to build and the GUI run, I'm not sure it ever actually worked properly on kde5, and certainly didn't seem to even on xorg last I tried it. But I can't /imagine/ the kde wayland port being considered complete without /some/ sort of scriptable/invokable custom window management comparable to the static functionality kwin window rules provides on X and wayland, and wmctrl and friends provide dynamically on X, so I guess eventually they'll either fix/port khotkeys, or reimpliment similar functionality from scratch. But I actually don't expect it until after the (currently underway) qt6 port is done. (And qt6 being the first qt to have wayland support from the get-go, I expect its wayland support to be better and more efficient, such that implementing such stuff in it may well be 2/3 the work it'd be on qt5.) Anyway, doing wayland-shading session support without full protocol support is still possible, but I expect it'd be several times the complexity of the "simple" solution I was imagining, so wouldn't be likely for initial support at least. But as long as apps can be forced to run in X mode via xwayland, existing solutions like your scripting solution should remain viable. And pre-setting such vars before app startup or auto-adding commandline options as appropriate, is what wrapper scripts are for! =:^) -- You are receiving this mail because: You are watching all bug changes.
