Version: (using KDE 4.0.82) Installed from: Ubuntu Packages remove "use custom titlebar button positions" a) it is completely redundant b) it makes easy task harder c) there is no real need for this checkbox
why is it redundant and unneeded?
Well, what do you need it for? Redundant -- see at the bottom of the dialog, there is "defaults" already, with undo (hopefully) it will be 200% redundant. Compare it to every other config. dialog -- you won't see "use custom toolbar" checkbox, you simply customize it. You won't see "use custom font size", you simply customize it, etc.
Yeah, I agree it's unneeded. It's kinda like having a "use custom desktop wallpaper" or something.
I agree its unneeded IF the ability to arrange title bar buttons was enabled by default, but as of 4.2.1 you can't unless you check the box.
Angel, of course the sense of my report is to remove this option and be able to configure the settings. Common sense = switch on.
Created attachment 32460 [details] Removes 'Use custom titlebar positions' checkbox, enabling by default This is my first patch, please let me know if I've made some mistake.
Please don't since this button is not redundant, but provide a major feature of window decorations. It lets the window decoration designer also decide the feel of the decoration, not only the look. The ability to customize button position is a secondary feature compared to this(Because of the frameworks flexibility it's easy to add, and only there as an extra convenience for the users). For some decorations this ability is a major part of the design. If the button is removed, to keep this feature the custom button position configuration must move to each styles configuration. This will mean that all styles initiate to their default value, rather than what the user selected for the previous chosen style. IMHO this will be more confusing than today's simple interface. By only removing this option you effectively break the design of several(half) styles currently in KDE, not to mention potentially any 3rd party styles. Of the current styles supplied with KDE, this affects B II, KStep, Laptop, Modern System, Quartz and Web.
> It lets the window decoration designer also decide the feel of the > decoration, not only the look. The ability to customize button position is a > secondary feature compared to this So in order to follow the designer idea, please do not customize your KDE. That's it. It is surprising you are advocate of keeping it because if it is valid what you said you should argue to add "customize colors" checkbox in colors module, "customize hotkeys" checkbox in hotkeys module and so on. If you don't want customization, keep default values. If you want to customize, customize. Middle-level "safety" checkbox is just an obstacle.
If you remove this option, please add a button to reset the button order to decoration defaults, because every decoration provides its own default button order.
It should be solved SS-wide (see: defaults).
> So in order to follow the designer idea, please do not customize your KDE. No, that's why there is an customize option in the first place. But window decorations are more than looks. > That's it. It is surprising you are advocate of keeping it because if it is > valid what you said you should argue to add "customize colors" checkbox in > colors module, "customize hotkeys" checkbox in hotkeys module and so on. > That's straw-man, it seems like you fail to realize that every style are different having it's own default. There is not one default, the default would then give different result depending on which style you are currently configuring. IMHO much more confusing and unexpected for users. > If you don't want customization, keep default values. Exactly, and decorations have different default based on the designers vision regarding the styles feel. > If you want to customize, customize. Exactly, and you most likely want your customization to be the same across styles. > Middle-level "safety" checkbox is just an obstacle. No, more like high level feature. It removes the obstacle of needing to customize every style to match your preference, and an easy way to change between it and the way the designers intended it to behave.
> > If you don't want customization, keep default values. > > Exactly, and decorations have different default based on the > designers vision regarding the styles feel. Great, checkbox not needed then. > > If you want to customize, customize. > > Exactly, and you most likely want your customization to be the same > across styles. And checkbox not needed then. Problem solved. There are only two cases -- either you would like to keep the defaults (then checkbox is not needed because you don't customize the settings) and there is second case when you would like to change it. In order to do so, currently you have to click on the checkbox and then customize settings. So there is one useless step. There is another issue -- being consistent. It is the only place in KDE where this useless checkbox is added and middle step for customization. So this is bad also from general UI POV -- KDE UI should be uniform. If you don't agree please provide real example when this fails.
You cannot revert to the defaults of your currently selected windeco. If you use the "default" button everything will be reset to default including the selection of your windeco. So if you used plastik with a custom button order and you want to reset to default plastik button order, you will get ozone in default button order, when you click the default button. The checkbox is adding this "revert to default for selected windeco".
I know you cannot now -- but this should be solved at SS level. Adding such ugly hacks as this checkbox is not real solution. And win decorations is not the only multitab module -- every multitab module has this problem that "defaults" reverts too many things.
So currently we have a clear dependency. As long as Systemsettings (or to be precise KCM) does not provide a default per tab button, the patch cannot go in as it removes functionality.
Not really, _with_ this patch KDE is uniform finally, not otherwise. _With_ this patch customizing the decoration is more intuitive. This report is marked as wish, but really it is flaw in UI. Adding new features should not block fixing flaws.
(In reply to comment #16) > This report is marked as wish, but really it is flaw in UI. Adding new features > should not block fixing flaws. Yes this might be a flaw. And removing this flaw will result in a regression. And IMHO it's better to have a small flaw in the UI then to have a regression. So let's be constructive again: what about removing the checkbox and therefore adding a button "Revert to decoration default" at the same time? That would remove the flaw without breaking existing functionality.
Martin, as I said before we should remove ugly hacks. "Revert decoration" would have sense only at this section, and nowhere else. So it is changing inconsistent UI to another inconsistent UI. I am thinking about something that could be applied everywhere, I will post mail to usability ML about it soon. Nikhil sent really useful patch and I don't understand why there is such resistance, it is step in the right direction, I hope nobody denies that.
and now we have reached the point where it is the question if usability is just about removing features. Usability should improve UI, but never ever remove features. And please don't do the mistake to tell me off, because I'm not an expert in UI designing or usability. I know quite a lot of it and I just disagree in some points. I don't oppose to any patch that does not remove existing functionality. I even agree that this interface is absolutely terrible and if you have an idea for improvement, for redisgning this particular UI, please go ahead. But removing features is just not an option.
Flaw in UI is not a feature, it is a bug. And I am quite pretty sure that we wasted already more energy than it costed the user trouble :-D
(In reply to comment #20) > Flaw in UI is not a feature, it is a bug. And I am quite pretty sure that we > wasted already more energy than it costed the user trouble :-D But you are wrong, there is no flaw in the UI. And it even does it job in a very clear and efficient way. I doubt very much it cause any users any trouble what so ever. The dialog and the option is different, or inconsistent as you call it, with other dialogs simply because it has functionality no other configuration dialog has. You have to realize, it does not have A default, KDE4 comes standard with 11 different defaults.
I actually prefer if the checkbox remains. I simply don't agree with the original poster that it isn't necessary, because window decoration buttons behave completely differently to custom colours etc. This is why: When the checkbox is checked, if I change the window decoration theme, then the buttons change to what the designer thought would be best for the window decoration. However, if I uncheck the checkbox and change the window decoration theme, the buttons remain the way I have configured them to be, regardless of the designer's view of what is best. So if we remove this checkbox, how should changing the window decoration make the buttons behave? It would either leave the buttons as I have previously configured them, which may be the default for some other window decoration but not the one I changed it to, or it would change the buttons to what the window decoration's default button layout is, and if I configured the buttons to my own liking, I would have to change them back again, creating unneeded work. One wouldn't know what kind of behaviour to expect any more, and this would be counter-intuitive.
> This is why: > When the checkbox is checked, if I change the window decoration > theme, then the buttons change to what the designer thought would > be best for the window decoration. ? Nope. > So if we remove this checkbox, how should changing the window > decoration make the buttons behave? ? The changing of the deco has 0 impact on the checkbox. Checkbox simply _allows_ you to make the changes. If you would like to customize deco, you customize, if you would like default deco, reset the changes. There is no need (this is important part) for the third party -- guard for allowing you customization. It is the _only_ part of systemsettings (and previously KControl) which has such guard. In every other place you simply do customization. Compare it to screensaver, plasma, fonts, colors, and so on, and so on.
(In reply to comment #23) > > This is why: > > When the checkbox is checked, if I change the window decoration > > theme, then the buttons change to what the designer thought would > > be best for the window decoration. > > ? Nope. Correction: when the checkbox is UNCHECKED, that behaviour is observed. I got the two mixed up. > > > So if we remove this checkbox, how should changing the window > > decoration make the buttons behave? > > ? The changing of the deco has 0 impact on the checkbox. Checkbox simply > _allows_ you to make the changes. > The CHECKBOX has a huge impact on the behaviour of the buttons, should you change the DECORATION, not the other way round, which is why I would keep things the way they are. > If you would like to customize deco, you customize, if you would like default > deco, reset the changes. There is no need (this is important part) for the > third party -- guard for allowing you customization. > Like I said, window decoration buttons are different to other features - if you change the colour scheme, it doesn't change the widget style, and vice versa. If you change the, "active desktop borders" setting, it doesn't change the, "Window snapping" setting, etc. etc. However, if you change the window decoration, it DOES, by default, change the buttons. This checkbox acts as an override for power-users, therefore it should be kept. > It is the _only_ part of systemsettings (and previously KControl) which has > such guard. In every other place you simply do customization. Compare it to > screensaver, plasma, fonts, colors, and so on, and so on. See above. Changing one setting in plasma doesn't typically change another. Window decorations are different.
> However, if you change the window decoration, it DOES, by > default, change the buttons. Of course that after removing this checkbox some cleaning is necessary, nobody said otherwise. But it does not change the fact, user should be allowed to make the changes right away. One part is style of deco, the other part is placement of the buttons. One should not force another. Possible actions: a) customizing the buttons placement b) falling back to default placement (for given deco), i.e. reset c) changing the deco style (no change of buttons placement) ad.c) after all it is _just_ deco style, changing regular style does not change for example border width, the same should be kept here, currently it is simply inconsistent
Wasnt this part rewritten for KDE SC 4.5? Can someone confirm that this bug is still present?
> Wasnt this part rewritten for KDE SC 4.5? Can someone confirm > that this bug is still present? Yes that part was rewritten and yes the bug is still present as I do not consider it as a bug, but as a feature (see for example comment #7)
Is this bug still _open_? I think it's been unanimously decided that the checkbox stays. Can someone please set this as WONTFIX or similar?
Bulk change: move all KWin kcm bugs to product kwin