[konsole] [Bug 430032] New: wishlist: konsole --hide-toolbar commandline option

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=430032

            Bug ID: 430032
           Summary: wishlist: konsole --hide-toolbar commandline option
           Product: konsole
           Version: master
          Platform: Other
                OS: Other
            Status: REPORTED
          Severity: wishlist
          Priority: NOR
         Component: general
          Assignee: konsole-devel at kde.org
          Reporter: 1i5t5.duncan at cox.net
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.