Version: 2.1 (using Devel) Installed from: Compiled sources OS: Linux Hi, I've already raised this issue in bug #162444 but I think it deserves a seperate wishlist bug report. Inheritance of profile settings leads to totally unwanted and unpredictable behaviour since you can't tell which profiles are affected by changing another. A profile should be an isolated set of settings! In addition, here's what I wrote about it in #162444: "This is a very bad idea!!! How are you supposed to know which profiles are affected, if you're changing a profile? Neither the parent nor the children of a profile are listed anywhere! The results of changing a single profile are completely unpredictable unless you remember the complete history of profile relationships (do you?)! And then there are some questions of consistency: Do changes cascade down to grandchildren as well? (Answer: Sometimes!) How is a parent-children relationship tracked? By name? (If I delete the profile "MyProfile" and create a new one called "MyProfile" is it still considered the parent of "Child of MyProfile" even if it's not?) I played around a bit. After a couple of changes in different profiles with even a clear relationship, i.e. parent-child-grandchild, I was in complete confusion!" Kind regards, Felix
> A profile should be an isolated set of settings! I disagree. I think it is useful not to have to change a setting in every profile if you decide that you want to make a global change. The UI does not currently make the inheritance explicit and I think it should.
Hi Robert, Robert Knight wrote: > ------- Additional Comments From robertknight gmail com 2008-05-22 18:38 ------- >> A profile should be an isolated set of settings! > > I disagree. I think it is useful not to have to change a setting in every profile if you decide that you want to make a global change. Well, I disagree with you again. A global change shoud not be achieved by profile inheritance. There could be something like "Change Multiple Profiles" in which you can choose the set of profiles you want to change. The only time when settings should be directly inherited from the parent profile is when you create a new profile. Every setting should be taken from the current profile. Any inheritance from the parent at a later time will lead to unpredictable and often unwanted side effects. Here's another example: You have one profile "Parent" with say 7 children. One month later you decide to change the font in Child2 and Child4 and the font size in Child6, Child1 and Child3. Since you didn't actually call the profiles "Child[1-7]" in the course of the next year you forget about the parent-child relationship of the profiles. Then some day you want to change the font and font size in Parent and _only_ in Parent. With profile inheritance you'll be confused to find out that you have to re-adjust the font in some of the children andt the font size in others. In other words, instead of just adjusting the font/fontsize in only one profile you put yourself in a position where you have to 1. Find out which profiles were affected 2. Find out what settings of the child profiles were affected 3. Readjust settings in 7 child profiles (not to mention the grand and grand-grand children) - (BTW, would you know the font you used before?) A lot of collateral damage, don't you think? > The UI does not currently make the inheritance explicit and I think it should. If you can come up with a proper GUI representation of the profile inheritance I'm on your side. But I can hardly imagine how this could be achieved in a user friendly manner. A proper UI representation should be able to display which profiles inherits which settings from which profile. Essentially, you would need something like an inheritance tree view for every single setting, since not every setting is inherited from a parent. A little complicated, isn't it? IMO, you're better off introducing something like "Change Multiple Profiles" or "Apply Changes Globally" or "Apply Changes to multiple profiles". Kind regards, Felix
Hi again, fexpop@onlinehome.de wrote: > How is a parent-children relationship tracked? By name? > (If I delete the profile "MyProfile" and create a new one called "MyProfile" is it still > considered the parent of "Child of MyProfile" even if it's not?) judging from the "Parent=" line in a Child.profile file, I think that it is exactly as I guesses. The parent is simply tracked by a file name! If you really keep the concept of profile inheritance (which I think you should not), you'd better use a unique identifier, e.g. some random number. Otherwise, there's another source for probable confusion! Kind regards, Felix
> Since you didn't actually call the profiles "Child[1-7]" in the course > of the next year you forget about the parent-child relationship of the > profiles. The way I use profiles this confusion does not arise because the children inherit the icon of their parents - so I have, for example: Platform Platform (Release) Platform Alt Colors Platform2 Platform2 (Release) Platform2 Alt Colors or similar. In this case it is quite obvious which is the parent profile and which are the children. > There could be something like "Change Multiple > Profiles" in which you can choose the set of profiles you want to change When you understand the inheritance mechanism I think it works quite well in practice but I think removing it and instead making it possible to edit multiple profiles at once as you suggest would be easier to understand, plus renaming "New Profile" to "Copy Profile" to clarify what it does. One problem I can see with this though is how to represent conflicts when editing multiple profiles. For example, if the two chosen profiles have different font settings, what to do with the font preview label and font size slider.
Hi Robert, Robert Knight wrote: > > The way I use profiles this confusion does not arise because the children inherit the icon of their parents - so I have, for example: > > Platform > Platform (Release) > Platform Alt Colors > > Platform2 > Platform2 (Release) > Platform2 Alt Colors > > or similar. In this case it is quite obvious which is the parent profile and which are the children. No, it's just obvious for _you_ since _you_ know you were creating children as "Platformx ...". It's nothing more than your own convention. Anyways, you could only tell what are are the children, not which settings would be inherited from the parent. >> There could be something like "Change Multiple >> Profiles" in which you can choose the set of profiles you want to change > > When you understand the inheritance mechanism I think it works quite well in practice but I think removing it and instead making it possible to edit multiple profiles at once as you suggest would be easier to understand, plus renaming "New Profile" to "Copy Profile" to clarify what it does. > > One problem I can see with this though is how to represent conflicts when editing multiple profiles. For example, if the two chosen profiles have different font settings, what to do with the font preview label and font size slider. It's just like selecting a piece of text in an office program with different fonts in use: The font field in the toolbar is just empty. But you can still choose a font there. It would then be applied to the entire selection. This in mind I'd like to propose to drop the concept of profile inheritance in favour of the concept of "Profile groups": 1. A profile is an isolated set of settings - no parent anymore 2. A profile group is a set of profiles, each specified by a unique identifier. 3.1 A profile does not know which groups it belongs to. 3.2 A profile can be a member of several groups. 4. The "Profile group settings" dialog could look exactly like the "Edit profile" dialog with the following modifications: 4.1 A tab to add/remove group members (profiles) 4.2 Settings that don't make sense (like "profile name") should be removed, or altered to make sense again ("Profile name" -> "Group name") 4.3 When starting the "Edit group settings", the member profiles are parsed. Those settings common to all the member profiles are displayed as usual, those which differ are greyed out (or empty). Differing settings can still be set. 4.4 Changes made in the "Edit group settings" dialog are applied to _all _ the member profiles, no exception. 5. To keep .profile files small, a hardcoded default profile could be introduced, from which all settings, which are not explicitly set in a .profile (somehow replacing Shell.profile as the mother of all profiles). I think this approach has the following advantages over profile inheritance: 1. No confusion wether you're just changing a single profile or a couple of them. 2. No confusion wether a setting changed in a parent will change a child as well. 3. No confusion due to a gran-grand-grand...child relation. 4. It's still possible to change more than one profile at once. 5. You can easily tell which settings are common to all the group members. 6. A profile can be a member of several groups, e.g. for you're scheme of profile names you could have groups "Platform1, Platform2, Release, AltColors" providing better control over common settings. What do you think? Kind regards, Felix
fexpop@onlinehome.de wrote: > 5. To keep .profile files small, a hardcoded default profile could be > introduced, from which all settings, which are not explicitly set in a > .profile (somehow replacing Shell.profile as the mother of all profiles). This should read: [...]from which all settings are used, that are not explicitly set in a .profile file (somehow replacing Shell.profile as the mother of all profiles). Kind regards, Felix
> Settings that don't make sense (like "profile name") should be removed, > or altered to make sense again ("Profile name" -> "Group name") I think the profile name is the only setting which cannot be shared. The edit box and its label can simply be disabled. > 5. To keep .profile files small, a hardcoded default profile could be > introduced, from which all settings, which are not explicitly set in a > .profile (somehow replacing Shell.profile as the mother of all profiles). That already exists - hence the reason why Shell.profile only has a small number of values compared with the total number of options. The fallback profile is hidden from the profiles menu. "Hidden" profiles are used for other purposes as well, for example to allow settings from the command-line to override those from the current profile. > What do you think? The concept makes sense although I think that the ability to define groups would only be useful if you have a large number of profiles. To begin with at least, I think just the ability to select multiple profiles and click "Edit" would be enough. Something worth thinking about at the same time is how/whether to provide editing of settings for a particular session only. Profiles are convenient because you can create a profile per type of task or environment and then re-use them. If you make changes they are instantly applied to all sessions using that profile. The disadvantage is that at the moment there is no GUI mechanism to change settings temporarily for a single session, except for a few select settings such as scrollback options and font size. For each of those I have had bug reports where people did not understand that those settings have only a temporary effect.
> The disadvantage is that at the moment there is no GUI mechanism Emphasis on "GUI mechanism" there because there is a commandline tool, konsoleprofile, which can be used for this purpose. If you want to have session settings automatically changed when logging into a server or sourcing a particular development environment script then that tool is better suited.
Robert Knight wrote: >> What do you think? > > The concept makes sense although I think that the ability to define groups would only be useful if you have a large number of profiles. Yes, it's definetely more useful the more profiles you're using. > To begin with at least, I think just the ability to select multiple profiles and click "Edit" would be enough. That would be a good start. > Something worth thinking about at the same time is how/whether to provide editing of settings for a particular session only. Well, that's exactly why I started bug #162444. I for one was missing the ability to change the color schema temporarily (i.e for a single session), others might miss other per-session settings. Actually, I don't think the settings menu of Konsole 1.6.6 was "the worst settings menu of any KDE application" as mentioned in [1]. On the contrary, it's very handy IMO since everything's there without having to work through dozens of tabs. > The disadvantage is that at the moment there is no GUI mechanism to change settings temporarily for a single session, except for a few select settings such as scrollback options and font size. For each of those I have had bug reports where people did not understand that those settings have only a temporary effect. Well, you could try to prevent those bug reports using a MessageBox saying "The changes made apply to this session only. Don't show this message again [x]". Maybe it helps... [1] http://dot.kde.org/1179921215/ Kind regards, Felix
> Actually, I don't think the settings menu of Konsole 1.6.6 was "the > worst settings menu of any KDE application" as mentioned in [1]. The main problem was the disorganization of the "Configure Konsole" dialog and confusion over how to save settings and then later restore them because there were two different interfaces for changing settings - the menus and the "session type" dialog with some settings only found in one or the other. As far as possible in Konsole 2.x, everything is in one place. For the common case where users only have a small number of different settings for different environments I think it works much better.
SVN commit 824515 by knight: * Change behavior of 'New Profile' button to copying the selected (or default) profile rather than creating a new profile which inherits from it. Profiles created previously should not be affected. This should remove the possible confusion arising from the previously used inheritance behavior * Support editing and deleting of multiple profiles at once by selecting them in the Manage Profiles dialog and clicking 'Edit Profile'/'Delete Profile'. String changes deferred to KDE 4.2 * Fix memory leak and selection loss in Manage Profiles dialog when profiles are added/removed/changed BUG: 162461 Squashed commit of the following: commit c6c482f76c840dfa34c36c2eee32f5e2aed499e7 Author: Robert Knight <robertknight@gmail.com> Date: Thu Jun 26 00:45:20 2008 +0100 Avoid the selection being cleared when profiles are added/removed/changed in ManageProfilesDialog. Finish addition/update/removal of items when profileAdded()/profileRemoved()/profileChanged() signals are emitted by the SessionManager. commit 0125653d41738768d074bcd3c6445dd98eefa619 Author: Robert Knight <robertknight@gmail.com> Date: Wed Jun 25 11:21:44 2008 +0100 Set model in ManageProfilesDialog setup rather than ManageProfilesDialog::updateTableModel() commit 32704ba0bf076ec3c305515e350c016a7bdaf2f3 Author: Robert Knight <robertknight@gmail.com> Date: Sun Jun 22 19:42:33 2008 +0100 Avoid creating a new QStandardItemModel on every profile table update. Refactor creation/update of items for profiles. commit dcd9eb9e91d64525359561cca2f8f6f54a35a2de Author: Robert Knight <robertknight@gmail.com> Date: Fri Jun 13 19:52:33 2008 +0100 * Disable previewing of a property when editing multiple profiles where the profiles have conflicting original values for the property * Change EditProfileDialog::_profileKey to EditProfileDialog::_profile commit 020ef2d5f090a1cc2b1814c4d429051cb3cf98bc Author: Robert Knight <robertknight@gmail.com> Date: Fri Jun 13 19:28:31 2008 +0100 Add stub functions for SessionManagerTest commit 655b0e6fa8e8891874ca5aa7bee6f81f3d76d065 Author: Robert Knight <robertknight@gmail.com> Date: Fri Jun 13 19:27:03 2008 +0100 Include KDE 3 profiles when displaying available profiles via "konsole --list-profiles" Re-use SessionManager::availableProfilePaths() to get the list of all profiles to load in SessionManager::loadAllProfiles() commit 93c02e6312c8a38d89a137c7260183dcf86946fa Author: Robert Knight <robertknight@gmail.com> Date: Wed Jun 11 04:02:26 2008 +0100 Export SessionManager class for testing. commit a35eaba16cad3a3301a4636d032d789df669df9e Author: Robert Knight <robertknight@gmail.com> Date: Sat May 31 22:34:33 2008 +0100 Add SessionManager test stub commit 347dadcd1c50157eb264bbb17423003a658bd8f5 Author: Robert Knight <robertknight@gmail.com> Date: Sat May 31 22:17:43 2008 +0100 Display profile names in 'Name' field when editing multiple profiles. commit 4d8e895fd9c95dbd954e224edcbcd68c24429bad Author: Robert Knight <robertknight@gmail.com> Date: Sat May 31 22:06:49 2008 +0100 Add test for Profile::asGroup() commit 527535f7786d5c7744436012dbbd889348cec6a1 Author: Robert Knight <robertknight@gmail.com> Date: Sat May 31 21:58:15 2008 +0100 Limit length of dialog caption when editing many profiles. commit eb6e199e6e130b7b33ff97f124162dbb2107bba1 Author: Robert Knight <robertknight@gmail.com> Date: Sat May 31 21:50:53 2008 +0100 Re-insert accidentally removed if() condition to check that deleted profile is not the default. commit e11d4d7dac1ae1df4c401a04e8497521f240d8f0 Author: Robert Knight <robertknight@gmail.com> Date: Sat May 31 20:32:01 2008 +0100 ManageProfilesDialog formatting tidy-up. commit 69dd69a9aa8df9dfa4f1473e53b99e17898c8549 Author: Robert Knight <robertknight@gmail.com> Date: Sat May 31 18:57:40 2008 +0100 When updating a profile group via SessionManager::changeProfile(), update the group's properties before calling changeProfile() on the group's members. Otherwise the profile group's property values will be out of sync with those of the member profiles. commit d74de728f0c19ca9786f2429fbd819938eaabe3e Author: Robert Knight <robertknight@gmail.com> Date: Sat May 31 18:56:04 2008 +0100 Add updated Profile.h missing from previous commit. commit 67f6ec24f6871a931d3b80cc11313a1c0c8fd240 Author: Robert Knight <robertknight@gmail.com> Date: Sat May 31 18:54:06 2008 +0100 Make profile groups hidden by default. commit f4653c6953b356107ab347f173e8d04296abcbac Author: Robert Knight <robertknight@gmail.com> Date: Sat May 31 18:41:49 2008 +0100 When modifying a profile group with SessionManager::changeProfile(), iterate through the group's profiles and call changeProfile() on each of them. Otherwise the profiles in the group are not saved to disk when they are updated. commit cc3c14e3c2d43f75591396b154e6b6f4b430d9a9 Author: Robert Knight <robertknight@gmail.com> Date: Sat May 31 18:35:24 2008 +0100 Add Profile::asGroup() convenience methods which return the profile dynamically cast to a Profile group. commit e2db97ee0bcb4bb3f4a8d7356846c37a04708c88 Author: Robert Knight <robertknight@gmail.com> Date: Sat May 31 03:43:20 2008 +0100 Make profile group hidden, prevents creation of nameless '.profile' file on disk. commit 872113584bce97ae739a7ba46d02ee2d63f2990d Author: Robert Knight <robertknight@gmail.com> Date: Sat May 31 03:22:45 2008 +0100 Clear corresponding shortcuts when deleting a profile. commit 0c9353ffde887ac408d87c258587d84cfa2a4d6f Author: Robert Knight <robertknight@gmail.com> Date: Sat May 31 03:08:47 2008 +0100 KDE4ProfileReader - Check that profile exists before trying to load it with KConfig commit af7caa25931684da0d8f0f495d5acab8e6de1b41 Author: Robert Knight <robertknight@gmail.com> Date: Sat May 31 02:57:50 2008 +0100 Fix enabling/disabling of buttons in ManageProfilesDialog when number of selected rows changes. commit d98184d6684cd9a58a702ab2b23bfa0105f25a0f Author: Robert Knight <robertknight@gmail.com> Date: Sat May 31 02:44:51 2008 +0100 Add a test for Profile::clone() commit b536355cde13523f12ed927b9a5e64b63954f21c Author: Robert Knight <robertknight@gmail.com> Date: Fri May 30 02:58:03 2008 +0100 Implement testProfile(), testProfileGroup(). Export Profile class for use in tests. commit 8458de3fffe3755cd5ba9ebdda5795a422cfcb5f Author: Robert Knight <robertknight@gmail.com> Date: Fri May 30 02:01:42 2008 +0100 Tidy up Profile docs. commit 6ed40ae0adc6128057b7d1c71c4bbb1259768102 Author: Robert Knight <robertknight@gmail.com> Date: Fri May 30 01:53:02 2008 +0100 Push ProfileGroup::isPropertyValueUnique() up to Profile::canInheritProperty() commit b992e0268c1708814a5843b13e321b9b4a86c05a Author: Robert Knight <robertknight@gmail.com> Date: Fri May 30 00:30:45 2008 +0100 Add Profile test stub. commit 7c7b63e50a2bb7bcd7a26d895e77860b6a5effde Author: Robert Knight <robertknight@gmail.com> Date: Thu May 29 06:12:52 2008 +0100 Document ProfileGroup commit 838a628dd395bdaf6ae04fb027b1efcccbbe9f32 Author: Robert Knight <robertknight@gmail.com> Date: Thu May 29 01:26:48 2008 +0100 Remove unused and incorrect Profile::terminal() commit 87e1ad1174ffa8fd1bafe37b4d52c9782708c9ea Author: Robert Knight <robertknight@gmail.com> Date: Thu May 29 01:23:52 2008 +0100 Remove unused kDebug() statements. commit 56c78128f083ef846308a09038251786677dd087 Author: Robert Knight <robertknight@gmail.com> Date: Thu May 29 01:22:41 2008 +0100 Profile documentation corrections. commit 965803c401692720c57a65bf1534f774e1b99365 Author: Robert Knight <robertknight@gmail.com> Date: Thu May 29 01:10:23 2008 +0100 Document SessionManager::fallbackProfile() commit a222673b15f6e8c8bb53e95046ee786369deb127 Author: Robert Knight <robertknight@gmail.com> Date: Mon May 26 20:49:12 2008 +0100 Disable 'New Profile' and 'Set as Default' buttons when multiple profiles are selected. Remove incorrect comment about QAbstractItemView signals. selectionChanged() is a slot not a signal. commit e5e9db39487595d92fe2e7d3fa16cca731c417ec Author: Robert Knight <robertknight@gmail.com> Date: Mon May 26 20:19:18 2008 +0100 Change the way new profiles are created. Instead of creating an almost-empty profile which inherits from the selected profile, create a new profile which inherits from the fallback profile and then clone the properties of the currently selected profile into the new profile. commit f56cc534b2ebd691c6b3449e982c74c7e564a35a Author: Robert Knight <robertknight@gmail.com> Date: Mon May 26 20:18:14 2008 +0100 Expose the hard-coded fallback profile in the SessionManager commit b00327479d222be60484bd781a131598f2c2482f Author: Robert Knight <robertknight@gmail.com> Date: Mon May 26 20:17:35 2008 +0100 Add method Profile::clone() to copy an existing profile, optionally copying all properties or just those differing from the current values. commit 951620449c3a621d38f6607c0ea44e2a1a0ac087 Author: Robert Knight <robertknight@gmail.com> Date: Mon May 26 19:24:49 2008 +0100 Treat a ProfileGroup with only one profile the same as a standard Profile in EditProfileDialog. commit ecdf120b67a6b14a871cd808654fe6653bb56aeb Author: Robert Knight <robertknight@gmail.com> Date: Mon May 26 19:24:08 2008 +0100 Make ProfileGroup instances with only one profile behave the same as a standard Profile with respect to 'unique' properties such as Name and Path. commit f72040f310946f92eff318c52da706fce00fa17e Author: Robert Knight <robertknight@gmail.com> Date: Mon May 26 19:14:27 2008 +0100 Fix double-deletion of profile group. commit 1523239e9cbde518eb89fc70e6711463a7f7bb2a Author: Robert Knight <robertknight@gmail.com> Date: Mon May 26 18:57:17 2008 +0100 Only look at indexes in column 0 when retrieving the selected profiles. commit 5706a8ee16bc1b87777563023e4ddf5253815c48 Author: Robert Knight <robertknight@gmail.com> Date: Mon May 26 18:52:47 2008 +0100 Move to next property when skipping a 'unique' property. commit 803eef6767620dd7a6e9b87cc97f1c110dfa66a6 Author: Robert Knight <robertknight@gmail.com> Date: Mon May 26 18:49:20 2008 +0100 Modify Edit/Delete actions in ManageProfilesDialog to allow editing/deleting of multiple profiles. commit eec6947620d51b2a41ed74a03e1a7b695d0ee811 Author: Robert Knight <robertknight@gmail.com> Date: Mon May 26 18:48:36 2008 +0100 Modify EditProfileDialog to show a different caption depending on whether the passed in profile is a single profile or a group of profiles. Disable the profile name edit and label when editing a group of profiles. commit 13ee83b2bb888da4009bee0cb25926fc02f34701 Author: Robert Knight <robertknight@gmail.com> Date: Mon May 26 18:47:22 2008 +0100 Add ProfileGroup class which provides a composite allowing multiple profiles to be treated as one. commit 1310a4ee66e6ba9eb91f1a0dfd79c5415c3a9f4f Author: Robert Knight <robertknight@gmail.com> Date: Sun May 25 00:07:47 2008 +0100 Undo string changes in Manage Profiles dialog so that this branch can be merged before 4.1 commit edc46b4085d61d1cc14a47c429aac5fc9f52a59f Author: Robert Knight <robertknight@gmail.com> Date: Fri May 23 18:34:09 2008 +0100 Change 'New Profile' button to 'Copy Profile' to clarify how it works. Change 'Edit Profile' to 'Edit' and 'Delete Profile' to 'Delete' to clarify that they can work on more than one profile. M +63 -13 EditProfileDialog.cpp M +4 -2 EditProfileDialog.h M +125 -90 ManageProfilesDialog.cpp M +16 -8 ManageProfilesDialog.h M +3 -3 ManageProfilesDialog.ui M +73 -1 Profile.cpp M +124 -50 Profile.h M +41 -10 SessionManager.cpp M +10 -3 SessionManager.h M +9 -1 tests/CMakeLists.txt A tests/ProfileTest.cpp [License: GPL (v2+)] A tests/ProfileTest.h [License: GPL (v2+)] A tests/SessionManagerTest.cpp [License: GPL (v2+)] A tests/SessionManagerTest.h [License: GPL (v2+)] WebSVN link: http://websvn.kde.org/?view=rev&revision=824515