With the plastik window-deco the [?] button is replaces by some horizontal space (like a seperator, if you configure the window-buttons), when its not used, while it was replaces by nothing at all in kde 4.9.x. I think the KDE 4.9 behaviour is more desirable. Reproducible: Always Steps to Reproduce: 1. Use Plastik as kwin Style 2. Configure your buttons to include [?] (Help-Button) 3. Open a window with, and one without help-button Actual Results: too much space between the button before and the button after the help-button on windows, where there is no help-button Expected Results: just no button at all.
Created attachment 79609 [details] screenshot of the problem At top you see the problem. At bottom everything is alright, because this window has a help-button. The horizontal space after the button / the horizontal space replacing the button is intentional and configured by me. I wanted both window-decoration to look like the lower one.
No idea whether the current behaviour was intended, but in general fixed offsets are a good idea because they prevents you from actually having to inspect the button to figure which it is on this window. As an alternative i'd suggest a "disabled" look instead of a spacer (keeping also the general look)
Ah, for the title/description: I tested it, the problem seems only to happen with "Plastik" Decoration. Some decoration do not support the help-button at all, others get it right. I do not think a disabled look is appropriate, because the general behaviour (for example on windows and other WMs) is to completely hide the button, when its not available. This is useful, because most windows do not have this button, and only some utility-windows do have it.
(In reply to comment #3) > This is useful, because most windows do not have > this button, and only some utility-windows do have it. I rather meant keeping fixed positions in general. Windows does not, but eg. OSX does (while i doubt there's a "what's this" button, but unless there's only the close button, either the minimize or zoom button will just be disabled) As for the "what's this" and some other buttons, i'd strictly promote the Bespin approach to stack them in one button and scroll through them at (rare) demand ;-)
still applies for Aurorae as of 5.2. I'm not sure yet whether I want to fix it.
Linking in HIG: @Thomas P (or anyone you'd like to consult ;-) The core question is "what to do with disabled titlebar buttons" (eg. if a window cannot be maximized) - show the disabled button - hide the disabled button - replace the disabled button with a gap One may simply argue that Plastik (as windows) traditionally just hid the button, but imo. it's rather important to sport a common behavior among at least all stock decos, so this should follow a general pattern (breeze, oxygen, plastik)
adding some more information: breeze hides the button.
Thank you for calling me in, Thomas! If a button in a UI becomes temporarily unavailable because of some situation-specific circumstances, it should be disabled and get a tooltip explaining these circumstances. The buttons in window decorations, however, are usually not temporarily unavailable. either a certain window has a button or it doesn't. Therefore, users won't "miss" buttons which are not there, and they can safely be hidden. As for the placeholder gap: Whether that's useful or not actually depends on the user's button configuration. Users who - for whatever reason - place "exotic" buttons like the ?-button between more common ones (like close or minimize) may find it irritating that the more common buttons "jump around" between windows which have the exotic buttons and those who don't. For the rest of us, the placeholder doesn't provide much benefit. However, I don't think many users place exotic buttons between common ones, as it makes more sense to put the common buttons towards the edge of the deco and the more exotic ones more towards the center anyway. Therefore I think we'll annoy less users if we just hide buttons which are unavailable on a certain window completely. Where should we document this?
all right, given that I am going to try to fix Aurorae. > Where should we document this? in the API documentation of KDecoration?
(In reply to Thomas Pfeiffer from comment #8) > Users who - for whatever reason - place > "exotic" buttons like the ?-button between more common ones (like close or > minimize) may find it irritating that the more common buttons "jump around" > between windows which have the exotic buttons and those who don't. Please notice that this is not limited to exotic buttons, "close" and "minimize" may be and "maximize" will regularily be disabled (for fixed maximum/size windows, some dialogs etc.)
(In reply to Thomas Lübking from comment #10) > Please notice that this is not limited to exotic buttons, "close" and > "minimize" may be and "maximize" will regularily be disabled (for fixed > maximum/size windows, some dialogs etc.) I'd say two groups of behavior: * might change during life time of window (e.g. maximize) * might not change during life time of window (e.g. quick help) And I'm not sure whether the same rules would apply. For a disabled maximized I'd expect the button to be there, but not for a disabled quick help.
What about a setting for the behaviour? For fixed behaviour: i think the close button should never be hidden, only disabled, as its almost there, in the sense that the user expects it to be there and needs an explanation if its not there. The help button should mimic the windows behaviour of just being there if needed, as a disabled button suggest that the help will be enabled in the lifetime of the window after some action. btw: how often is a close button really disabled (and not just ignored by the program)?
(In reply to Martin Gräßlin from comment #11) > I'd say two groups of behavior: > * might change during life time of window (e.g. maximize) > * might not change during life time of window (e.g. quick help) > > And I'm not sure whether the same rules would apply. For a disabled > maximized I'd expect the button to be there, but not for a disabled quick > help. Oh, I just realized that I actually expected _too little_ about what's technically possible. I had originally thought that it would make sense to disable (plus tooltip) those buttons that may become enabled or disabled based on the situation and only hide those that are either there in an application or not, but I thought "How is the KWin/the windeco supposed to know that?" so I abandoned the idea. If, however, the windeco _can_ know whether the button is temporarily or permanently unavailable, then of course temporarily unavailable buttons should be disabled and permanently unavailable ones should be hidden.
(In reply to Thomas Pfeiffer from comment #13) > (In reply to Martin Gräßlin from comment #11) > > I'd say two groups of behavior: > > * might change during life time of window (e.g. maximize) > > * might not change during life time of window (e.g. quick help) > If, however, the windeco _can_ know whether the button is temporarily or > permanently unavailable, then of course temporarily unavailable buttons > should be disabled and permanently unavailable ones should be hidden. *cough* "might" *cough* Actually every button *might* be temporarily unavailable - it's more a matter of likelihood. But *usually* a feature will be available or not for a window as long as it exists - and it's not predictable whether the eg. the client will later on release the size constraints. @Martin I'm actually not sure about esp. the context help here - a client could pot. provide it depending on which kcm is currently loaded or which tab is the current in a QTabWidget - I didn't find a comment on whether WM_PROTOCOLS must not be updated after mapping.
I have now adjusted Aurorae in the linked review request for quick help and on all desktops. > I'm actually not sure about esp. the context help here - a client could pot. provide it depending on which kcm is currently loaded or which tab is the current in a QTabWidget - I didn't find a comment on whether WM_PROTOCOLS must not be updated after mapping. no idea either. The feature is KDE/Qt specific, so probably looking at Qt's code would be the best solution to get the intended behavior. Also it would be easy to change Qt's implementation to fit what we expect.
The HTML problem seems fixed, but other characters can still break stuff. Example URL: http://www.robotinabox.de/was-tun-wenn-schueler-autismus-haben%E2%80%A8%E2%80%A8%E2%80%A8/ xprop output for the title: WM_ICON_NAME(COMPOUND_TEXT) = "Was tun, wenn Schüler Autismus haben?\342\200\250\342\200\250\342\200\250 | Marlies Hübner - Mozilla Firefox" affected versions: - 4.14.2 (debian jessie) - 5.6.4 (neon-useredition-20160609-0826)
4.14 tested with plastik decoration, 5.6 with all defaults of the live cd.
Ooops, wrong bugreport. Sorry.
This issue report is quite old. Can you please confirm, that it still persists with KDE 5.23?
It still happens