Created attachment 159518 [details] Screenshot of issue SUMMARY When window list is opened by shortcut, the menu is styled differently and is effectively useless as the window titles are truncated and the height of the menu is limited. See attached screenshots. STEPS TO REPRODUCE 1. Add a window list to a panel 2. Configure a keyboard shortcut for it 3. Hit shortcut and see uselessly formatted menu OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Operating System: Kubuntu 23.04 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.0-20-generic (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 1600X Six-Core Processor Memory: 15,5 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 980 Ti/PCIe/SSE2 ADDITIONAL INFORMATION
Can confirm.
Looks like what happens is that the widget has a FullRepresentation that opens when it's activated via keyboard shortcut, as with all such widgets. But when clicked, the button eats the click and handles it in a custom way to show a menu, rather than showing the FullRepresentation. Fixing this by removing the menu-based pop-up would be easy, but would degrade the intended UX which is to pop up a thing that looks and feels like a desktop-style menu. I'm looking into whether it's possible to catch and redirect the activation signal sent by the keyboard shortcut.
Can't find an activation signal to bind to. Either I missed it or it would have to be added somewhere. Ivan, do you know of one?
I'm not a user of this applet, but I will give it a look. Normally, launching an applet via its configured shortcut expands compact applets into their full representation; while regular mouse clicks can be handled by MouseArea to execute arbitrary code — for example open up a native menu.
One possible workaround would be to have a single (default) representation only, which internally decides whether to show an icon or a list based on applet's form-factor and size. In that case, there won't be second representation to open on activation by shortcut, and we *might* be able to handle activation in a different way then.
Thanks for looking! Not a high priority, don't kill yourself over it, especially if it's not a quick fix.
I'll add a pain point not yet mentioned for this bug: When clicking the window list widget, the (app-style) menu can be navigated with tab, shift+tab, up, down, and enter. But the Plasmashell-style menu cannot be navigated with those keys. If this were fixed, the widget could be used as a keyboard-driven task-switcher alternative. I set the shortcut to super+tab in order to use it this way, but encountered this bug. I think it's worth noting that the user-facing description of the shortcut is "Activate widget as if clicked."