Dan Johansson posted on Sat, 14 Apr 2012 12:02:54 +0200 as excerpted:
> Yesterday I upgraded my KDE installation (4.7.4 -> 4.8.1).
> Now the "new tab button" in Konsole opens a new tab with the _default_
> profile instead of opening a new tab with the _current_ profile like it
> did before.
> This is most annoying as I have one profile for each machine/user I
> manage and until now I could just click the "new tab" button and get a
> new window on the host that I am currently logged into.
> Is there any parameter to restore the old behavior or is this hard-coded
> (I really hope not or I will have to start looking for a new terminal
> emulator with tabs that work like I want it).
As a guess, you won't find many here that use konsole profiles at all. I
do, but wouldn't notice this because the only time I don't use the
default profile is for a launcher menu script I have, where konsole pops
up (with different than default behavior, thus the separate profile)
running a scripted menu that takes only a single key as input, using that
to launch something else.
(I scripted this solution up to get around khotkey4's broken multikey
functionality. I have some "extra" keys on my inet/media keyboard, one
of which I used as a launch-menu launcher in kde3. But kde4 lost that
functionality and the bug says qt4 itself is broken in that regard, tho
qt5 apparently supports it already, so I had to come up with a different
solution. The key insight was that I could view each hotkey in the series
separately, so I have khotkeys set to launch my scripted launcher in a
konsole window, where a single key choses a category and launches it
again, to choose an app. So with three keys, launch-cat-app, I can
launch any of my most used apps as configured in my own menu system.)
But my script has an arbitrary 30 second timeout, after which it takes a
default action, so the konsole windows using that profile are transient
indeed, and adding a second tab wouldn't make sense.
I do use the new-tab functionality as well, but only on the default
profile, so for me, the behavior would be unchanged and wouldn't have
been noted.
I don't know whether there's a configurable fix, but it'd be possible to
check out the git sources and bisect to an individual troublesome commit,
which you could then either revert or generate a reverting patch from,
and build it yourself. I don't claim to be a coder, but I run gentoo so
build everything from sources using gentoo ebuild scripts, and I'm
familiar enough with git (from also running a live-git upstream kernel,
bisecting and reporting problems to get them fixed by release) that using
it to bisect down to an individual commit is more or less routine for me,
and I do occasionally use it to generate patches that I then place in a
directory such that gentoo's portage build system automatically applies
them as it builds updates, from then on. Occasionally I have to change
the patch a bit to keep it working, but the technique does work
reasonably well, even tho I do NOT claim to be a coder, as I said, only
an admin with enough scripting and building from source skills to
generally manage to hack up a solution to this sort of thing when I I
need it badly enough, as was the case for multikey hotkeys, where I used
scripting, and for gwenview, for instance, where I preferred the older
sub-x00-percent zooming (the patch I use changes the new 100% zooming
steps to 5%).
That's probably not the answer you wanted, but it's the best I've got.
Hopefully someone else can do better for you, tho as I said, I don't many
here actually use konsole profiles. I guess we'll see...
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
