konsole app is not accessible via Unity

[Steve McInerney]

Click on the 'Dash Home'
type in 'konsole'
Get the icon for konsole returned
Click on the konsole icon
nothing happens.

I previously had the konsole icon locked to my side bar, it refused to activate from there either.

Can start konsole by firing up a stock terminal, type in konsole, and you're away.

But konsole is now invisible to the task switcher, tho does show up on the launcher.

With konsole running, lock it to the launcher. Exit konsole. Click on the konsole icon on the sidebar launcher, nothing happens.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: konsole 4:4.9.2-0ubuntu1
ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5
Uname: Linux 3.5.0-17-generic i686
NonfreeKernelModules: nvidia
ApportVersion: 2.6.1-0ubuntu4
Architecture: i386
Date: Fri Oct 19 16:26:02 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha i386 (20120201.2)
MarkForUpload: True
ProcEnviron:
 LANGUAGE=en_AU:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_AU.UTF-8
 SHELL=/bin/bash
SourcePackage: konsole
UpgradeStatus: Upgraded to quantal on 2012-09-07 (42 days ago)

[Majewsky (majewsky)]

Since the update from 4.8 to 4.9 RC 1, a new Konsole window starts in ~/Documents instead of ~. This differs from the standard behavior of about every terminal or terminal emulator in the world.

Reproducible: Always

[adaptee (adaptee)]

(I guess) You are starting konsole through krunner, right ? If not, how ?

Please describe the problem in a clear and umambiguous way. Basically, you should follow the template shown in https://bugs.kde.org/enter_bug.cgi?product=konsole&format=guided, i.e., "Steps to reproduce", "Expected results", "Actual Results", etc. That would reduce the cost of communication and the chance of misunderstanding.

[Kurt Hindenburg (kurt-hindenburg)]

I just noticed that this happens on my laptop when starting Konsole from the taskbar menu.

2.9

[adaptee (adaptee)]

See https://bugs.kde.org/show_bug.cgi?id=183534 for the root cause

The change on the konsole side is https://projects.kde.org/projects/kde/kde-baseapps/konsole/repository/revisions/ebcab3c307f83ddf42a9096b8a76a5389ce52f3d.

That commit only makes konsole more like other emultators. So if konsole is starting in "~/Documents" when started through krunner or menu, I'm pretty sure that also applies to other emulators, like xterm, rxvt-unicode, gnome-terminal, etc .

[adaptee (adaptee)]

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

[Vamp898 (vamp898)]

(In reply to comment #3)
> See https://bugs.kde.org/show_bug.cgi?id=183534 for the root cause
>
> The change on the konsole side is
> https://projects.kde.org/projects/kde/kde-baseapps/konsole/repository/
> revisions/ebcab3c307f83ddf42a9096b8a76a5389ce52f3d.
>
> That commit only makes konsole more like other emultators. So if konsole is
> starting in "~/Documents" when started through krunner or menu, I'm pretty
> sure that also applies to other emulators, like xterm, rxvt-unicode,
> gnome-terminal, etc .

I dont get it.

Start Konsole in GNOME --> opens in ~
Start Konsole in KDE --> opens in ~/Documents

And it doesnt care if you use krunner or not to start it so why is this krunner related anyway? Does krunner set a global var which is used by konsole?

[adaptee (adaptee)]

(In reply to comment #5)
> I dont get it.
>
> Start Konsole in GNOME --> opens in ~
> Start Konsole in KDE --> opens in ~/Documents

Try running xterm or gnome-terminal in gnome and KDE(through krunner or menu), the result will be the same as the konsole case above (suppose the ~/Documents folder is present ). Without that commit, konsole just start in "~" if you haven't set the initial path explicitly in default konsole profile. That is what I mean that commits only makes konsole more like other emulators.

> And it doesnt care if you use krunner or not to start it so why is this krunner related anyway? Does krunner set a global var which is used by konsole?

See bug 183534

[Francesco Cecconi (brand-nmapsi4)]

I have the same result with gnome-terminal and xterm. (through krunner or menu)

[Maxim Kukushkin (maxim-kukushkin)]

This bug also affects me (Arch Linux, KDE 4.9.00). If I open a system terminal, it opens in ~, but once I try to open xterm or konsole, it opens in ~/Documents (no matter how I run them - krunner or any other way).

Also, if I open a second tab in Konsole or a second Konsole instance - it starts in ~.

I don't have any "cd" to Documents in bashrc or profile and it doesn't appear in environment variables. So, to me it's a bug in KDE. KDE shouldn't affect the behavior of Bash.

[Mr-blurred (mr-blurred)]

I have the same problem. And it's really irritating. But nevertheless, thank you for your apps! :)

Arch Linux 3.4.9
KDE 4.9

[Graeme Hewson (ghewson)]

I start Konsole through a shortcut in the panel, or through a keyboard shortcut, and not through krunner.

As has been pointed out, a second or subsequent instance of Konsole starts with ~, not ~/Documents. I don't understand this inconsistency, which is perhaps even more annoying than having *all* instances start in ~/Documents would be.

Anyway, I've now set my Documents path through System Settings to be my home directory. I don't think I should have to do that, and it's a kludge, but there it is.

[adaptee (adaptee)]

Well, a summary of the situation (or my reply in https://git.reviewboard.kde.org/r/106177/)

    1. The reported problem happens to konsole 2.9.x. But the same problem also happens to xterm, gnome-termianl under the same situation.

    2. There is *nothing* wrong on the konsole side, IMO. The "faulty" commit mentioned in comment #3 only makes konsole more like other emulators.

    3. No matter whose fault it is , if users think it is konsole's fault, then it is and should be fixed.

    4. I don't like the idea of writing extra (strange) code to work around a long outstanding problem in another component. More precisely, the problematic code is here: http://lxr.kde.org/source/kde/kdelibs/kio/kio/krun.cpp#1079 .

    5. Reverting that "faulty" konsole commit is an easy task, while it also means konsole will lose that only recently gained similarity to other emulators.

In the end, I think reverting is the right way. But I'm still reluctant to do it (because there is nothing wrong on the konsole side, you know...). That is why I didn't fix this problem in KDE SC 4.9.1, although I had enough time to do it.

So all subscribers of this report, you have two choices to get this problem fixed :

    1. Raise your hands and push me in this report: "I don't care whose fault. I only want it to be fixed ASAP(4.9.2). Revert that commit. "

    2. Go to bug 183534, add your polite and convincing argument why the current behavior of using KGlobalSettings::documentPath() as the fallback working directory is problematic. Then wait for bug 183534 to be fixed.
l

[Maxim Kukushkin (maxim-kukushkin)]

Hello Jekyll,
I see your point. As for me, it's better to fix the more global problem then rollback changes in Konsole (in fact it will be a workaround then). I'll share my opinion in bug 183534

[Mr-blurred (mr-blurred)]

I also think so. The global fix is more appropriate. But the only thing I don't understand is why the second instance of Konsole runs in ~/ directory?

I press Alt+F2, type "konsole" and it starts in ~/Document. Next, I press Alt+F2, type "konsole" and it starts in ~/. It seems that the Konsole not always inherits its working directory from parent process. In the case of Gnome Terminal launched by Krunner, second instance starts in ~/Document directory.

[Graeme Hewson (ghewson)]

I agree, let's do the job properly. I've added my vote to bug 183534.

[adaptee (adaptee)]

Git commit 5f7b5eba568e8f4d311d9fba015e6f68478b3af6 by Jekyll Wu.
Committed on 21/09/2012 at 12:46.
Pushed by jekyllwu into branch 'master'.

Specify $HOME as working directory through the .desktop file

This is just a workaround for the problem of opening "~/Documents" on startup.
Although it is simple (just one line) and easy to understand, it is still a
not-so-pleasant hack which doesn't need to be added at the first place.

Note, the per-profile working directory still takes precedence if it is set

M +1 -0 desktop/konsole.desktop

http://commits.kde.org/konsole/5f7b5eba568e8f4d311d9fba015e6f68478b3af6

[adaptee (adaptee)]

Git commit a910778820408f293085073712b98a090dd3b28a by Jekyll Wu.
Committed on 21/09/2012 at 12:46.
Pushed by jekyllwu into branch 'KDE/4.9'.

Specify $HOME as working directory through the .desktop file

This is just a workaround for the problem of opening "~/Documents" on startup.
Although it is simple (just one line) and easy to understand, it is still a
not-so-pleasant hack which doesn't need to be added at the first place.

Note, the per-profile working directory still takes precedence if it is set
(cherry picked from commit 5f7b5eba568e8f4d311d9fba015e6f68478b3af6)

M +1 -0 desktop/konsole.desktop

http://commits.kde.org/konsole/a910778820408f293085073712b98a090dd3b28a

[Synfl4g (synfl4g)]

present on F18 too, is not a problem of konsole, and .desktop file is a workaroud. KDE is not the right place for fix old apps like xterm with not xdg dirs standard and .desktop file. Broke KDE for repair other things is not a solution

[David Faure (faure)]

Git commit f659ebf30dde67798926e9ab0a7671a96602174b by David Faure.
Committed on 05/10/2012 at 12:00.
Pushed by dfaure into branch 'KDE/4.9'.

By popular demand, revert the call to chdir(documentPath).

This was an attempt to make the KDE document path work in non-KDE
gui apps (such as openoffice) (#108510). But it makes terminals
start in ~/Documents, which users don't expect.
Related: bug 302903, bug 108510

M +1 -9 kinit/kinit.cpp
M +1 -6 kio/kio/krun.cpp

http://commits.kde.org/kdelibs/f659ebf30dde67798926e9ab0a7671a96602174b

[David Faure (faure)]

Git commit d6dddcc4dbe928670cef61708805c81bf6d1066c by David Faure.
Committed on 05/10/2012 at 12:15.
Pushed by dfaure into branch 'KDE/4.9'.

Revert a91077882, fixed in kdelibs instead, and $HOME breaks in Gnome.

FIXED-IN: 4.9.3

M +0 -1 desktop/konsole.desktop

http://commits.kde.org/konsole/d6dddcc4dbe928670cef61708805c81bf6d1066c

[David Faure (faure)]

Git commit c090b85ff808c920ebf6db3459136105f3ad3fc8 by David Faure.
Committed on 05/10/2012 at 12:15.
Pushed by dfaure into branch 'master'.

Revert a91077882, fixed in kdelibs instead, and $HOME breaks in Gnome.

FIXED-IN: 4.9.3
(cherry picked from commit d6dddcc4dbe928670cef61708805c81bf6d1066c)

M +0 -1 desktop/konsole.desktop

http://commits.kde.org/konsole/c090b85ff808c920ebf6db3459136105f3ad3fc8

[Steve McInerney (spm)]

But konsole is now invisible to the task switcher, tho does show up on the launcher. <== I lie.

It is showing at the present time. Wasn't prior to this latest reboot.

[adaptee (adaptee)]

See https://bugs.launchpad.net/unity/+bug/1063630/comments/4

[Harald Sitter (apachelogger)]

Will subsequently be fixed in the .3 update which should hit the official archives in a month or so.

[Dedanna1029 (dedanna1029)]

I am still seeing this bug in a fresh install of Mageia 2, KDE 4.8.5 (although I do not think the KDE version is relevant, and I'll state why). For me, on fresh installs of whatever distro, this has been happening for years and years, going back all the way to KDE1, and has been equally as annoying as it has been long.
I've posted to several forums through the years on this; no one has every seemed to have the answer, not even at a forum that I used to moderate myself (bjoernvold). There is a discussion on this ongoing ATM, at that very forum about this, please do go have a read at http://bjoernvold.com/forum/viewtopic.php?f=20&t=2542
I am pleading to all concerned on this bug to find the actual fix, and then to release it to various distro developers.
Thanks.

[Dedanna1029 (dedanna1029)]

Please re-open this bug. I can not find where to do it myself. Thanks.

[Graeme Hewson (ghewson)]

4.8.5 is a fairly old release. The fix was for 4.9.3, and indeed the problem was fixed for me. A workaround is to set the Documents path in System Settings / Account Details.

However, I experience a residual problem where the default download directory for Akregator is ~/Documents. Whether that's related to this bug, I don't know.

[Dedanna1029 (dedanna1029)]

I've set that in system settings already, and it's still doing this.

[adaptee (adaptee)]

(In reply to comment #21)
> I am pleading to all concerned on this bug to find the actual fix, and then
> to release it to various distro developers.
> Thanks.

It (either this konsole issue or the underlying issue) is fixed in 4.9.3 . Read bug 183534. You can ask your distro developers to backport commit http://commits.kde.org/kdelibs/f659ebf30dde67798926e9ab0a7671a96602174b

Actually, if you use 4.8.5, konsole shouldn't suffer from this issue at all even when the underlying issue was there, since konsole simply didn't care about the working directory inherited from its parent process at all in old versions.

(In reply to comment #23)
> However, I experience a residual problem where the default download
> directory for Akregator is ~/Documents. Whether that's related to this bug,
> I don't know.

That should be a different bug. See bug 304123.

To sum up, this (konsole) problem is really solved. No need to reopen.

[Dedanna1029 (dedanna1029)]

(In reply to comment #25)
> (In reply to comment #21)
> > I am pleading to all concerned on this bug to find the actual fix, and then
> > to release it to various distro developers.
> > Thanks.
>
>You can ask your distro developers to backport commit
> http://commits.kde.org/kdelibs/f659ebf30dde67798926e9ab0a7671a96602174b

That, I'll be doing. I think it should've been backported to begin with.

> Actually, if you use 4.8.5, konsole shouldn't suffer from this issue at all
> even when the underlying issue was there, since konsole simply didn't care
> about the working directory inherited from its parent process at all in old
> versions.

However, I'm showing this to be false with screenshots in a moment (I am not lying; as I said, I've seen it in every version of KDE going back to KDE1).

[Dedanna1029 (dedanna1029)]

Created attachment 77404
KDE version straight from system settings

This is the KDE version this machine is on, straight from KDE's system settings. Mageia does not boast a KDE 4.9anything at all, but 4.8.

[Dedanna1029 (dedanna1029)]

Created attachment 77405
Guake terminal, after having typed exit, no less.

Konsole itself isn't doing this. It does it for a while, then eventually, about a few months later, something will make it stop. However, all other terminals do it in KDE, where they don't in Gnome, as was said in some original posts in this bug.

You can clearly see the command prompt it's at, and the number of the terminal in Guake. It's clearly just had "exit" typed in, starting it with a fresh terminal. I could pull up others as well, that do it in KDE.

[adaptee (adaptee)]

(In reply to comment #28)
> Created attachment 77405 [details]
> Guake terminal, after having typed exit, no less.
>
> Konsole itself isn't doing this. It does it for a while, then eventually,
> about a few months later, something will make it stop. However, all other
> terminals do it in KDE, where they don't in Gnome, as was said in some
> original posts in this bug.
>
> You can clearly see the command prompt it's at, and the number of the
> terminal in Guake. It's clearly just had "exit" typed in, starting it with a
> fresh terminal. I could pull up others as well, that do it in KDE.

Well, that is why I just say "konsole shouldn't suffer from this issue in old versions (4.8.5)". I do know other applications had that issue in old KDE releases, but that is irrelevant with this konsole report. That is bug 183534, which has been explicitly marked as the dependency and root cause of this konsole issue.

before 4.9.0 : one konsole bug + one kdelibs bug ==> not a problem for konsole ( like -1 x -1 = 1 ), but a problem for other applications ( like 1 x -1 = -1 ).

in 4.9.0: konsole bug fixed + kdelibs bug remaining => this konsole report ( like 1 x -1 = -1 )

in 4.9.3 : konsole bug fixed + kdelibs bug fixed => no problem for konsole and other applications ( like 1 x 1 = 1)

I think I have explained it clearly enough.