* Rename everything related to built-in profile both in code and UI.
* Unified style for [Read-only] and [Default] badges in profile
manager's list model.
* Change --fallback-profile option to --builtin-profile.
* Backward compatibility: yes. If a user happened to name their
profile "Built-in", it would continue to work as normal, and even
load with `--profile "Built-in"` command line flag. It will let them
modify any property including Name; but changing the name back
to "Built-in" shows a warning and reverts the change as usual.
* Remove "This option is a shortcut for" sentence. While it is still
technically possible to pass built-in profile's magic path, this
option is not a shortcut, nor implemented as such.
* Delete extra naming conditions in ProfileManager::changeProfile,
because they could never be triggered anyway, due to pre-flight
checks in EditProfileDialog::isProfileNameValid. Automatic unique
profile names generation has been done even earlier in either
SessionController or ProfileSettings. Just as before, users will
continue experiencing a generic "A profile with the name \"%1\"
already exists." message.
Tests:
* Improve test for uncreatable file name of built-in profile.
* Add backward compatibility test for loading existing profile
named "Built-in" which also references real built-in as its parent.
BUG: 438309
The code was checking if the path ended with a specific file name, which
meant that if you have two profiles "Root Shell.profile" and
"Shell.profile", the matching is messed up because the former ends with
the latter. Instead since we're using the path, add a '/', this way we're
matching the whole file name which is the last component in the path after
the last '/'.
Thanks to the bug reporter for git bisect'ing the repo to find the culprit
commit.
BUG: 447872
FIXED_IN: 21.12.0
- Call ProfileSettings::slotAccepted() when the parent ConfigurationDialog
is accepted, so that ProfileManager::saveSettings() is called
- don't delete the ProfileSettings dialog on accept, it'll be destroyed when
the parent ConfigurationDialog is destroyed
- save the profiles' shorcuts if they were actually changed
With this commit and the previous one, there is no need for ~Part() or
~Application() to call saveSettings(), shorcuts settings are saved when
the ProfileSettings dialog is accepted and saving the default profile is
done in setDefaultProfile(). This fixes an issue where changing e.g. the
default profile is only saved to the konsolerc file when the main window is
closed.
It doesn't seem useful to delay saving to when the the MainWindow destructor
calls ProfileManager::saveSettings().
This seems to be fallout from a previous refactor to put all the global
settings dialogs in one parent dialog (ConfigurationDialog), because now
nothing actually calls ProfileSettings::slotAccepted().
- Don't use a QHash to hold a few profile shortcuts-related items, instead
use a vector of struct.
- Load profile shortcuts after loading the profiles; after commit
50041fd02e, all the profiles are loaded in the ProfileManager constructor.
Now there is no need to store the profile path as a member in ShortcutData;
and when saving the shortcut settings we can use profile->name(), since the
way the ProfileWriter works results in the filename being the
profile name + ".profile". When loading shortcuts, keep backwards
compatibility by checking for both "profile name" and "profile name.profile".
Now all the profiles are loaded in the constructor; I didn't see any
noticeable difference in loading times.
Also all the profiles are loaded anyway because ProfileList calls
ProfileManager::allProfiles() to populate the profiles menu ...etc.
I'd used a std::set with a compare function, so that the profiles are always
sorted by name ...etc, but that is wrong, as the Key type in the set is a
QExplicitlySharedDataPointer, if the QESDP is copied, its own address is
going to change, but the address of of the object it's managing (Profile)
is the same, that's why QESDP internally overloads operator== to compare
the address of its d pointer (the one returned by data()).
That meant that multiple QESDP could exist in the set, not good... (a QSet
worked because it uses a hash which is based on the address of the object
returned by data()).
So, use a vector, that is sorted by profile name (we only need to sort it
when allProfiles() is called, and when a profile name is changed).
This fixes an assert in ProfileManager::setDefaultProfile(); to test open
the profile manager and select the built-in profile and click "set default".
Add a unit test.
This is a first step in simplifying the code; since the Fallback profile
doesn't have a file on disk, it's basically a corner-case that we have to
babysit in various places in the code.
Now when the user tries to "Edit current profile", if it's the Fallback
profile, a new profile is created, with a unique name "Profile 1",
"Profile 2" ...etc. This is similar to using the "New" button in the
ProfileSettings dialog.
- Since the favourite profile feature was removed in commit 28ba920c82,
there is no need to sort profiles by menu index, this simlifies the code
some more.
- Remove Profile::menuIndexAsInt() method, now it's not used anywhere
- This also fixes an issue with sorting the the Default/fallback profile,
since commit ce31d0e235 it would be always sorted at the top of the
list (to signify that it's a special, read-only profile...etc), sorting
by menu index breaks that behaviour:
- create a new profile by editing the Defualt/fallback profile, and give
the new profile a name (Defualt is reserved of course)
- open the profile manager dialog, you'll find the Default/fallback
profile not at the top of the list, until you restart Konsole
This issue was reported by Kurt in
https://invent.kde.org/utilities/konsole/-/merge_requests/351#note_197432
Let the Default/fallback profile be shown in the Profile Manager dialog,
and disable the Edit and Delete buttons for it, it can be "cloned" by
using the New button.
BUG: 433210
FIXED-IN: 21.04
Now the 'File->New Tab' menu is updated when the default profile is
changed, i.e. the action font is made bold and the favourites icon
emblem is added to the profile icon.
A call to menu()->setDefaultAction() has been removed, as I don't see
what it serves exactly in the current code.
Reported by khindenburg in:
https://invent.kde.org/utilities/konsole/-/merge_requests/351
When saving the fallback profile to a new profile, we have to delay
calling addProfile until after a path has been set for the new profile.
This is because ProfileModel::populate calls ProfileManager::sortProfiles,
and the latter skips profiles that have path == FALLBACK/ .
This also seems to take care of duplicate entries in "Switch Profile"
menu, with respect to the fallback profile after saving.
Modify changeProfile to always work on the Profile::Ptr arg it's called
on,this is needed to be able to call setProfile from EditProfileDialog
aftersaving the fallback profile; the fallback profile is special in
many ways,most important of which is that it's never saved to a .profile
on disk, sincechangeProfile is going to give the newly saved profile a
unique name, e.g."Profile 1", we need to update the EditProfileDialog
with the new profile,so that saving settings works and actually modifies
the new profile ratherthan the fallback one. This also means that the
profile ptr that the currentSession is using will point to the
modified/saved profile and not thefallback one.
After the fallback profile is "saved" to a new profile, we init another
instance of the fallback profile, so that it's always availabe in the
"Switch profile" context menu.
Reserve the profile name "Default" for the fallback profile.
This was harder than I tought. Because of the static initialization
static linkage order, we ended up having two different values of
a static variable on the code, that where supposedly only one.
https://stackoverflow.com/questions/26547454/static-variable-is-initialized-twice
The choosen change: Use OBJECT instead of STATIC for linking also
made me fix a few other profile headers to use the correct folder.
The only real thing a favorite profile does is to be accessible
from the Settings -> Profile menu. This simplifies a lot of code
and makes the flow of settings more what the user expects.
Next: Merge ProfileManager & ProfileModel
This also allowed me to remove a few includes of Profile.h
around the codebase, that used Profile::Ptr. now the compilation
is a bit faster and also does not recompile things as often.
This reverts commit f96deb39aa.
This was anti-optimization.
QStringLiteral is a QString created at build time. Initialization of
QString with it has no overhead.
QLatin1String is 8 bit C string wrapper which needs run-time conversion
to 16 bit encoding used in QString.
This reverts commit d689ba5403.
I should have tested this more; this breaks a number of things as
switching doesn't execute the 'Command'. Since the next release is
close, let's just revert for now.
FIXED-IN: 19.08
CCBUG: 319926
The conversion to using stable_sort requires <= be changed to < to be
valid strict weak ordering (irreflexive requirements).
(cherry picked from commit b3ceeb044d)
Ahmad Samir
Friedrich W. H. Kossebau
ivan tkachenko
Laurent Montel
Kurt Hindenburg
Carlos Alves
Tomaz Canabrava
Gustavo Carneiro
Martin T. H. Sandsmark
João Eudes Lima
Mariusz Glebocki