konsole has repeatedly lost my no-toolbar setting, displaying (IIRC) the session toolbar. This is on git-master built using the gentoo/kde project overlay packages. I'm running on (kde/)wayland by default now so the bug is /possibly/ wayland related, tho I suspect not. I /suspect/ the problem is a race between a just-closing konsole window presumably attempting to write konsolerc, and a just-opening window presumably attempting to read it, because one of my use-cases (a recursively invoked popup pdmenu TUI tree in a successive konsole windows, one per tree level, see bug #430032 for the detail) involves a lot of that. The assumption being that the file is locked for writing by the old instance just as the new instance tries to read it, resulting in the new instance defaulting to showing the toolbar, a state which (if I've not reset the toolbar to unshown by then) it presumably saves as it quits. When it happens I have to context-click (aka right-click) on the toolbar, select unlock toolbars to get the per-toolbar option, and unselect the one that got set back to appear (IIRC the session toolbar). Doing that once is no big deal, but having it happen repeatedly if inconsistently gets irritating after awhile. After it happened a few times I took all the buttons off the toolbar so it's empty, and that is retained, but when the show-toolbar option is reset to on, it still shows the (smaller) empty toolbar. The bug is the more irritating because in that particular usage I'm trying to show a TUI menu as if it's a stand-alone popup, no windeco (kwin window rule), no scrollbar (konsole profile), no tabbar (commandline), no menu (commandline), no toolbar (general konsole preference), transparent background (kwin window rule), so the TUI menu appears bare in the middle of an otherwise 100% transparent window. Unfortunately the no-toolbar setting keeps getting lost, destroying the illusion. I tried setting konsolerc to read-only, hoping to avoid the reset being saved at least, but then konsole insists on popping up a kdialog complaining about the read-only before the konsole window appears. =:^( So after setting konsolerc back to writable I tried setting it immutable, unfortunately with the same dialog result. =:^( So now I resorted to copying konsolerc to a backup, and a $HOME/bin/konsole wrapper script that copies it back over konsolerc before doing exec /bin/konsole.[1] Altho I've not been running it long that seems to have been a usable workaround so far, but konsole shouldn't be repeatedly forgetting the no-toolbar setting in the first place. I've had no such problems with konsole losing no-scrollbar, possibly because that's a per-profile setting. That suggests a possible solution here that would be a useful added feature as well. =:^) --- [1] reverse-usr-merge via /usr -> . symlink, so the default /usr/bin/konsole is actually /bin/konsole.
(In reply to Duncan from comment #0) > So now I resorted to copying konsolerc to a backup, and a $HOME/bin/konsole > wrapper script that copies it back over konsolerc before doing exec > /bin/konsole. FWIW that has been working reliably for me for I guess 3+ months now. It's a kludge of a workaround but it's consistently working, unlike the option without the kludge.
Not sure if this is the same cause, but recently since my latest update from 20.12.3 to 21.04.0 there is now both a "main toolbar" and "session toolbar", and even though I keep having to show the menubar, unselect them to hide them, then hide my menubar again, they keep coming back. It's getting really irritating.
(In reply to nick from comment #2) > Not sure if this is the same cause [...] It's getting really irritating. I believe it is, and yes, it is. =:^( Thanks for the bug confirmation. The good news is the wrapper-script workaround is solid -- I've not had to worry about the problem since I set that up. The bad news is of course the hassle of the workaround, including remembering to manually update the backup on deliberate config change. Question: Does your use-case involve the rapid konsole closing and re-launching of my use-case that I suspect is triggering the race I believe to be the root of the problem? If so that's further confirmation of that theory. If not, the problem is worse than I suspected.
I haven't paid close attention to my use cases, but for sure this happens (just tested again): 1 - I have dozens of konsoles open. 2 - I pick one and remove the toolbars and hide the main menu 3 - Ctrl-Shift-n to open a new konsole window 4 - the new window is fine. 5 - wait a while 6 - Ctrl-Shift-n from the first konsole again, now the new window has the toolbars again. 7 - remove them in the new window 8 - Ctrl-Shift-n from the first konsole again and now the new window also doesn't have the toolbars again. That first one is peristently open the whole time. Among my dozens of other konsole windows every time I use one I remove the toolbars. I frequently open new konsoles, and randomly the toolbars start reappearing on the new ones even though the source konsole has had them removed.
(In reply to nick from comment #4) ... ... So no for-sure confirmation on the closing one and immediately opening a new one race, but dozens of konsoles and no definite negative-confirmation either, so it's possible. FWIW, while I may well have high single-digits or even plausibly in the teens of konsoles open it'd be very rare to have "dozens" open, to the point I'm not sure I /ever/ have. But of about three use-cases here, the one definitely closes/open konsoles fast enough that one closing could still be writing the config while another opens, thus producing that race I believe to be the trigger here. What we know: * The no-toolbars config option is is honored at least some of the time, so it's written and read back correctly, even if it appears to be inconsistently. * Using a wrapper script that rewrites the konsolerc file from backup before launch appears to be a solid workaround -- I've *never* seen the problem since I instituted the wrapper -- so provided konsole can read the config file, it does seem to do so and the config appears to be correctly loaded from the file (as long as it can be read). * SOMETHING is therefore inconsistently either rewriting the config, OR is preventing reading the config correctly at startup. Of course my *theory* is that it's the latter, due to the file being locked for writing by an unloading instance at the same time a newly launching instance attempts to read it, thus creating a race such that the new instance can't read the config and defaults to showing the toolbar. And that both of us use enough konsoles that it's plausible one is starting while another is quitting (definitely the case here, plausibly the case for you) would seem to support the theory. A plausible second step that just occurred to me now: While one would hope that (in this era of limited-write ssds) konsole doesn't needlessly rewrite its config /every/ time it loads, the logic could very well be that it treats *any* error reading the config file as if the file doesn't exist, implying it's a first-run, and thus writes out its default config as what it believes to be the not-yet-existing file, instead of waiting for a config change to write it out, as would normally be the case. That would explain why when it toggles back to show-toolbar, it's then consistent on every load until the toolbar is manually turned off again. While I'm not particularly comfortable reading code (and definitely not writing it, tho I I'm getting a bit more comfortable hack-patching existing code), I should take a look and see if I can figure out what it's actually doing. If it turns out it's either unconditionally rewriting the config at every load, or it's treating /any/ error reading the config as a fresh config and writing out the default config... BTW, I believe you can bug-status confirm the bug if you feel comfortable doing so. (I'd feel weird confirming my own bug, but now that you're seeing it too I believe it's confirmable.)
Looking at the config file, looks like there's specific line entries for menubar, statusbar, etc, but not for the toolbar. Presumably toolbar "state" is stored in the generic and opaque (that is non-plain-text, apparently text-encoded binary) "State" entry, probably along with a bunch of other stuff, making it rather more delicate and prone to corruption than a dedicated separate-line plain-text setting. =:^(
It's actually worse than I originally thought. Both toolbars are returning w/o any user changes being made on *active windows*. 1) Ctrl-shift-N an open konsole (that doesn't have the toolbars). 2) Sometimes this new konsole has the toolbars 2a) if it does, remove them 3) use it, keep it open 4) at some time later check it and you'll see the toolbars have magically reappeared. 5) remove them, return to 3 and repeat... They will *not* stay away.
Created attachment 139069 [details] attachment-5899-0.html konsole has no code to manage toolbars, this is handled by the kxmlgui library, I'm trying to debug this but *currently* I'm not affected. On Mon, Jun 7, 2021 at 2:42 AM <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=430036 > > nick@leippe.com changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Status|REPORTED |CONFIRMED > Ever confirmed|0 |1 > > --- Comment #7 from nick@leippe.com --- > It's actually worse than I originally thought. > Both toolbars are returning w/o any user changes being made on *active > windows*. > > 1) Ctrl-shift-N an open konsole (that doesn't have the toolbars). > 2) Sometimes this new konsole has the toolbars > 2a) if it does, remove them > 3) use it, keep it open > > 4) at some time later check it and you'll see the toolbars have magically > reappeared. > 5) remove them, return to 3 and repeat... > > They will *not* stay away. > > -- > You are receiving this mail because: > You are the assignee for the bug.
(In reply to tcanabrava from comment #8) > konsole has no code to manage toolbars, this is handled by the kxmlgui library Thanks for the pointer. I had decided it wasn't konsole here too, but in a jump of illogic concluded that meant qt, forgetting about the frameworks, and wasn't going to even attempt qt code. But kxmlgui's friendlier territory as it's both considerably smaller and and one of the "most kde packages" I'm already running live-git, so I may actually take a look at it. > I'm trying to debug this but *currently* I'm not affected. Thanks.
*** Bug 438160 has been marked as a duplicate of this bug. ***
konsole version 21.04.2 fixed the problem for me.
(In reply to Garry Williams from comment #11) > konsole version 21.04.2 fixed the problem for me. Also, kf5-kxmlgui-5.83.0-1.fc34.x86_64
I still have the same issue with latest master. And it appeared after upgrading konsole, not kxmlgui, so the bug is in konsole
(In reply to Martin Sandsmark from comment #13) > I still have the same issue with latest master. > > And it appeared after upgrading konsole, not kxmlgui, so the bug is in > konsole The upgrade was from b21938e5 to 036e4e87 fwiw. It also seems to have somehow lost/reset my default profile, and I can't seem to disable the resize hints popping up (if I turn it on it stopped for a while in new windows, but now they're suddenly back).
Also seems to happen when I updated from 6723627d to master. A bit hard to bisect because of the nature of it. I version control my konsole config, so this seems to be the relevant change Konsole in master applies to its kxmglgui rc file that breaks it fwiw: --- kxmlgui5/konsole/konsoleui.rc +++ kxmlgui5/konsole/konsoleui.rc @@ -1,6 +1,6 @@ <?xml version='1.0'?> <!DOCTYPE gui SYSTEM 'kpartgui.dtd'> -<gui name="konsole" version="14"> +<gui version="17" name="konsole"> <MenuBar> <Menu name="file"> <text>File</text> @@ -50,6 +50,10 @@ <Action name="configure-notifications"/> <Action name="configure-settings"/> </Menu> + <Menu name="plugins"> + <text>Plugins</text> + <ActionList name="plugin-submenu"/> + </Menu> <Menu name="help"> <text>Help</text> </Menu> @@ -62,10 +66,10 @@ <Action name="split-view-top-bottom"/> </ToolBar> <ActionProperties> - <Action shortcut="" name="clone-tab"/> - <Action shortcut="" name="close-other-views"/> - <Action shortcut="" name="help_contents"/> - <Action shortcut="" name="last-used-tab"/> - <Action shortcut="" name="last-used-tab-reverse"/> + <Action name="clone-tab" shortcut=""/> + <Action name="close-other-views" shortcut=""/> + <Action name="help_contents" shortcut=""/> + <Action name="last-used-tab" shortcut=""/> + <Action name="last-used-tab-reverse" shortcut=""/> </ActionProperties> </gui>
Created attachment 139897 [details] attachment-11955-0.html Martin, I don’t see anything related to the loss of visibility on the updated xml :/ On Tue, 6 Jul 2021 at 13:28 Martin Sandsmark <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=430036 > > --- Comment #15 from Martin Sandsmark <martin.sandsmark@kde.org> --- > Also seems to happen when I updated from 6723627d to master. A bit hard to > bisect because of the nature of it. > > I version control my konsole config, so this seems to be the relevant > change > Konsole in master applies to its kxmglgui rc file that breaks it fwiw: > > --- kxmlgui5/konsole/konsoleui.rc > +++ kxmlgui5/konsole/konsoleui.rc > @@ -1,6 +1,6 @@ > <?xml version='1.0'?> > <!DOCTYPE gui SYSTEM 'kpartgui.dtd'> > -<gui name="konsole" version="14"> > +<gui version="17" name="konsole"> > <MenuBar> > <Menu name="file"> > <text>File</text> > @@ -50,6 +50,10 @@ > <Action name="configure-notifications"/> > <Action name="configure-settings"/> > </Menu> > + <Menu name="plugins"> > + <text>Plugins</text> > + <ActionList name="plugin-submenu"/> > + </Menu> > <Menu name="help"> > <text>Help</text> > </Menu> > @@ -62,10 +66,10 @@ > <Action name="split-view-top-bottom"/> > </ToolBar> > <ActionProperties> > - <Action shortcut="" name="clone-tab"/> > - <Action shortcut="" name="close-other-views"/> > - <Action shortcut="" name="help_contents"/> > - <Action shortcut="" name="last-used-tab"/> > - <Action shortcut="" name="last-used-tab-reverse"/> > + <Action name="clone-tab" shortcut=""/> > + <Action name="close-other-views" shortcut=""/> > + <Action name="help_contents" shortcut=""/> > + <Action name="last-used-tab" shortcut=""/> > + <Action name="last-used-tab-reverse" shortcut=""/> > </ActionProperties> > </gui> > > -- > You are receiving this mail because: > You are on the CC list for the bug.
(In reply to tcanabrava from comment #16) > Martin, I don’t see anything related to the loss of visibility on the > updated xml :/ Nothing really stands out to me either, except the version bump and the reordering of the arguments for the actions somehow getting reordered parameters (or whatever the XML terminology is). Even more funny, I can't remove the toolbar without manually editing the konsoleui.rc. There's supposed to be a "Show toolbar" under the Settings menu, right? It's there in all other KDE applications here...
I can't test (for some reason konsole now segfaults on launch after latest pull), but the switch from setupGUI() to createGUI() in b43548b22 might be related?
Checked the kxmlgui createGUI() doc, and it seems very likely, should probably check what other stuff it sets up that we need: "In a regular app you usually want to use setupGUI() instead of this one since it does more things for free like setting up the toolbar/shortcut edit actions, etc."
(In reply to Martin Sandsmark from comment #17) > Even more funny, I can't remove the toolbar without manually editing the > konsoleui.rc. There's supposed to be a "Show toolbar" under the Settings > menu, right? It's there in all other KDE applications here... This might be dated (still on 81f1c5352 which I updated to on July 2), but here, konsole has a "Toolbars Shown" submenu, with "Main Toolbar" and "Session Toolbar" checkbox entries. So no "Show Toolbar" checkbox, it's two checkboxes under "Toolbars Shown". I think that got me when I was first looking into this bug as well.
Reverting b43548b22 Konsole both remembers whether the toolbar should be shown, and the missing options in the settings menu are back (and probably some other stuff I didn't notice). For reference, here's the code that isn't run after b43548b22, should probably copy it into konsole unless it's okay to revert b43548b22: https://invent.kde.org/frameworks/kxmlgui/-/blob/master/src/kxmlguiwindow.cpp#L262-299
Aaand sorry for the comment spamming, but b43548b22 was to work around a bug in kxmlgui which has since been fixed in kxmlgui: https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/53 So it should be safe to revert.
A possibly relevant merge request was started @ https://invent.kde.org/utilities/konsole/-/merge_requests/435
(In reply to Duncan from comment #20) > (In reply to Martin Sandsmark from comment #17) > > Even more funny, I can't remove the toolbar without manually editing the > > konsoleui.rc. > > This might be dated (still on 81f1c5352 It was. Missing the ability to turn off the toolbars after update to 26018e3aa, today. Comment #23's mr gives me back the options and turns off the toolbars again. I tried without a konsolerc to try to see if it triggered the 1px-window again, and then realized it wasn't going to be a valid test as I have kwin window-rules for konsole that set the size. Of course I could try without them too, but I think it's better just to let others test that. Meanwhile, this gave me an excuse to try commenting out my konsole-wrapper-script workaround from comment #0, to see if with the new code the bug I originally filed this on is still triggering. Short test so far but I no longer see it! =:^) Assuming the mr gets merged I'll test for a few more days and set resolved/fixed if no further problems.
*** Bug 439571 has been marked as a duplicate of this bug. ***
*** Bug 440358 has been marked as a duplicate of this bug. ***
(In reply to tcanabrava from comment #8) > konsole has no code to manage toolbars, Perhaps not, but... I install konsole5-21.04.2-3.fc34 and konsole5-part-21.04.2-3.fc34 and the bug comes back -- I cannot make the toolbars go away permanently. I downgrade to konsole5-21.04.2-1.fc34 and konsole5-part-21.04.2-1.fc34 and the toolbars are gone and do not come back. No other change was made and I did this multiple times. 21.04.2-3.fc34 introduces the bug. Downgrading fixes the bug.
(In reply to Garry Williams from comment #27) > I install konsole5-21.04.2-3.fc34 and konsole5-part-21.04.2-3.fc34 and the > bug comes back -- I cannot make the toolbars go away permanently. > > I downgrade to konsole5-21.04.2-1.fc34 and konsole5-part-21.04.2-1.fc34 and > the toolbars are gone and do not come back. > > No other change was made and I did this multiple times. > > 21.04.2-3.fc34 introduces the bug. Downgrading fixes the bug. If I'm correctly reading those Fedora version numbers the -N segment (where N is a number) is Fedora's patch-level on top of the upstream version given by the rest of the version number. If that's correct, the -2 and -3 indicate Fedora patch-levels on top of the same upstream version 21.04.2. The problem you're seeing is thus between Fedora patch-levels 2 and 3 of upstream version 21.04.2, placing it in Fedora's court. Now it is true that many distro-level patches will originate upstream, and I suspect that's the case here as well. At the upstream-kde individual git-commit level there were several sub-bugs as konsole worked around the original bug that I believe was in kxmlgui, but kxmlgui caught that bug and fixed it while introducing another, at least as seen by the work-around konsole code. It ultimately took several commits to both the konsole and kxmlgui repositories to fix the mess and clear up all the (sub-)bugs, and as of my update yesterday, the last one (the merge-request linked in comment #23, ) hasn't actually been committed yet, so upstream's still in flux. But I've been applying that merge-request as a local patch and with it, at least for me as original bug reporter, all of konsole's toolbar-handling bugs appear to be fixed. =:^) So from here you have several options: 1) Just wait, possibly keeping konsole at an unaffected -2 patch-level until a fix is available as an update beyond -3. Eventually konsole will merge that last mr and make a new release, and you'll get a fixed version from fedora, due to fedora either updating to the upstream release with the fix or doing another fedora patch-level update with the fix on the same upstream version they're using now. 2) File a fedora bug, asking them to do another patch-level bump with the mr included as a fedora patch. 3) Build konsole from sources yourself, applying the mr as a local patch to fix the problem. Note that depending on the fedora version of kxmlgui you may have to build a current version of it locally as well, and then build konsole on top of that. Should you choose to do this, you can of course do #2 as well, putting your results in the fedora bug. (Being a Gentooer it's possible my patch-level interpretation is incorrect but most distros have something similar; for Gentoo it's -rN, r for revision, example -r2, 21.04.2-r2. Of course gentooers build from source by default and the local application of random patches like that in the mr is relatively trivial, but upgrading a package is in general a lot more work than it is on a binary distro because it /normally/ means building from sources.)
The change between Fedora -2 and -3 was indeed a backport from upstream. It was a backport of https://github.com/KDE/konsole/commit/b43548b , which fixes bug #437791 (the Konsole window initially appearing at a very small size on launch).
Just to be clear, I saw this bug come back after installing (from Fedora updates-testing) konsole5-21.04.2-3.fc34 and konsole5-part-21.04.2-3.fc34. I see the bug fixed by downgrading to konsole5-21.04.2-1.fc34 and konsole5-part-21.04.2-1.fc34. The bug is fixed in the -1 version and comes back in the -3 version. I have never seen a -2 version of either package. (See my comment #27.)
ah, sorry, forgot to explain that - for the F34 branch -2 is effectively a no-op. -2 was a straight rebuild on the Rawhide branch for the Rawhide mass rebuild, it did not happen on the F34 branch. But the commit for -2 was merged into the F34 branch presumably as the maintainer is keeping those branches equal for now (this is a fairly common strategy). So still the only actual difference betweeen -1 and -3 is the same patch.
(In reply to Garry Williams from comment #30) > The bug is fixed in the -1 version and comes back in the -3 version. I have > never seen a -2 version of either package. Oops. That was my mistake. I saw the .2 and looking for a context of something before -3, was reading it as -2. (In reply to Adam Williamson from comment #29) > The change between Fedora -2 and -3 was indeed a backport from upstream. It > was a backport of https://github.com/KDE/konsole/commit/b43548b , which > fixes bug #437791 (the Konsole window initially appearing at a very small > size on launch). And yes, git b43548b was implicated in the set of commits between konsole and kxmlgui. As I said, with the patch in the remaining pr it all seems to be straightened out on master/head of both, here.
Please test https://invent.kde.org/utilities/konsole/-/merge_requests/447
*** Bug 440394 has been marked as a duplicate of this bug. ***
*** Bug 440443 has been marked as a duplicate of this bug. ***
(In reply to Ahmad Samir from comment #33) > Please test https://invent.kde.org/utilities/konsole/-/merge_requests/447 Pulled that and built with it just a moment ago. We'll see how it goes as soon as the rest of my kde rebuilds finish (under 10 to go) and I can reboot. Tho mr435 from comment #23 had fixed the toolbar problem for me, but this one (mr447) is supposed to fix other problems (that weren't affecting me) that it didn't, but as sandsmark says on the mr, "the change is a bit complex", as is this heap of intertwined bugs where the simple fix for one triggers another, so we'll see...
*** Bug 440286 has been marked as a duplicate of this bug. ***
I don't want to unilaterally change the title of this bug, but - given that half a dozen or so (duplicate) bugs have been opened in the past few weeks, complaining that the konsole toolbars can't be hidden - it may be worthwhile to come up with a better title for this bug (so people can find it). Specifically, those users weren't concerned (yet) that their no-toolbar setting wasn't persistent, they were complaining that no option exists to hide the toolbars. (when you do a search for "toolbar" with product=konsole, it appears that there are no relevant issues, since all of the closed ones are filtered out, and - from the title - this one does not appear relevant)
(In reply to Adam Batkin from comment #38) > (when you do a search for "toolbar" with product=konsole, it appears that > there are no relevant issues, since all of the closed ones are filtered out, > and - from the title - this one does not appear relevant) [Original bug filer, here.] Hmm... Personally, I'd take a look at pretty much anything with "toolbar" in the title/summary... Even if it's not the same bug it's invariably interesting and I find the often different use-cases educational. And of course I always search on closed bugs too (and sort by bug number or last modified, ignoring obviously too old bugs), /especially/ if I'm running a release version (instead of the live-git I run for kde) since with a bit of luck it's already fixed in git and I can simply apply the fixing commit as a patch (easy enough on gentoo, where the normal case is building updates from source, and applying a patch is a simple matter of dropping the patch in the appropriate dir to be auto-applied), but with two decades of running distro-testing releases and perhaps a decade running selected upstream pre-releases and live-git, with a bug-searching/filing history to match, I suppose I have a bit more experience than most. Meanwhile, this bug report actually ended up conflating (at least) two konsole toolbar bugs. It was originally filed (with a then-accurate title/summary) long before the missing-setting bug, which got duped to the existing won't-remember bug even though they're technically related but different bugs. Arguably they should have stayed separate. But irrespective of that, you remain correct that the existing title doesn't reflect the now-reality of the conflated and duped bugs. And as the original filer I /do/ have the right to change it. =:^) How about this new one?
Git commit 090356661c92bfedeeeaf6f4f77d294facb3d8c6 by Kurt Hindenburg, on behalf of Ahmad Samir. Committed on 02/08/2021 at 15:28. Pushed by hindenburg into branch 'master'. Fix KXmlGUI toolbars; and Konsole MainWindow size Call setupGUI(), which will call createGUI (since we set the KXmlGuiWindow::Create flag), omit the StatusBar flag since we don't have a statusbar and don't want the "Show StatusBar" menu action. TabbedViewContainer::sizeHint() calculates an optimum size for itself, including the sizes of its child widgets; added in efb621d091c05f11 by Mariusz Glebocki; following the code: MainWindow creates a ViewManager ViewManager creates a TabbedViewContainer and then a TerminalDisplay which means that the first time TabbedViewContainer::sizeHint() is called the TerminalDisplay widget size is 0, then TabbedViewContainer::sizeHint() would return 0. Which is why calling resize() in MainWindow was delayed to the showEvent(), (and even delayed more by a QTimer::singleShot() call in Application), at which point all the child widgets have been created and MainWindow::sizeHint() (which logically takes into account the sizeHint() of its child widgets) would return a sensible size. Related: bug 436471, bug 439339 M +12 -5 src/MainWindow.cpp https://invent.kde.org/utilities/konsole/commit/090356661c92bfedeeeaf6f4f77d294facb3d8c6
Is there anything left to do to fix this?
*** Bug 440902 has been marked as a duplicate of this bug. ***
I just installed KDE Gear 21.08 and hit the bug for the first time ever: scaly toolbars that force Konsole windows to have a width of about 1400px. "Settings > Tab Bar/Splitters > Appearance > Show > Never" is ignored. Also specific toolbar settings (e.g. no text) are not remembered. If the cited commit from comment #28 is already included in the current version (21.08.0) and should have fixed this: it didn't. Workaround: enable "Settings > General > Remember window size". (Naturally, this stifles the possibility to open new Konsole windows with a default size specified in the default profile.)
Arch just upgraded KDE packages to konsole-21.08.0 and this issue popped up. The toolbars showed up many months ago and I disabled them and they stayed off. The upgrade seems to ignore whatever config there is / was. Downgrading konsole to konsole-21.04.3 makes it go away again. Zero other changes to configs or anything. Personally, I don't think the "Remember Windows Size" setting is a solution either. I like my "profile" default size.
After updating to konsole 21.08.0 on arch linux today, I can also no longer hide any of the toolbars and no longer see a menu item to hide them under "Settings". Downgrading fixes the issue. It doesn't look like konsole 21.08.0 was ready for release...
Git commit fb7f838fd3138a39aea3bcb2e91f923741587137 by Ahmad Samir. Committed on 13/08/2021 at 18:21. Pushed by ahmadsamir into branch 'cherry-pick-09035666'. Fix KXmlGUI toolbars; and Konsole MainWindow size Call setupGUI(), which will call createGUI (since we set the KXmlGuiWindow::Create flag), omit the StatusBar flag since we don't have a statusbar and don't want the "Show StatusBar" menu action. TabbedViewContainer::sizeHint() calculates an optimum size for itself, including the sizes of its child widgets; added in efb621d091c05f11 by Mariusz Glebocki; following the code: MainWindow creates a ViewManager ViewManager creates a TabbedViewContainer and then a TerminalDisplay which means that the first time TabbedViewContainer::sizeHint() is called the TerminalDisplay widget size is 0, then TabbedViewContainer::sizeHint() would return 0. Which is why calling resize() in MainWindow was delayed to the showEvent(), (and even delayed more by a QTimer::singleShot() call in Application), at which point all the child widgets have been created and MainWindow::sizeHint() (which logically takes into account the sizeHint() of its child widgets) would return a sensible size. Related: bug 436471, bug 439339 (cherry picked from commit 090356661c92bfedeeeaf6f4f77d294facb3d8c6) M +12 -5 src/MainWindow.cpp https://invent.kde.org/utilities/konsole/commit/fb7f838fd3138a39aea3bcb2e91f923741587137
A possibly relevant merge request was started @ https://invent.kde.org/utilities/konsole/-/merge_requests/457
*** Bug 440946 has been marked as a duplicate of this bug. ***
*** Bug 440992 has been marked as a duplicate of this bug. ***
Fixes were cherry-pick'ed to release/21.08 branch.
*** Bug 441098 has been marked as a duplicate of this bug. ***
*** Bug 441159 has been marked as a duplicate of this bug. ***
(In reply to Ahmad Samir from comment #50) > Fixes were cherry-pick'ed to release/21.08 branch. It seems this broke konsole again: https://bugs.kde.org/show_bug.cgi?id=441244
(In reply to Mario Splivalo from comment #54) > (In reply to Ahmad Samir from comment #50) > > Fixes were cherry-pick'ed to release/21.08 branch. > > It seems this broke konsole again: > > https://bugs.kde.org/show_bug.cgi?id=441244 The fix is in the release/21.08 git branch, it was added there after 21.08 was released, so distro maintainer will need to backport the commit(s) to their respective distros.
(In reply to Ahmad Samir from comment #55) > (In reply to Mario Splivalo from comment #54) > > (In reply to Ahmad Samir from comment #50) > > > Fixes were cherry-pick'ed to release/21.08 branch. > > > > It seems this broke konsole again: > > > > https://bugs.kde.org/show_bug.cgi?id=441244 > > The fix is in the release/21.08 git branch, it was added there after 21.08 > was released, so distro maintainer will need to backport the commit(s) to > their respective distros. Aaa, thnx for the explanation!
*** Bug 441244 has been marked as a duplicate of this bug. ***
*** Bug 441385 has been marked as a duplicate of this bug. ***