| Summary: | The "No Titlebar and Frame" toggle in the window context menu should be transient like all the other options in the same menu | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | guimarcalsilva |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | kde, nate |
| Priority: | NOR | Keywords: | usability |
| Version: | master | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=466107 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
guimarcalsilva
2023-02-19 21:03:59 UTC
People use this on a transient basis - giving a presentation making a screen cast and so on. A window rule would not cover this case and we would get more bug reports. (In reply to David Edmundson from comment #1) > People use this on a transient basis - giving a presentation making a screen > cast and so on. > > A window rule would not cover this case and we would get more bug reports. I'm afraid I have to disagree, David. Most applications used for those purposes have their own fullscreen mechanism, and do not require the use of that toggle, otherwise they wouldn't be usable on other DEs or Windows. What is happening here is that there's no way of bringing the titlebar back unless you have a keyboard and know the shortcut. The toggle is completely inaccessible otherwise. Can this bug report be re-opened, at least for discussing alternative solutions? I made the suggestion of only making the option available in Window Rules, but that's only one suggestion and other people might come up with other ways of making that option more easily reversible. To correct a misconception, touch users won't encounter this issue because it's not possible to show the titlebar context menu without a pointing device; pressing-and-holding on the titlebar with a touchscreen does not open a menu. So this issue is limited to adventurous right-clickers. But I agree, the internet is littered with examples of where people shot themselves in the foot over this. At a certain point a large enough collection of anecdotes becomes indicative of a usability issue. I also agree that using this for presentations seems uncommon since the most common apps you'd want to present already include their own full-screen functionality. Because this is intended for transient usage, perhaps an acceptable solution could be to show a minimizable notification that says what happened and includes a "Restore" button. People don't want to see it because it interferes with their transient use case can manually minimize it to the Notifications widget, which will ensure they remember where it went and how to get it back. People who don't want to see it because they have in mind a more permanent use case can always use a window rule. (In reply to Nate Graham from comment #3) > Because this is intended for transient usage, perhaps an acceptable solution > could be to show a minimizable notification that says what happened and > includes a "Restore" button. People don't want to see it because it > interferes with their transient use case can manually minimize it to the > Notifications widget, which will ensure they remember where it went and how > to get it back. People who don't want to see it because they have in mind a > more permanent use case can always use a window rule. Since the option is used temporarily in most cases, what if the toggle automatically got reset to normal the next time you opened the window? That toggle is the only option in that submenu that isn't transient, all the others are temporary and do not get saved between application restarts, so that would make the behavior of all options there consistent with one another. Users that need the change to be permanent will likely use window rules like they already do for all the other options there (eg. Keep Above Others or Fullscreen), but people that might enable it by accident can get back to the normal state by simply resetting the application. Oh, that's a really good idea. Then all those items are transient, and we can add a header to the menu that says something liker "Temporary changes" with all the transient items underneath it. (In reply to Nate Graham from comment #5) > Oh, that's a really good idea. Then all those items are transient, and we > can add a header to the menu that says something liker "Temporary changes" > with all the transient items underneath it. I think the transient nature of the toggles there is quite obvious considering they're grouped with actions like Move and Resize, which are transient in nature. The only odd one there is No Titlebar and Frame. There's a possibility some people could get a little confused when they upgrade Plasma and that changes, but that wouldn't be a problem for much time. New users also don't have the expectation those options should be permanent, as they usually aren't permanent in other systems. If telling people those options are not permanent really becomes a necessity, a tooltip should be enough. |