Version: (using KDE KDE 3.5.8) There is no clear disctintion what "apply" does. Does it apply in the meaning -- applying changes to the selected scheme. Or does it mean -- apply scheme to the KDE? Ok, I know the answer because I tested it but current design is not clear, and it is too much focused on changing the default KDE scheme. Please: * add [set as default] button to make this clear what it does * change [discard] to [undo changes] (done in schemes definitions) * change [apply] to [save changes] (as above) * get rid of the "current scheme" -- current scheme is just a scheme marked as default, besides it is awkward to edit anything (try to change scheme, peek another one, and change the scheme again, you find out you changed "default" instead of the first one) In other words -- both setting default scheme for KDE and editing schemes should be equally easy.
This would make it impossible to change the colors without saving that as a scheme, which I'm sure is not desirable. Sorry, but I don't see anything wrong here.
Matthew, I reopen this to discuss it further, because I have feeling that: a) we don't understand each other b) the goal is discussion-worthy (currently it is too easy to loose your changes and it is impossible to edit (any!) scheme in normal manner) So... your concern: > This would make it impossible to change the colors without saving that as a > scheme You mean change colors for the current KDE? Not for scheme itself, right? No, because you cannot set something that will disappear in several seconds. But there is no contrary here -- by choosing "set as default" the scheme would be saved as well (with confirmation or not). So it would be just an indication which scheme is the default one, no extra scheme for current KDE.
> Matthew, I reopen this to discuss it further Sure, I'm not against discussion :-). > currently it is too easy to loose your changes and it is impossible to edit > (any!) scheme in normal manner I don't get this. The normal scheme-editing procedure is: - pick a scheme - edit it - if you want to keep the changes, save the scheme This is how it was in KDE3 as far as I can tell, and is how I am used to scheme managers working (i.e. it is the same in Konsole and Windows' color settings). > > This would make it impossible to change the colors without saving that as a > > scheme > > You mean change colors for the current KDE? [snip] So it would be just an > indication which scheme is the default one, no extra scheme for current KDE. Right. Currently, the "current" scheme is magic, and does not need to be saved other than being active. It sounds like you are saying you have to give a scheme a name and save it in share/apps/color-schemes in order to be able to use those colors. I think this is a bad idea, for several reasons (one being you have to save to apply your WIP to KDE). > add [set as default] button to make this clear what it does The way settings in general usually work is: make some changes, hit 'apply' to apply them without closing the dialog, or 'ok' to apply and close. 'cancel' discards changes made since 'apply' (or opening the dialog if you never 'apply'd). 'set as default' cannot be done, the "default" is hard-coded into kdelibs (kcolorscheme.cpp). I think you are confusing "default" and "current"? But as I've said, the "make these settings current" button is always 'apply', this applies to *all* settings dialogs everywhere in KDE. > change [discard] to [undo changes] (done in schemes definitions) Honestly, I wouldn't mind getting rid of 'discard', but it might not be technically possible. Anyway this has nothing to do with the color kcm, you can take it up with kcmshell if you like. > change [apply] to [save changes] You can ask kde-usability to make this change KDE-wide, but that's the level it needs to be done at, for the reasons above. It sounds like what you really want is an 'undo' button that undoes the last change you made (e.g. replacing the "working scheme" with a named scheme). To try to alleviate further communication barriers: "current scheme" - the color scheme currently applied to KDE "default scheme" - the 'factory default' colors, as hard-coded in kcolorscheme.cpp "working scheme" - the colors currently selected in the dialog; becomes the current scheme if 'apply' or 'ok' is clicked
A bit scary... Matthew, it is a lengthy answer, sorry ;-) > To try to alleviate further communication barriers: Thank you! > "default scheme" - the 'factory default' colors, as hard-coded in > kcolorscheme.cpp Ok, I'll try to avoid this term. > > currently it is too easy to loose your changes and it is > > impossible to edit (any!) scheme in normal manner > I don't get this. The normal scheme-editing procedure is: > - pick a scheme > - edit it > - if you want to keep the changes, save the scheme Nope, this not work like this. But there are two issues here. Maybe I discuss minor problem here, and move to more important. * I pick a scheme * I edit it * I save it (KControl asks for name, which is incorrect, because I edit edit, save-as should ask for the name) * I don't change name, I click ok * what happens * besides this tiny little icon on the left of the name -- _nothing_, the color on the right, which was before editing white, I edited it to green is now white again So -- simply put, it does not work. But even if it would -- it is all about analogies. General principle would be like this -- introduce as few UI behaviours as possible. Good DM would have only one which would be used in _every_ app. Bad DM would have as many UIs as apps it has. There is very good concept in KDE -- project. Within a project you have several documents. Take a look at Kate, take a look at KDevelop, take a look at Konqueror (name project does not appear, but the UI concept is exactly the same). In all those programs, you can freely edit documents and if you like changes, you can save them (all). For example. And I see Colors in Kcontrol in the same way -- individual schemes are documents, all schemes together make project. So the user should be able to edit _freely_ 2 schemes at once (it is really useful) and when she/he is finished, save them both. In current behaviour you have to do this: * pick scheme A * set is as current scheme * edit current scheme a bit * save-as it * pick scheme B * set is as current scheme * edit current scheme * save-as it * pick scheme A again * ... and so on It is hardly editable not mentioning this UI behaviour is out-of-KDE-world. Now, compare it two my wish (*): * pick scheme A * edit it * pick scheme B * edit it * pick scheme A again * ... and so on * done? ok, save the schemes (*) my wish is not really "add this button, remove this button", but rather more general -- please make the Controls more scheme (one) oriented so user could freely edit any of them > > You mean change colors for the current KDE? [snip] So it would be > > just an indication which scheme is the default one, no extra > > scheme for current KDE. > > Right. Currently, the "current" scheme is magic, and does not need > to be saved other than being active. It sounds like you are saying > you have to give a scheme a name and save it in > share/apps/color-schemes in order to be able to use those colors. Yes. > I > think this is a bad idea, for several reasons (one being you have > to save to apply your WIP to KDE). You always have to store data in order to use it. It is not KControl, it is just the general rule. > The way settings in general usually work is: make some changes, hit > 'apply' to apply them without closing the dialog, or 'ok' to apply > and close. 'cancel' discards changes made since 'apply' (or opening > the dialog if you never 'apply'd). 'set as default' cannot be done, > the "default" is hard-coded into kdelibs (kcolorscheme.cpp). I > think you are confusing "default" and "current"? But as I've said, > the "make these settings current" button is always 'apply', this > applies to *all* settings dialogs everywhere in KDE. The problem is, I see it rather as an _editor_ for schemes, not just as a _selector_. So, if you ask me if Colors module is a good selector, yes, is a good editor -- no (see above). And my point is how to design it so it would be a good selector AND editor. > It sounds like what you really want is an 'undo' button that undoes > the last change you made (e.g. replacing the "working scheme" with > a named scheme). :-D Nah, I would like to edit schemes easily. I would like to merge some schemes (i.e. I edit one, I take a peek at the second, I get back to edited one, make more changes, and so on). With current design it is almost impossible. Because on every switch you loose data :-) And I cannot hit [apply] on half-baked schemes, because the moment I hit it, I could not see anything (black on black for example).
This is very old and was somehow implemented in https://quickgit.kde.org/?p=plasma-desktop.git&a=commit&h=b9e2664cc7aa50aa9e6be8368f34390bc756b73a Please open a new bug or be specific about this one if it should still be open