| Summary: | core kcms should not manipulate the effects plugin list, but effects should autoload depending on core settings | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Allan <allan> |
| Component: | effects-various | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | wishlist | CC: | bfeber |
| Priority: | NOR | Flags: | thomas.luebking:
Decision-Required+
|
| Version First Reported In: | 5.2.2 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
Stripped down: ------- The window geometry effect gets en/disabled by the options kcm but should instead either autoload depending on the GeometryTip OR not be stashed in the effects kcm You want to kwriteconfig5 --file ~/.config/kwinrc --group Plugins --key kwin4_effect_windowgeometryEnabled --type bool false Technically, that's not a bug. Autoloading depending on core config items would require a way for the core to impact a temporary config and reload plugins from there. On a more general POV, since the effect invocation is generic (any effect with the proper feature announcement can replace the legacy box), I'm not sure whether stashing the effect is the best idea - at least it would have to show up whenever any effect plugin with the same feature (how do we know that?) is installed (to allow a selection) On my setup, the key is simply windowgeometryEnabled, no kwin_4effect prefix. To rephrase, the first time the GUI checkbox is checked, there is no wgE key created in kwinrc. This is why I was led to believe that the GeometryTip key was responsible for both invocations. After creating it manually, and setting both wgE and GeometryTip to false, I can see that the behaviour of the GUI checkbox is to set both to true, even though the wgE effect overrides that of GeometryTip. I believe the bug is: the wgE key, when changed from its default state, should be written in kwinrc like other keys when changed from the default state Is it the intention to have the simpler GeometryTip as well as wgE to both exist? If so, then: - no way to invocate GeometryTip from the GUI, even though it is a simpler and different view for the geature - GUI for wgE turns on GeometryTip, when both are separate effects Another note is that GeometryTip can be turned on and off and its effect immediately visible upon 'qdbus org.kde.kwin \KWin reconfigure'. However, I do not know how to turn on/off plugins such as wgE and kwin4_effect_translucencyEnabled after making a change to the text file besides logout/login. How is the GUI 'Apply' button reloading KWin instantly? It would make sense to me that instant KWin reload should exist for text file changes if it exists for the GUI. (In reply to Allan from comment #2) > After creating it manually, and setting both wgE and GeometryTip to false, I > can see that the behaviour of the GUI checkbox is to set both to true, even > though the wgE effect overrides that of GeometryTip. There's no "override". The background is that the "light" box is a rather expensive implementation with an extra X11 window - which is required without compositing (thus "legacy", it's the implementaiton KWin has since ~1998) but becomes extra-expensive with compositing (another window to redirect which then updates like hell) With enabled compositing, we can skip that and paint the information directly into the scene. This is what the "window geometry" effect (the dark variant) does - in addition it makes use of some extra compositor features (translucency, round corners - actually it's an unthemed & generic effect frame, like the labels in the present windows effect) and, since it's fairly cheap, we also have more boxes for more/positioned information. What happens is that if you configure the geometry tip, the code will first check whether a) it's compositing and b) an effect can paint that info for us. The legacy box is then simply skipped. The kcm loads the effect qdbus org.kde.KWin /Effects loadEffect windowGeometry or unloads it qdbus org.kde.KWin /Effects unloadEffect windowGeometry and also should (the code is there and it does here) write the config entry accordingly. The effect itself has no and does not listen to further config keys - loading it implies you want to see the window geometry - it however has a toggle shortcut, Ctrl+Shift+F11. > the wgE key, when changed from its default state, should be written in > kwinrc like other keys when changed from the default state Afaics, this *is* happening. Geometry tip has been dropped. Let's revisit this once the need for this reappears. Currently, geometry tip can be implemented only using scripting, which can be enabled by a single option rather than two. |
There are two implementations of the window geometry feature. The first is the light implementation. It is supposed to set by the boolean 'GeometryTip' key under the 'Windows' group in ~/.config/kwinrc. In a clean install, this setting shows a light-coloured centered box centered in the window, displaying window dimensions. The second one is activated by the GUI settings. It is the dark implementation. It shows shows a dark-coloured box in the center of the window, another in the top left, and another in the bottom right, with dimensions and coordinates. The dark implementation overrides the light implementation and kills text configuration/kwriteconfig compatibility. Reproducible: Always Steps to Reproduce: In KUBUNTU: 1. kwriteconfig(5) --file ~/.config/kwinrc --group Windows --key GeometryTip --type bool true 2. Restart KWin --> org.kde.kwin /KWin reconfigure 3. See a light-coloured centered box with window dimensions. 4. Change the key in #1 to false via kwriteconfig, restart KWin. See that the option is successfully turned off. 4. Change the GUI setting: System Settings -> Window Mangement -> Window Behavior -> Moving -> CHECK "Display window geometry when moving or resizing" 5. See dark-coloured boxes at the center, top left, and bottom right with window dimensions and coordinates. 6. Uncheck the setting in the GUI. 7. Check the key in #1, it is now: GeometryTip=true. 8. Attempt to disable the feature with kwriteconfig(5). 9. The black geometry boxes are not turned off (reboot, logout, KWin restart persistent). However, the box is checked/unchecked accordingly in the GUI to match the setting in the text file. 10. Check and then uncheck the box and click Apply in the GUI is the only way to disable the function. Actual Results: The GUI overrides the text configuration, even though the GUI checkbox mirrors the text configuration. Expected Results: Have the window geometry feature be enabled and disabled to match a setting in ~/.config/kwinrc. Have the GUI include options for both implementations with full text config compatibility, since they are different: - light implementation shows only window dimensions, like other window managers - dark implementation shows dimensions and coordinates In OpenSUSE: The GUI setting enables the dark implementation and overrides the light one. It properly writes to the 'windowgeometryEnabled' key under [Plugins]. It can be disabled with 'kwriteconfig --file kwinrc --group Plugins --key windowgeometryEnabled --type bool false'. If it is disabled, the light implementation can be turned on and off only through the 'GeometryTip' key. In Kubuntu: The GUI setting enables the dark implementation and overrides the light one. It improperly writes the setting to 'GeometryTip' under [Windows]. The GUI checkbox will mirror the 'GeometryTip' key state if kwinrc is changed, but the feature will still be enabled. It can only be disabled by checking and unchecking the GUI checkbox. Changing a 'windowenabledGeometry' key under [Plugins] has no effect in Kubuntu.