Spectacle cannot be invoked by shortcut (hotkey)

English Applications
#1

Good morning,

I recently found Spectacle cannot be invoked by shortcuts any more in my KDE Plasma desktop. It’s happened since openSUSE Tumbleweed snapshot 20170502 or a little earlier. I cannot be exactly sure because I reinstalled my system using snapshot 20170429. Before this, the shortcuts work very well.

Also, Win+PrtScr, Meta+PrtSc and 'Shift+PrtSc` do not work.

I tried to change the default shortcut from PrtSc (Print) to other like “Ctrl+I”. The new shortcut does not work either. But I can start Spectacle from kickstart menu and it works well from there.

Then I looked into the “Action” tab in the shortcuts settings page, it has following configurations:

Remote application: org.kde.Spectacle
Remote object: /
Function: StartAgent
Arguments:

Any suggestions to bring the shortcut feature back?

My environment is,

openSUSE Tumbleweed: 20170510
KDE Plasma: 5.9.5
Qt: 5.7.1
KDE Frameworks: 5.33.0
Kernel: 4.10.13-1-default

Regards,
CnZhx

#2

Hm, works fine here (42.2, but with the latest KDE packages from the Tumbleweed devel projects).

The “Action” settings you posted are the same here too.

Some random things to check:
Are the shortcuts activated? There is a checkbox next to them in “Custom Shortcuts” that should be filled (you may have to enlarge the window or use the scrollbars to see them though)
Does spectacle start if you click on the “Call” button in the “Action” tab?
Do other shortcuts work?
Does it work on a fresh user account?
Is kglobalaccel5 running?

Oh, and just for clarification:
This is a standard X11 session, right?
Or are you using Plasma on Wayland?

#3

Thank you, @wolfi323,

I think I am using a standard X11. (BTW, I tried to find out how to test Wayland but failed to start Plasma on Wayland.)

Followed your hints, I found that:

  • All entries for the Spectacle are selected in the Shortcuts settings page (with the blue square block).
  • The “call” button in the “Action” tab does not work though.
  • This shortcut in a new user profile works. (I should really learn to use this method but I cannot recall this on a new problem :shame:)

Then, do you happen to know how can I solve this in my current profile? I really don’t want to rebuild all the configuration files.

Thanks again for your valuable advice.

#4

You need the package plasma5-session-wayland installed, then you’d get an entry “Plasma5/Wayland” on the login screen.

But the shortcuts should work on X11.
And actually I’m not sure if they would work on Wayland currently, because these things have changed completely on Wayland (because only the compositor, i.e. kwin itself, can implement global shortcuts there, i.e. kglobalaccel5 won’t work at all).

The “call” button in the “Action” tab does not work though.

Ok, so apparently this is the problem, the DBUS service cannot be started.

As it works on a fresh user account, it doesn’t seem to be an installation problem though.

Hm.
One thing I could imagine is that the DBUS service already exists for some reason, but doesn’t react.
I would suggest to check if spectacle is already running (in the system monitor that appears when you press Ctrl+ESC e.g.). If it is, try to kill it and see if it helps.

And maybe try to delete spectacle’s config file (~/.config/spectaclerc), though I don’t really think that could cause a problem like you describe.

#5

Thanks, I will try this later. I always want to take a look at this new stuff :slight_smile:

I have done some testing but none of them work. Some of following results are answer to your advice/guess.

  • Spectacle is not running when I does not run it from kickstart menu.
  • Spectacle does have nothing to with this.
  • ~/.config/kglobalshortcutsrc has nothing to do with this.
  • ~/.config/khotkeysrc might be the config for this, but I do not know how to regenreate this configuration file.

I guess, it is because the UUID used to identify the call to org.kde.spectacle in ~/.config/khotkeysrc should be consistent with some other configuration in current user profile. But I could not find the connection or file. I tried to copy and replace this configuration file from the new user directory, and with a reboot, but it doesn’t work.

#6

Spectacle can be run in two ways, as application (e.g. from the application menu), or as background service.
The latter is used by the pre-defined hotkey, its action “StartAgent” is called via DBUS to open a Spectacle window.

It is started as background service via “spectacle --dbus”. Does it (clicking on “Call” or pressing the keyboard shortcut) work if you run that manually?
Does org.kde.Spectacle show up in qdbusviewer or qdbusviewer-qt5 when you run it manually like that in a konsole? And does clicking on its “StartAgent” method (to call it) in qdbusviewer open the spectacle window then?

  • ~/.config/kglobalshortcutsrc has nothing to do with this.
  • ~/.config/khotkeysrc might be the config for this, but I do not know how to regenreate this configuration file.

If the “Call” button does not start Spectacle either, the problem is not related at all to the hotkeys/shortcut configs or even the shortcuts daemon IMHO.

#7

Good to know that. I always feel it difficult for me understand dbus related topic.

I am not sure I get you correctly. Do you mean run spectacle --dbus in Konsole? I tried it in Konsole and krunner, and both give me nothing (no response and just a blink cursor in Konsole which can only be terminated by Ctrl+c).

Update:
This command does have an effect: after running it, there is a new process spectacle in System Monitor but no other effects.

Here are some results,

  • the “Call” button does not work (no response) and the “Launch D-Bus Browser” button has no effect either.
  • It seems I have no qdbusviewer or qdbusviewer-qt5 package installed in my system. And zypper search for these two names with default repos gives no result.
#8

Yes.
And you need to run it as user, not root (e.g. via su or sudo).

I tried it in Konsole and krunner, and both give me nothing (no response and just a blink cursor in Konsole which can only be terminated by Ctrl+c).

Of course, it keeps running and listens to commands via DBUS.
In other words, you should not terminate it with Ctrl+C before you try the other tests (clicking “Call” or running qdbusviewer).

I probably should have mentioned that, sorry.

Just to be sure, check again for running spectacle processes (and kill them) before you run it.

It seems I have no qdbusviewer or qdbusviewer-qt5 package installed in my system. And zypper search for these two names with default repos gives no result.

qdbusviewer-qt5 is part of the libqt5-qttools package which is required by plasma5-workspace (without it the desktop wouldn’t even start), so you definitely should have it installed. qdbusviewer is the Qt4 version and is part of libqt4-x11.

Btw, you can enter something like “cnf qdbusviewer” to find out which package contains a certain shell command or application.

#9

Ok, now I performed following tests in sequence,

  • Reboot my system;
  • Run spectacle --dbus in Konsole and keep it running;
  • Make sure there is spectacle in System Monitor;
  • Navigate to Settings -> Shortcuts and click “call” and “Launch D-Bus Browser” buttons.

But the buttons give me nothing. Maybe there is something wrong with my D-Bus Browser because I tried to activate the “Launch D-Bus Browser” button in other entry named “Perform D-Bus call ‘qdbus org.kde.krunner /App display’”, and it does not work either.

Thanks for these information :slight_smile:

#10

And what about qdbusviewer-qt5?
Is org.kde.Spectacle listed there?

The “D-BUS Browser” has nothing to do with whether “Call” or the shortcuts work. Actually this would just run qdbusviewer, which is a tool to display all D-BUS services and their methods and signals… It’s not needed at all for proper system operation.
The problem here is that we renamed the Qt5 qdbusviewer to qdbusviewer-qt5 in openSUSE (to make it not conflict with the Qt4 version), but apparently “forgot” to patch this settings module to run qdbusviewer-qt5 instead. (apparently you do not have qdbusviewer installed, but qdbusviewer-qt5 should be there as mentioned)

And if DBUS wouldn’t work in general, the desktop wouldn’t start either.

Btw, a workaround may be to just assign a shortcut to the spectacle menu entry in the menu editor…
(or create a new shortcut in the shortcuts settings that runs spectacle normally)

#11

PS: I found out why the “Call” button is likely not working.
It’s a similar problem as with “Run D-Bus Browser”, it runs “qdbus”, which we renamed to “qdbus-qt5”.

Apparently you don’t have libqt4 installed either? (that contains qdbus)

If you install it, that “problem” should be fixed. It will probably also fix the actual issue with the shortcut, as khotkeys itself would likely call the same function as the settings module’s “Call” button.
I would just find it strange that it worked on a fresh user account then… :-/

#12

@wolfi323, to reply to your previous 2 posts (I’ll skip the quote):

  1. On the “D-BUS Browser”

You’re right. I have qdbusviewer-qt5 in my system but not qdbusviewer. And, qdbusviewer-qt5 can open the “D-BUS Browser” even in my current profile.

  1. On the button of “Launch D-BUS Browser”

This button works in the fresh user profile although not in my current profile.

  1. On a new shortcut

I try to create a new global shortcut in System Settings -> Shortcuts -> Custom Shortcuts. I set it to be a “Command / URL” and set a hotkey for it. This works well although only being equivalent to what the old “PrtSc” can do.

If I select “D-Bus Command” and fill the fields with the same as those in the entry of “Start Screenshot Tool”, this won’t work.

  1. on libqt4

I checked with zypper search and found that I have libqt4 installed from repo of openSUSE-Tumbleweed-Oss.

  1. on the account

I merged my backed up account files into this new system. Maybe this merge caused the problem. And so, a fresh account does not have this problem.

Do you think it is possible to regenerate all user profile (my current account) without damaging the user data, those not originally included in user profile, in it? Or just the part related to dbus?

Thank you very much, wolfi. You are so knowledgeable about all these stuff.

Regards,
CnZhx

#13

So, does org.kde.Spectacle show up there, and does a Spectacle window open if you click on “Method: StartAgent” in org.kde.Spectacle?

  1. On the button of “Launch D-BUS Browser”

This button works in the fresh user profile although not in my current profile.

Hm.
So you do have qdbusviewer installed, but you cannot run it in the standard user account it seems.
It may be the same with qdbus.

What error message do you get exactly if you type “qdbusviewer” or “qdbus” into Konsole?
Does “/usr/bin/qdbusviewer” or “/usr/bin/qdbus” work?

  1. On a new shortcut

I try to create a new global shortcut in System Settings -> Shortcuts -> Custom Shortcuts. I set it to be a “Command / URL” and set a hotkey for it. This works well although only being equivalent to what the old “PrtSc” can do.

Spectacle does accept command line arguments.
E.g. “spectacle -a” or “spectacle --activewindow” will take a snapshot of the active window.
See “spectacle --help” for all of them.

May be a workaround until we can fix the problem.

If I select “D-Bus Command” and fill the fields with the same as those in the entry of “Start Screenshot Tool”, this won’t work.

Obviously.

  1. on libqt4

I checked with zypper search and found that I have libqt4 installed from repo of openSUSE-Tumbleweed-Oss.

Ok, it should be there by default, and libqt4-x11 (i.e. qdbusviewer) too.

I just thought it got uninstalled because you wrote that you don’t have those commands.
But yeah, as I already mentioned, it would have been strange then that it would work on a fresh account…

  1. on the account

I merged my backed up account files into this new system. Maybe this merge caused the problem. And so, a fresh account does not have this problem.

Yes, it’s obviously some problem with your user account.
The question is what.

Do you think it is possible to regenerate all user profile (my current account) without damaging the user data, those not originally included in user profile, in it? Or just the part related to dbus?

There is no “part related to dbus” in the user profile.
Actually there’s not even much like a “user profile” either.
There are just config and data files that are located in your home directory.

And as I indicated already, I don’t really think this could be caused by some broken config file really.

Maybe some user startup script “corrupts” the command path?
What do you get if you enter “echo $PATH” into Konsole? And “which qdbus”?

My main suspicion here still is that “qdbus” cannot be run for some reason, just like apparently “qdbusviewer” cannot be run for some reason, though it works on the fresh account.

#14

It’s not there initially, but it shows up if I run spectacle --dbus in Konsole.

“qdbusviewer” doesn’t work, but I think the error message doesn’t matter because “/usr/bin/qdbusviewer” works.

And after run “/usr/bin/qdbusviewer”, the “qdbusviewer” window shows up. There are two “org.kde.Spectacle” instances. I think one is the original one, and another one is the one I brought with the command in Konsole. I am not sure about the “original one” because when I use Ctrl+c to terminate the command, both of the two instances disappear.

P.S. It seems the qt5 viewer has a name of “QDBusViewer”.

“qdbus” works in Konsole. And it lists all the instances hooked into dbus. Do you think it would help if I paste the outputs?

Thanks a lot. Now I have a full working set of shortcuts for Spectacle.

Yes, libqt4-x11 is there too. I just didn’t realise I should check `` as well. Sorry for my ignorance.

By “user profile” I mean the configuration files. I just do not know the right way to address them. If this problem is not caused by certain configuration file(s), it’s really very weird.

The outputs of “echo $PATH” and “which qdbus” are here:

cnzhx@a:~> echo $PATH
/home/cnzhx/anaconda3/bin:/home/cnzhx/anaconda3/bin:/home/cnzhx/bin:/usr/local/bin:/usr/bin:/bin
cnzhx@a:~> which qdbus
/home/cnzhx/anaconda3/bin/qdbus

It looks like the “qdbus” is not the system default one but belongs to anaconda3. That’s really odd.

I have this in my ~/.bashrc file:

# added by Anaconda3 4.2.0 installer
export PATH="/home/cnzhx/anaconda3/bin:$PATH"

I will comment this line out and reboot to see if the problem disappear. And I will report here later.

#15

After commenting out the line for anaconda3 and a reboot, the original dbus method shortcuts work for Spectacle now. I think the problem is solved. Now I just need to reinstall the anaconda3 or find a way to reformat the export PATH="/home/cnzhx/anaconda3/bin:$PATH" in my ~/.bashrc file. It doesn’t affect my system before this system reinstallation and copying back of my user directory. Maybe I should not copy back the export PATH="/home/cnzhx/anaconda3/bin:$PATH" line into .bashrc file instead of reinstall anaconda3 for my laziness. I thought this is the only thing I need to bring back anaconda3 in this new system since I copied back all the files including configuration files from my old account, and I have make sure the old system is upgraded to the same snapshot of the new openSUSE Tumbleweed with the new system.

Thank you very much, @wolfi323. You are amazing and very patient on helping me.

Best Regards,
Haoxian

#16

Oh well.
So it is another instance of problems caused by the (IMHO) broken Anaconda installer.

It already caused problems for starting Plasma at all.
See here: https://forums.opensuse.org/showthread.php/520677-Could-not-start-D-Bus-Can-you-call-qdbus-qt5 or https://forums.opensuse.org/showthread.php/520628-Could-not-start-D-bus-Can-you-call-qdbus-qt5/page3

I implemented a workaround for that back then, but didn’t think about khotkeys…
And TBH, I don’t think this can/should be fixed from our side, the Anaconda developers would need to fix their installer IMHO.

I already wrote in that second thread:

But I still think that Anaconda’s installer should not “replace” the qttools for the user. This could break other things too which use qtpaths, not just startkde.

Turns out I was right.
Although apparently it also breaks things that are not using qtpaths… :\

But at least we found the cause of your problem now! :wink:

#17

Without your help, I could never find out it is caused by Anaconda3. It adds the PATH statement to introduce its packages. I think the real reason is that I replaced my .bashrc too early after the system installation caused the /usr/bin/qdbus has no chance to initiate the configurations. After I commented out the statement yesterday, and reboot, then the dbus call and DBus Browser work fine now. Then, I active the statement of Anaconda3 in .bashrc, reload .bashrc, then,

cnzhx@a:~> which qdbus
/home/cnzhx/anaconda3/bin/qdbus

But the Shortcuts still work ,and the dbus call and DBus Browser work fine too.

Do you think the sequential order of the paths in $PATH matters? Could I change the statement,

# 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"

to make the system load /usr/bin/qdbus other than /home/cnzhx/anaconda3/bin/qdbus?

#18

@wolfi323, after reading through the 2 links you provided earlier, I realise it’s not a good idea of change the sequential order as it makes the statement of Anaconda3 in .bashrc has no effect to Anaconda3. I will change the $PATH before and after using Anaconda3 as a workaround. I think it’s not a good idea for Anaconda3 to change the path to system binaries to its own packages too.

#19

I don’t think that’s the reason.
There are no configurations for this, and login runs qdbus-qt5 anyway.

Do you think the sequential order of the paths in $PATH matters? Could I change the statement,

# 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"

to make the system load /usr/bin/qdbus other than /home/cnzhx/anaconda3/bin/qdbus?

Actually it should not matter in this case which version of qdbus (or qdbus-qt5) is used.

The problem seems to have been that /home/cnzhx/anaconda3/bin/qdbus apparently refused to run for some reason.
I have no idea why that was or why it obviously works now, as you never answered my question about what error message you get when trying to run qdbus manually… :wink:

#20

It would have effect, the commands in /home/cnzhx/anaconda3/bin/ would be found “automatically” without having to use the full path.
But the commands in (e.g.) /usr/bin/ would be preferred over the ones in Anaconda’s directory.

I don’t know Anaconda, but that should be fine normally, unless you explicitly want to replace the system commands with other versions.
Anaconda itself should not be installed in /usr/bin/ anyway, so this probably only applies to the qttools it ships with. I have no idea whether Anaconda needs its own versions and break when using the system’s one or whether everything would work fine though…

But yeah, IMHO the best way is to create a specific Anaconda script that sets up the environment, and only run that when needed.