kupfer
kupfer copied to clipboard
kupferlauncher
Main window appears and vanishes immediately
I tried kupfer and I like it (when it works) but I'm having a debilitating issue.
Environment
Kupfer Version: 310 Window Manager: Mutter Desktop Environment: Gnome 3.22 Linux Distribution: Arch Linux
Actual Behaviour
Many times, on pressing ctrl +space I get the kupfer window for an instant and then it vanishes. This is especially true when there's some program running (Chromium, Libreoffice)
Expected Behaviour
The main window should remain open until Enter is pressed of some search result clicked.
CLI Errors
[kupfer.ui.browser] WindowController: Trying to register <Primary>space to spawn kupfer.. success Error [kupfer.ui.session] SessionClient: org.gnome.SessionManager.AlreadyRegistered: Unable to register client [kupfer.ui.session] SessionClient: Warning: Not able to connect to current desktop session, please Quit before logout to save kupfer's data.
My two cents go on mutter's focus stealing prevention. My theory is that kupfer appears, but mutter tries to keep the keyboard focus on the previous application that had focus, thus kupfer disappears on losing keyboard focus.
Your comment made my test something. If I place the mouse pointer where I expect the Main window to pop up and press ctrl + space, the window doesn't disappear. If the mouse pointer is anywhere else on the screen, the window disappears.
Thanks. Linux is very diverse, so we need reports and contributions from users across the board. Is it possible for you to experiment with the code?
(1.)
I'd try to comment out self.window.get_window().focus(timestamp=timestamp) on line https://github.com/kupferlauncher/kupfer/blob/master/kupfer/ui/browser.py#L2269
I think we are doing things correctly here, using the event timestamp and so on. However the event timestamp comes from “outside” GTK because it's from a global keybinding.
(2.)
How does it behave if kupfer is already running, and you run kupfer from the terminal or just run the application starter (.desktop file) again? Does it focus kupfer correctly?
Oh the mouse issue makes it sound like kupfer disappears at its own volition - by the mechanic that it hides itself when it loses focus.
I'm no programmer but could test builds. The AUR contains a git version of kupfer that I haven't installed. I could install that one if that helps testing.
It's probably outdated? It would help a lot if you used git to get kupfer from this repo.
The version I'm using was updated yesterday https://aur.archlinux.org/packages/kupfer. I do not use focus follows mouse but when I scroll the window under the mouse pointer scrolls without it stealing focus. When I run kupfer from terminal while it is still running, the same thing happens. That is, if the mouse pointer is in the center of the screen, the main window appears and stays. If it is somewhere else, it appears and vanishes.
It's probably outdated? It would help a lot if you used git to get kupfer from this repo.
It builds from git master head everytime you run makepkg.
Ah nice. Note that the same quality assurance isn't necessarily true of the master branch as of the releases. Though I suppose both are looking pretty good, we're not randomly breaking things that work.
I've tried just mutter --replace (mutter 3.22.2), and that is not enough to reproduce this issue. Maybe it's some other part of the gnome shell session.
There's experimental code (which will go away) in the current master and 311.
Quit kupfer and then start it using KUPFER_NO_HIDE_ON_FOCUS_OUT=1 kupfer. If you are used to hide on focus out, this is a bit annoying, but it's fine to use kupfer this way really. First question is; does it work for you?
I tried it and it works, but as you said it is a bit annoying to dismiss the main window.
I tried it and it works, but as you said it is a bit annoying to dismiss the main window.
But does Kupfer have the keyboard focus when it appears? That is important. Because if Gnome makes sure Kupfer can't steal the keyboard focus (focus stealing prevention levels can be set in KDE for examle) then there is nothing Kupfer can do about this. You have to find a setting in Gnome that would allow other applications to get the keyboard focus on activation.
It should have, it uses present and focus with an event timestamp (Source of the event timestamp can be from startup notification if you use the kupfer desktop file, or from the keyboard shortcut if you use that.)
XFCE at least has support for sending startup notifications when starting its global keybindings, too.
Synapse seems to manage this well. I don't know if the programming language used is the same, but maybe we could see how they manage it.
On 23 Feb 2017 9:28 am, "bluss" [email protected] wrote:
It should have, it uses present and focus with an event timestamp (Source of the event timestamp can be from startup notification if you use the kupfer desktop file, or from the keyboard shortcut if you use that.)
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kupferlauncher/kupfer/issues/51#issuecomment-281927122, or mute the thread https://github.com/notifications/unsubscribe-auth/AHQdgJwoDdT_TDdCXTwrQNWDOhT7hJMVks5rfUMogaJpZM4MIZXH .
As long as it's language we can read. They use Gtk as well, so that important part is the same. I'll take a look.
I see now that several things are different. Kupfer is a regular window, Synapse uses "SPLASHSCREEN". Kupfer wants the window to be movable with the pointer and you can interact with it using the mouse as well as the keyboard. They also use a pointer/keyboard grab. We could use the keyboard grab part, not sure if that makes a difference.
New temporary knob to tweak in git, I'd try KUPFER_WINDOW_TYPE_HINT=splashscreen kupfer that one or try normal.
All possible values: https://lazka.github.io/pgi-docs/index.html#Gdk-3.0/enums.html#Gdk.WindowTypeHint
Some of them have strange effects.
Seeing this as well, under gnome-shell. Interestingly, it used to work in gnome-shell under Ubuntu 16.04, seems to have started under 17.04. I could be wrong though, it's hard to remember things like this properly. I see exactly the same behaviour as the OP, disappears immediately, stays if I have the pointer where the window will appear.
