Bug 430032

konsole needs a --hide-toolbar (--hide-toolbars?) command-line option to match the --hide-menubar and --hide-tabbar options.

---
Optional read: background/usage-scenario and further information:

After kde unfortunately lost chained-global-hotkeys back in the infamous kde3>kde4 upgrade I was forced to homebrew my own because I've way more hotkey entry candidates than "extra" keys or wetware-memory for exotic modifier combinations that might well be needed in various apps anyway, making hotkey-chain trees the most reasonable solution since at minimum that requires (key realization) a single global hotkey initiator with recursive invocation.

The trouble was I could only find one X-based solution (xbindkeys IIRC) with the required key-chaining/recursive-invocation that I needed, and that was in its advanced mode, which required lua scripting.  But I didn't know lua and what with all the other changes I was having to do to accommodate the still-badly-broken-at-the-time kde4 (yes, that's still a sore spot all these years later, we'll leave it at that), I didn't want to have to learn it, not for /just/ a hotkey solution.

So that left coming up with my own.  The trouble is I don't know C/C++ or even (now) javascript/qtscript so that's out, but I do know bash, so I bashed out a solution!  Enter a terminal -- konsole since we're talking kde -- to display the TUI as a popup.  While the original TUI was all bash, being all scripted that was rather slow.  The current iteration uses (TUI-based) pdmenu to generate the TUI and respond to the chained hotkeys after the initial kde-based launching hotkey, making it much faster tho still not as fast as an all-native-code solution would be.

Of course years later and switching to wayland I'm glad I don't have a legacy-X hotkeys solution to migrate off of, with the TUI-based solution workable as long as a terminal is available and I can setup at least one global hotkey to launch it in that terminal. =:^)

Meanwhile, the idea is to have the TUI /appear/ as if it's an independent popup menu, not in a terminal window.

To make that happen I have a special konsole profile for the popup UI that has the scrollbar hidden and a transparent default-background, with pdmenu using an alternate background color for the actual menu.  The popup konsole is then invoked with --hide-tabbar and --hide-menubar to eliminate them, and I have a window rule setup to eliminate the windeco/titlebar/borders and set the initial window placement "under mouse".

That works as intended, the appearance is as if it's a bare (if somewhat squarish, no rounded-corners on the per-character background) popup menu, with one exception -- konsole's toolbar.

Unfortunately the toolbar setting isn't per-profile so I can't set it there, tho that'd be a different bug (which I can file if you like).  Fortunately I don't want a toolbar in any of my profiles so that's not a problem affecting me, I can just turn it off everywhere.

What does affect me is again a different bug (which I plan on filing but I'm doing this one first), that konsole has repeatedly lost its no-toolbar setting.  I suspect what is likely making that more frequent here is the frequency with which I launch konsole windows, often multiple times within a few seconds as I recurse down my menu tree, launching new konsole windows for each level of the tree as the window for the level above closes, so it's quite possible there's read/write racing going on with the previous window closing and writing state while the new window opens at the same time.

But that's a different bug.

The (wishlist) bug here is simple.  With a --hide-toolbar option to match the already existing --hide-tabbar and --hide-menubar options I could just set that either in individual scripts or in a ~/bin/konsole wrapper script and wouldn't have to worry about whether konsolerc retains my toolbar prefs or not.

I guess a --hide-scrollbar option might be useful for some as well.  Tho I've not had problems with it, the per-profile setting is enough for me and unlike the toolbars setting, the scrollbars setting doesn't appear to get lost (maybe /because/ it's per-profile?).  But I could file a separate wishlist-bug for that too, if you like.