Fixes the following crash
- Open Settings -> Manage Profiles...
- Click on a non default profile and edit it
- In "Edit Profile Dialog", check "Default" to make this profile default
- Click Ok, Now we are back in "Manage Profiles" dialog.
- See that "Set as Default" is still clickable, clicking it crashes konsole
BUG: 423136
BUG: 445173
BUG: 454986
Currently Konsole has its tabs on the bottom of the window. This is
nonstandard; few to no other main views in KDE apps have their tabs on
the bottom in the same manner.
In a productivity-focused app like Konsole, there could be an argument
for this being more Fitts' Law compliant, because tabs on the bottom
would touch the bottom screen edge when the window is maximized or
tiled and there is no bottom panel, making access via pointing device
fast. But... Plasma does have a bottom panel by default, so a person
would have to change their settings to realize this gain anyway. Such
a person could change their tabs to be on the bottom themselves.
There aren't strong reasons for putting the tabs on the bottom, so
let's move them to the top to match the behavior and appearance in
other KDE apps.
* 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
kpty code is (as of now) unix-only, so konsole as a whole cannot
possibly work on windows (without a thick emulation layer). therefore,
remove the pointless #ifdefs that only reduce the code's legibility.
- 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.
Currently there are two options to control menubar visibility: the first in the menu and the second in the preferences dialog, moreover the second option makes the changes persistent. This MR removes the second option (from the preferences dialog) and makes the first option (from the menu) make the changes persistent.
BUG: 440328
This is similar to commit c413d543c1, EditProfileDialog's base class
(KPageDialog) already connects OK button clicked signal to accepted() signal;
creating another connection to accepted() in SessionController (which
creates the EditProfileDialog object), means the code will be run twice, not
ideal. Instead put the logic in EditProfileDialog::save() which is called by
the EditProfileDialog::accept() slot.
The same goes when ProfileSettings creates an EditProfileDialog.
When you open settings and close it, than open a new window, than
close the old window, the MainWindow with the settings will
delete the configDialog. If you try to open settings againg it crashes.
Fix is each MainWindow now has its own configDialog.
BUG: 436366
Now when creating a new profile, the title will be "Create new profile",
this is less confusing when the user tries to edit e.g. the Fallback profile,
which in effect will create a new profile as the Fallback one is immutable.
exec() creates a nested eventloop, which could lead to some nasty
crashes ...etc.
ProfileSettings::editSelected(): since the dialog is modal, the user
can't interact with the konsole window at all, so no chance of opening
another instance of the EditProfileDialog.
- If there is no selection only enable the "New" button, this fixes a
crash if you select a profile, then Ctrl+Click to unselect it, the set
as default button would still be enabled and clicking it caused a crash
- If a profile is selected, clone its properties, otherwise the fallback
profile properties will be used, this more expected
- Differentiate between a profile being deleteable and writable:
- Disable the Edit key for read-only profiles, i.e. a '.profile' that
doesn't have write permissions for the user
- Disable the Delete key for a '.profile' that is in a directory that
isn't writable for the user (i.e. a .profile can be read-only, but
still deleteable by the user)
- Change the model selection mode to single selection, that simplifies
the code, besides it looks like editing more than one profile at the
same time hasn't worked for a while, and there are no complaints AFAICS;
remove the now redundant selectedProfiles() method.
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
The code that managed the profile model currently is done
inside of the ProfileSettings, and thus unusable out
of it. Since I want to make it easier to select a profile
this needs to split.
It's also a bad code style to mix interface and code
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.
The Splitter is a great addition to konsole, but it lacked one
thing that always made KDE software proud: Configurability.
Some people like to have the header bar, some people don't,
some people prefer to have thin lines separating the views, some people
prefer to have the lines a bit thicker so it's easy to drag them with
the mouse.
This patch introduces those two settings in a new Tab on the Settings.
FIXED-IN: 20.08
FEATURE:
GUI:
CHANGELOG: Add Splitter settings for visibility and drag size
