SUMMARY Konsole does not respect profile for every new tab when the profile was mentioned at the execution. STEPS TO REPRODUCE 1. execute: konsole --profile ~/profilename.profile & 2. try to open a new tab OBSERVED RESULT Main tab is opened with the profile used when it was executed but no the new tabs; they are taking the profile from konsolerc file. It must still use the profile EXPECTED RESULT All tabs must be using the profile used in konsole --profile execution. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: RHEL 7 (available in About System) KDE Plasma Version: 4.11.19 KDE Frameworks Version: 4.14.18 Qt Version: 4.8.7 ADDITIONAL INFORMATION
when you open a new tab via the menu, you get to select the profile interactively, so that's obviously not the issue here. the issue manifests when the "new tab" action is activated via a key binding, as it does indeed always use the default profile. one way to deal with that would be indeed respecting the --profile option as you suggest. another way would be using the profile of the current tab. there is a precedent for this in form of the profile option to use the current tab's working directory. a third option would be a combination of the two: use --profile if specified, otherwise fall back to current profile. though this would make the behavior somewhat inconsistent, so it might be a tad confusing.
This bug is fixed in the PR https://invent.kde.org/utilities/konsole/-/merge_requests/252 awaiting review and merging.
This has always been the behavior. Opening a new tab via the default shortcut always uses the default profile. "Fixing" this would be a change in behavior. The patch in the MR uses the 3rd option suggested by Oswald which IMHO is confusing.
I really believe that the third option should be the default behavior in case the profile is specified using --profile, even in a new tab, as this is the look that best fits our view. I am open to suggestions if they feel necessary.
i don't see why changing the behavior should be a notable problem in this case. anyway, how about separate actions? new-tab-default (aliased to the current new-tab), new-tab-current, new-tab-selected, and new-tab-smart (yay, who doesn't like an explosion of options).
Oswald, allow me to disagree with you, I believe that many options end up confusing users, in this case, I also believe that the behavior should be standard in the case of using the --profile argument for the entire instance of the application that is running. It is worth noting that other instances assume the current behavior.
the wording was fairly indicative of sarcasm. ;) anyway, having multiple additional actions wouldn't be that bad in this case, as they would appear only in the shortcut config dialog (they aren't relevant for the menu, as i already pointed out). it would be also ok to have only one additional action, and possibly make its exact behavior configurable in the profile (though such a micro-option would add mostly useless clutter). i for one don't really care which of the proposed behaviors the new action would have, as my usage pattern is basically one profile per window, so they'd all do the same thing. but if i had to choose, i'd use my 2nd option, as it's most consistent with existing functionality (cf. $PWD).
Thoughts on a command line only option so konsole --all-tabs-use-profile=myprofile ?
--all-tab-profile=... maybe, to make it less verbose. note that this is lacking the "copy current" mode. one could add --new-tab-profile={default,current,smart} instead, but that just shifts the additional choices to the command line, so it's not much of an improvement.
so, there already is an action which is (mostly?) equivalent with the proposed new-tab-current: clone-tab. and as indicated on gitlab, the maintainers seem to be fine with changing the meaning of new-tab to heed the command line override. so we end up with two actions with rather obvious semantics. seems like a sensible outcome to me.