- 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".
This lets people find Konsole with some common-seeming words that they
might search for if they need to run a script or CLI program and they
aren't super familiar with Konsole or CLI stuff in general.
- More range-for
- Reverse iterators instead of java-style ones with toBack/hasPrevious
- Don't use a QSet (which is based on QHash) to hold a few items
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.
There is an inconsistence in "Find Next/Previous" icons in Edit menu and
the search bar. Make sure they are consistent whenever "Search backwards"
is checked or not.
BUG: 443244
Add a checkbox to the Edit Profile dialog to set/unset the profile as
the default profile. Responds to the Apply and Ok buttons like other
dialog settings. Unchecking (and clicking Apply/Ok) sets the fallback
profile as the default.
- refactor the code
- remove redundant includes
- change the string used in the GUI to "window color scheme", to differentiate
between it and the terminal color schemes
Add AppColorSchemeChooser class which use KColorSchemeManager to change
konsole color scheme. Inspired by KateColorSchemeChooser wrote by
Zhigalin Alexander <alexander@zhigalin.tk>.
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.
Reading the upstream code, it looks like setStyleSheet(QString())[1] will
unset any custom style sheet. This seems like a cleaner solution because
setting a stylesheet at all interferes with changing the widget colorscheme
from a dark to a light scheme or vice versa.
To test:
- open konsole
- open systemsettings and change the colorscheme to a dark one, if you're
already using a dark one, change to a light one
- widget colors are changed as expected, except for konsole tabs, which look
odd
Opening a new konsole window seems to clear the issue and the tabs look
normal again.
[1] https://code.woboq.org/qt5/qtbase/src/widgets/kernel/qwidget.cpp.html#_ZN7QWidget13setStyleSheetERK7QString
The Qt::WA_NativeWindow attribute is need so that windowHandle() doesn't
return 0, since windowHandle() is used in two places now in the code, just
always set it.
When rememberWindowSize() is false, override the Window-Maximized config
key, which maximizes the window initially.
To test:
- unset "remember window size"
- close the window and make sure the config has been saved to konsolerc
- open konsole, keep the window unmaximized, close, open -> size is restored
- open konsole, maximize the window, close, open, the window is maximized
even when rememberWindowSize() is false
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 includes the toolbar/menubar/dockwidget states (i.e. the State= config
key), and the window geometry. I was wrong to think the State= key included
the window geometry.
Depending on the "remeber window size" setting, we can apply the size saved
in the config file or the size from the profile settings (lines x columns),
which is included in MainWindow::sizeHint().
BUG: 442252
FIXED-IN: 21.12
The buttons have very long labels, which made the window too wide
or caused the toolbar to display a disclosure button to show all the
options.
This moves those buttons into a "Split View" toolbar button, which
fixes those issues and looks much nicer.
BUG: 437555
Sub-menu will always be displayed in "File>New Tab" and "New Tab" button,
even if there is only one profile to display (the built-in default).
This fixes not being able to create a new tab from "File>New Tab" menu and
long-pressing on the new tab toolbar button.
BUG: 436264
Ahmad Samir
l10n daemon script
Nate Graham
James Beddek
Nathan Sprangers
Fushan Wen
Heiko Becker
Nicolas Fella
Maximilien DI DIO
Martin T. H. Sandsmark
Kurt Hindenburg
Hannah von Reth
Eugene Popov
Thomas Surrel
Harald Sitter