| Summary: | No way to hide close button on tab of grouped window | ||
|---|---|---|---|
| Product: | [Plasma] Oxygen | Reporter: | Rodrigo Fernandes <rfernandes> |
| Component: | win deco | Assignee: | Hugo Pereira Da Costa <hugo.pereira.da.costa> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | minor | CC: | hugo.pereira.da.costa, kwin-bugs-null |
| Priority: | NOR | ||
| Version First Reported In: | 4.11.90 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Rodrigo Fernandes
2013-11-19 10:12:48 UTC
I'd rather not add an option for this (deeming it too much of a corner use-case). Now, I guess we could implement some "smart" hiding, a la, e.g. firefox: in firefox, the close button gets hidden for all tabs except the active one, when tab size becomes too small (because there are too many). Would that work for you ? Yes, that's an appropriate compromise. I any case should you wish to implement the full request, could you not reuse the settings for the presence of the close button (from configure buttons)? That is if I don't want the close window button, the tab close window button would also not appear. @Rodrigo I guess that would work too, but then I'm sure to get a bug report to ask for having the tab-close button and not the window close button ... ok. So now I also realize that the window close button is actually only closing the current tab when several windows are grouped. Maybe I need to think more about this :) > ok. So now I also realize that the window close button is actually only
> closing the current tab when several windows are grouped. Maybe I need to
> think more about this :)
maybe make the normal close button a "close window group" with maybe a dialog
asking whether that's what is really wanted like closing multiple tabs in a
browser.
Hiding the close buttons by default on the non-active tab might still be a
nice addition.
@Martin on the window close button, I agree. Now: should that go to oxygen ? Or upstream (kwin) ? (so that all tabbed decoration have consistent behavior) > Now: should that go to oxygen ? Or upstream (kwin) ? (so that all tabbed
> decoration have consistent behavior)
I'd say KWin (libkdecoration) as we need to make that in a way that we don't
run into issues with trying to decorate our own window.
>maybe make the normal close button a "close window group"
I think that would change the semantics of the closing button too much.
I've given it a bit more though and came up with the following option
A dropdown in the "configure button..." dialog
Show close button : {Always, Only on Active, Never};
Additionally to ensure the different semantics a new close all windows button would be added, which would, akin to the appmenu icon, only show up if there are tabs in the current window.
I can add some mockups if desired.
I'm also willing to implement this, provided I can have someone to ask questions about the codebase.
Presuming the close button behavior stays at it is, the only thing required is the deco to provde or interpret an option to show close buttons for each tab (as close still closes the active one) In general, i'd agree that if the deco is configured to not show a close button, it should not appear in tabs either. If this is not the case (ie. close is supposed to be generally shown) the decoration could hide the global close button in favor of the individual ones. About closing all tabbed windows by the global close button: Right now one can keep clicking the close button until the window disappears. If the close button behavior changes to close all open tabs, we'll have to ask the user (the behavior in a way differs from the one of untabbed windows) what means you click the close button and then point and click the "ok" button, ie. this will only benefit for many tabbed windows (>> 2) The question here is how window tabbing is used - open browser tabs can easily count dozens ;-) 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! 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? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone! 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! 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! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now 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 Thank you for helping us make KDE software even better for everyone! |