Bug 408217

see also https://bugs.kde.org/show_bug.cgi?id=407076

Hi,
AFAIR this behaviour is not new.  That's the way konsole treated the switch-profile as long as I can remember.

When one replaces the command too, then switch-profile would be identical to new-tab (except that it closes the first the current tab).

In my opinions _if_ this behaviour change is implemented then it's better called replace-tab.

(In reply to Achim Bohnet from comment #2)
> Hi,
> AFAIR this behaviour is not new.  That's the way konsole treated the
> switch-profile as long as I can remember.

Prior to https://bugs.kde.org/show_bug.cgi?id=405930, if I used the keyboard shortcut, it would properly create a new tab.  Switching an existing tab to a new process makes no sense to me.

Also, if I use the switch-profile like the way it is now, whether keyboard or menu, and then restart KDE such that that konsole gets restarted, then that tab has the theme AND runs the command, which is different behaviour. I'd say that it's far more broken now than it was before that "fix".

The only way I can see to salvage the difference between "switch profile" and "new tab -> profile" is to separate out *theme* from command/profile. That is, everything under "Settings" changes from "profile" to "theme". There is no command or current directory associated with a theme. The entire "General" tab in profiles would be removed.

And then a new configuration, say "template", would exist that would have that "General" tab that just got removed, plus a link to an existing "theme". (Perhaps the ability to create a new theme at the same time would be there, doesn't matter to me.)

Both themes and templates can have keyboard shortcuts. I would personally never use the shortcut for the theme, but that doesn't mean others wouldn't.

On re-startup, konsole would have to know what template and theme each tab had, and apply as appropriate.

That's the salvage. Otherwise, I would simply move the whole profile thing to be starting new tabs. Because as long as a command exists there, which is the sole reason why I use profiles in the first place, switching a tab to a profile without running the command specified is inherently broken.

I completely agree with Darin.  Great summary and suggestion to fix the regression introduced in  #405930, that damaged suddenly my/our workflow.

+1 to associate the shortcuts with 'new-tab'.

This is a bug in the "Switch" that it doesn't run the Command.  So I'll leave this open for that.  The shortcut issue will create new tabs in 19.08 as they did in 18.12

This broken my workflow as well. Would be happy if previous behavior is restored.

Darin suggestion on fix is spot on.

(In reply to Łukasz Ligowski from comment #6)
> This broken my workflow as well. Would be happy if previous behavior is
> restored.
The previous behavior has been restored already in 19.08.

https://cgit.kde.org/konsole.git/commit/?h=Applications/19.08&id=a1b64d7956485c6358bd2cccabde3843c1d314eb

*** Bug 415355 has been marked as a duplicate of this bug. ***

Darin comment covered my wishes!
As a side note, for anyone looking at this bug: 
The current workaround (not with keyboard, but at least it's less painful) is to open a new Tab from the File Menu:

File --> New Tab --> <Select the profile> you wish

(In reply to Achim Bohnet from comment #2)
> Hi,
> AFAIR this behaviour is not new.  That's the way konsole treated the
> switch-profile as long as I can remember.
> 
> When one replaces the command too, then switch-profile would be identical to
> new-tab (except that it closes the first the current tab).
> 
> In my opinions _if_ this behaviour change is implemented then it's better
> called replace-tab.

I use KDE since 1.x and at least with Fedora and Suse/openSUSE it was never the case. I even had scripts in the past to create profiles for the servers of a new project etc.

I can confirm the old behaviour has been restored - if you're on a distro that's not carrying KDE apps 19.08.3+ (maybe earlier), then you'll have to wait until the distro makes available the upgrade.  (Which is why these regressions are so painful - it can take a long time for some distros, especially the LTS releases, to get the fixes.)

However, I thank the developers for fixing it. It's really appreciated and helpful.

(In reply to Darin McBride from comment #11)
> I can confirm the old behaviour has been restored - if you're on a distro
> that's not carrying KDE apps 19.08.3+ (maybe earlier), then you'll have to
> wait until the distro makes available the upgrade.  (Which is why these
> regressions are so painful - it can take a long time for some distros,
> especially the LTS releases, to get the fixes.)
> 
> However, I thank the developers for fixing it. It's really appreciated and
> helpful.

You could take the link to the commit that fixed the issue (from comment#7), and file a bug report in your distro's bugzilla asking to backport the fix, they'll consider the patch and see if it can be easily backported or if it's more prudent to wait till the next stable release, usually it's the former :)

I am not sure if it is the same problem: since version 19.12.0 I am no longer able to connect to a remote host, using another profile. For example: I have a profile and in the settings I set a commend "ssh root@host".  

Until version 19.08.3 I got then a new tab and connection to the host, i. e. after hitting File --> New Tab --> <Select the profile>.  Now in version 19.12.0 I get only a blank, black screen, neither a prompt or a flasing cursor; nothing.  If I downgrade to version 19.08.3 it works again.

Other commands like "su -" for a root-session are working, and also if I issue a "ssh root@host" on a prompt of a existing session, but can't connect to the host while switching to another profile. 

Platform are the Archlinux packages.

(In reply to Martin Schnitkemper from comment #13)
> Until version 19.08.3 I got then a new tab and connection to the host, i. e.
> after hitting File --> New Tab --> <Select the profile>.  Now in version
> 19.12.0 I get only a blank, black screen, neither a prompt or a flasing
> cursor; nothing.  If I downgrade to version 19.08.3 it works again.

Maybe a problem with the color scheme?
Might be bug#415242...

(In reply to Darin McBride from comment #11)
> I can confirm the old behaviour has been restored
That's true, but "Switch profile" still doesn't execute the command. (that's not a regression though, it was already like this in the KDE4 version at least)

As that's what actually has been reported in comment#0, maybe the bug should be reopened?

PS, the bug report hasn't been closed earlier intentionally:
(In reply to Kurt Hindenburg from comment #5)
> This is a bug in the "Switch" that it doesn't run the Command.  So I'll
> leave this open for that.

Reopening therefore.

(In reply to Wolfgang Bauer from comment #16)
> PS, the bug report hasn't been closed earlier intentionally:
> (In reply to Kurt Hindenburg from comment #5)
> > This is a bug in the "Switch" that it doesn't run the Command.  So I'll
> > leave this open for that.
> 
> Reopening therefore.

Ouch. Thanks for fixing my mistake :)

(In reply to Wolfgang Bauer from comment #14)
> Maybe a problem with the color scheme?
> Might be bug#415242...

Yes, it is as you described.  After I changed the background to a fixed color, all is visible for me.  Hence, it is not a connection problem, it was just the black on black that confused me.

For a workaround I will keep these settings, or try to re-compile using  the given patch.

Sorry for the noise, and thanks for your advice.