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)
Summary:
This is a proposal to modify the profile shortcuts behaviour:
instead of opening a new tab with the corresponding profile
they now switch the profile of the current terminal display.
FEATURE: 319926
Reviewers: #konsole, hindenburg, tcanabrava
Reviewed By: #konsole, hindenburg
Subscribers: loh.tar, konsole-devel
Tags: #konsole
Differential Revision: https://phabricator.kde.org/D17374
Summary:
Great part of the code inside saveShortcuts and saveFavorites
is similar, extract it to a new function and call it.
Test Plan: Edited shortcuts, saved, saves where correct.
Reviewers: hindenburg, #konsole
Reviewed By: hindenburg, #konsole
Subscribers: konsole-devel
Tags: #konsole
Differential Revision: https://phabricator.kde.org/D13539
Summary:
If anything throwed we would have a memleak,
this is smaller and safer.
Reviewers: #konsole, hindenburg
Reviewed By: #konsole, hindenburg
Subscribers: konsole-devel
Tags: #konsole
Differential Revision: https://phabricator.kde.org/D13538