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.
(In reply to Duncan from comment #0) > 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. Now filed as bug #430036
Why not just turn off the toolbar if you don't like it? I don't really understand the use case for any of these --hide-[thing] args.
(In reply to Nate Graham from comment #2) > Why not just turn off the toolbar if you don't like it? I don't really > understand the use case for any of these --hide-[thing] args. Keep in mind we're talking about a terminal here, which may often be called by scripts. I believe the intended use-case for --hide is scripts that want to present effectively a popup message, possibly with some limited interactivity, but where menubars/tabbars/toolbars/scrollbars don't make sense as the window isn't intended to be on screen long enough for them to be actually needed. Which makes the extra bars, etc, just more visual clutter. In some cases these aren't per-profile options so without the commandline --hide-X options they'd have to be toggled globally, and the user may not want that globally. Where they are per-profile, a single monolithic script file with a few extra characters on the konsole call line explicitly toggling off the <whatever> is a *lot* more convenient than having to worry about an entire additional custom profile file, located in an entirely different directory from the script, as well. (And that's assuming the profiles are contained in a single per-profile file, which I'm not entirely sure of without having to verify, but which I believe to be the case.) Certainly that's why I make use of such options here, even if it's just for my own use on a single computer.