[Konsole-devel] [Bug 162461] Please, disable profile inheritance

[fexpop at onlinehome.de]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=162461         




------- Additional Comments From fexpop onlinehome de  2008-05-24 13:26 -------
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