Bug 183834 - "Keep window open when it loses focus" (lock) toggle in Plastik theme more difficult to click than it should be
Summary: "Keep window open when it loses focus" (lock) toggle in Plastik theme more di...
Status: REPORTED
Alias: None
Product: yakuake
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Eike Hein
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-09 21:39 UTC by Stephan Sokolow
Modified: 2022-12-23 06:25 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Sokolow 2009-02-09 21:39:25 UTC
Version:           unknown (using 4.2.00 (KDE 4.2.0), Gentoo)
Compiler:          x86_64-pc-linux-gnu-gcc
OS:                Linux (x86_64) release 2.6.25-gentoo-r7-20080501

In both variants of the Plastik theme, the hasp of the lock icon and the area within do not respond to clicks. This is very bothersome because it seems as if that's where I always end up clicking.

In essence, the problem is that it breaks the user assumption that a button will respond to clicks. (half of what you intuitively expect to be clickable... isn't) I have to slow down to visually confirm that the toggle responded every time I use it.

My recommendation is to simply make it respond to clicks anywhere within the bounding rectangle. (that's what's usually expected for something like that)
Comment 1 Eike Hein 2009-02-10 13:10:01 UTC
The reason for this is that in the current Yakuake UI system, UI elements are locked to their respective bars (tab bar and title bar). The Plastik theme tries to make it appear otherwise by lining up graphics to make the lock spin both bars, but the actual Qt button widget is only on one of them. It's thus impossible to make the whole lock react to clicks.

A rewrite of the skinning system to make it more flexible and allow for more sophisticated visual and interaction possibilities is a work in progress, and will be included with Yakuake 3.0. It will also resolve this problem. Support for old-style skins is likely to be dropped at that point; the Plastik theme may or may not be ported.
Comment 2 Eike Hein 2009-02-10 13:10:28 UTC
s/spin/span/, sorry.
Comment 3 Andrew Crouthamel 2018-11-02 04:26:47 UTC
Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!
Comment 4 Stephan Sokolow 2018-11-02 05:35:07 UTC
I'm still on KDE 4 (Kubuntu 14.04 LTS), which means Yakuake 2.9.9.

I don't know if that qualifes as being recent enough to satisfy the NEEDSINFO, but, given that 3.0 was supposed to be the version which fixed this, I suspect not.
Comment 5 Andrew Crouthamel 2018-11-16 02:48:52 UTC
Dear Bug Submitter,

This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version?

Thank you for helping us make KDE software even better for everyone!
Comment 6 Stephan Sokolow 2018-11-16 03:11:54 UTC
To clarify my previous response:

1. It's still a problem on Yakuake 2.9.9 (as expected, given that fixing it requires changes slated for 3.0)

2. I can't test on anything newer because I won't have time to upgrade to KDE 5 until early 2019.
Comment 7 Justin Zobel 2022-12-08 23:51:07 UTC
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Comment 8 Bug Janitor Service 2022-12-23 05:22:27 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 9 Stephan Sokolow 2022-12-23 06:25:21 UTC
Bit of a jerk move to have automated "review this now or submit to the CADT model" messages in the lead-up to Christmas.

To be honest, with this being the *second* cycle of "an entire KDE major version went by without any sign anyone's paying attention to the bug tracker on the half dozen or so bugs I reported", I've more or less been trained to never bother to report KDE bugs anymore.

...and yes, this is still a problem with the copy of Yakuake 19.12.2 I'm running on the Kubuntu 20.04 LTS I daily-drive. If you need feedback on something newer, I'll need either an Appimage or installation instructions for a Flatpak build.