Hm, but if qdbus worked, I don’t see any reason at all why the shortcuts (or the “Call” button) did not work.
Unless “spectacle --dbus” itself would have failed to start or create the org.kde.Spectacle DBUS service, but that was not the case either…
The lists are sort of the same (I have not compared them line by line) before and after the problem was solved.
The exact lines in the list are not really relevant here and may differ depending on what applications are running, what desktop you use (possibly even the version), etc…
The only important thing is that it shows something (and not just an error message), that indicates that things are working in general.
And of course for the pre-defined screenshot shortcuts to work (or the “Call” button for their pre-defined actions), org.kde.Spectacle needs to show up after runs “spectacle --dbus” is run (this should be run automatically if the service it accessed by something).
That’s why I draw the conclusion that maybe I need to run qdbus at least once before the export statement of Anaconda3. The detail explanation on what’s happening here is that in following list,
At first, I want to copy back my backup of user direction into this system so that the installation process could pick it up when I set a user account as this could save a lot of time and effort (I think).
But it turns out I put the backup into a sub-directory so the installation process didn’t pick it up during intallation.
Then I thought I could do it before I login to my account (with the same user name as the backup profile).)
So, the last step makes the export statement of Anaconda3 exist in the profile before the initial login of the account. And this make me think that if I login first and then import the export statement of Anaconda3, the problem may not happen at the first place. But this is only a bold guess.
As it is in my answers to your inquiries, at first, org.kde.Spectacle does show up in the dbusviewer window after “spectacle --dbus” is run through console. But when I let it running there, the “call” button and the shortcut do not work as before.
Now, as the problem is solved, there is no org.kde.spectacle in the list initially. But if I call the “Start Screenshot Tool”, then org.kde.spectacle shows up in the list. And it disappears after I close Spectacle.
The only difference that export statement makes is that you use Anaconda3’s qdbus now, which is actually the Qt5 version.
So this has been run before, startkde uses it…
Also, AFAIK qdbus doesn’t have any “configuration” that would need to be initialized. It is just a simple tool to access DBUS, similar to dbus-send.
TBH, reconsidering all information in this thread, I have absolutely no idea what really may have caused your problem.
Anyway, patching khotkeys to use qdbus-qt5 should likely have avoided your problem altogether as Anaconda only comes with a qdbus, so even with that export the system’s version is used.
And we should do this in any case, as libqt4 might not be installed (the Plasma session only requires Qt5 of course), it’s currently only still pulled in by some KDE4 applications in the default install that may get ported to KF5/Qt5 as well sooner or later.
As it is in my answers to your inquiries, at first, org.kde.Spectacle does show up in the dbusviewer window after “spectacle --dbus” is run through console. But when I let it running there, the “call” button and the shortcut do not work as before.
Yes, I do remember that.
And the only reason for this I can think of is that qdbus didn’t work.
Now, as the problem is solved, there is no org.kde.spectacle in the list initially. But if I call the “Start Screenshot Tool”, then org.kde.spectacle shows up in the list. And it disappears after I close Spectacle.
Yes, as mentioned it is started on demand, i.e. when you press PrintScr (or similar) the first time, then it stays running.
I mean the qdbus may need to initialise the contents in configuration file of khotkeysrc for the system to recognise the UUIDs or something else in that file. Because, after I remove the export statement and reboot (which I should not do before a test run of the “Call” button or the shortcut), the system can respond to the call or shortcut for Spectacle. Then, I activate the export statement of Anaconda3 and then do a,
. ~/.bashrc
the path of Anaconda3 is imported into $PATH. However, the system could still correctly respond to the call or shortcut for Spectacle.
It’s very good to know this pending change is about to come
It’s just that khotkeys runs qdbus to invoke the configured action when you press the shortcut or click on “Call”.
The UUID is just an internal number of khotkeys, to correlate a configured keyboard shortcut with the action it should trigger (you can assign at least two shortcuts to the same action…).
Even if there would be a problem with the UUIDs that would cause the keyboard shortcut to not work, clicking on “Call” should still work as that doesn’t need any UUID (it just calls qdbus with the appropriate parameters, in this case “qdbus org.kde.Spectacle / StartAgent”).
Then, I activate the export statement of Anaconda3 and then do a,
. ~/.bashrc
the path of Anaconda3 is imported into $PATH. However, the system could still correctly respond to the call or shortcut for Spectacle.
Erm, if you run “. ~/.bashrc” in a shell, that only affects the current shell and not the rest of the system (in particular not khotkeys).
Did you see if it still works now when you logout and in again? (or reboot)
It’s very good to know this pending change is about to come
Well, it’s necessary.
It likely just has been overlooked so far because it did work anyway (because libqt4 is still installed by default).
Yes, you’re right. It won’t work after a log out and in.
Ahhh, there are so many things I need to learn :\ It’s great to have you and many other experienced users in this forum.
Ok, so at least it’s still broken. That at least makes it a little bit less mysterious…
I would be interested now whether running this actually works (with the Anaconda export active), or whether there is an error message:
qdbus org.kde.Spectacle / StartAgent
On my system (without Anaconda), this opens a spectacle window as it should even if spectacle is not running already (and even if logged in to a different desktop like IceWM).
And, I suppose, “qdbus-qt5 org.kde.Spectacle / StartAgent” would work anyway, right?
But it might also be interesting to know whether “qdbus org.kde.Spectacle / StartAgent” works after you ran “spectacle --dbus” manually, or not (and whether there is an error message in that case)…
I activated the export statement line and did a log out then in. Then the shortcut didn’t work. Here comes the test.
qdbus version doesn’t work:
cnzhx@a:~> qdbus org.kde.Spectacle / StartAgent
qdbus: relocation error: qdbus: symbol _ZN9QDBusUtil17isValidMemberNameERK7QString, version Qt_5 not defined in file libQt5DBus.so.5 with link time reference
cnzhx@a:~> qdbus org.kde.Spectacle / StartAgent
qdbus: relocation error: qdbus: symbol _ZN9QDBusUtil17isValidMemberNameERK7QString, version Qt_5 not defined in file libQt5DBus.so.5 with link time reference
So, it doesn’t work and gives the same error message.
Then I run them in the same konsole tab,
cnzhx@a:~> spectacle --dbus &
[1] 3710
cnzhx@a:~> qdbus org.kde.Spectacle / StartAgent
qdbus: relocation error: qdbus: symbol _ZN9QDBusUtil17isValidMemberNameERK7QString, version Qt_5 not defined in file libQt5DBus.so.5 with link time reference
Ok, so that explains everything:
Anaconda’s included qdbus is incompatible with the system’s Qt5 libraries, so it fails to start.
(Anaconda likely even comes with a completely different Qt5 version)
I don’t know if Anaconda actually needs qdbus (and qtdbusviewer or the other qt tools), but as it is broken anyway, it might just as well be fine to delete them in ~/anaconda3/bin/ I suppose.
But if you remove the export from ~/.bashrc, it should at least not affect the rest of the system.
I guess so. But I don’t know Anaconda too much. TBH, I think it’s Anaconda’s fault for messing up user’s system. It should use a better way to register its library.
Thank you very much @wolfi323, for your great help and your valuable explanation
In case it helps, based on Toban Wiebe’s blog [1], if anyone use only Anaconda with its jupyter notebook, it’s safe to adjust the export statement in ~/.bashrc of Anaconda from
# added by Anaconda3 4.2.0 installer
export PATH="/home/cnzhx/anaconda3/bin:$PATH"
to
# added by Anaconda3 4.2.0 installer
export PATH="$PATH:/home/cnzhx/anaconda3/bin"
At least, this is good enough for me. I don’t use Anaconda too much.
