On Fedora 27 / Wayland, default install, Geany 1.31 In Nautilus, after associating a file type with Geany (e.g. .log or .txt), opening the file creates a new geany instance if there was none, or a new tab in geany if there was an existing instance. The small annoyance is in the latter case - the new tab is created and the file is loaded, however if Geany's window is not brought to the front nor put in focus
Geany > Preferences does not seem to expose any setting to control this behavior. Gedit's behavior for the same use case is as expected: a new tab is open and Gedit's window is brought to front and given the focus.
I believe Geany's behavior up until some six months ago (1.29?) did not have this problem
I believe Geany's behavior up until some six months ago (1.29?) did not have this problem
Were you using Wayland at that time?
I believe my switch to GNOME 3.22 somewhat changed the "bringing in front" behavior. For example the same version of Firefox doesn't get brought to front (most of the time) when following a web link from e.g. Thunderbird.
In any case, I don't believe anything changed in Geany to that regard, so I would first try and investigate if it's not another component that changed behavior (likely the window manager), and then whether other apps work as expected, and if they do check what Geany should do.
I switched to wayland about six months ago too. I just tested the exact same workflow on an X11 session and on a Wayland session. X11 sessions do NOT have this problem. On Wayland, this is reproducible 100% of the time.
Also tried the following: invoking geany from an xterm with different GDK backends:
xterm with Wayland as GDK Backend - same problem reproduced, same behavior as observed when opening files from nautilus, the existing instance is used to open the second file in a new tab but geany is not brough up to front
xterm with XWayland as GDK Backend - no issue: opening the second file causes geany to be brought to front, with the new file in a new tab
More like a bug in the window manager, or rather a continuation of an existing bug, note the workaround hack to make it work on some X11 window managers [here](https://github.com/geany/geany/blob/ca16aff4c5cb73ccb6b1c9db58389a33ad027e4f...).
Try gedit on wayland or better yet file a bug report to get Gnome to work properly so apps don't need workarounds.
Hum, interesting. Yeah, sounds awfully buggy, and looking at GEdit's code it will suffer from the same problem, so no way to even copy a workaround from there.
@arigit could you try the hack from [the last commit](https://github.com/b4n/geany/commit/94e46963f351f5b66dbe0b5c80cff21fd6d158d7) on https://github.com/b4n/geany/tree/wip/present-window-time? I have no real idea if it has any chance to help, but who knows. Otherwise, try and pass `GDK_CURRENT_TIME` as the timestamp and see if it works under Wayland (it doesn't under X11, but we have a hack there).
It is reported but doesn't seem to be going anywhere https://bugzilla.gnome.org/show_bug.cgi?id=766284
A while ago, tilix (gtk3 terminal emulator) had the same problem and they got it fixed
https://github.com/gnunn1/tilix/issues/849 https://github.com/gnunn1/tilix/issues/932
Was that commit supposed to fix it? Because tilix --focus-window --action=app-new-session still doesn't work. A new tab is opened, the window just isn't focused.
They talk about the same GTK bug in the discussion.
https://github.com/gnunn1/tilix/commit/84abb55043b5ad6273bb8fc74967b90ab2453...
The fix seems to be along the lines of what @b4n mentioned above. The code is in D but but idea seems to be the same
``` if (isWayland(window)) { + trace("Present Window for Wayland"); + window.presentWithTime(Main.getCurrentEventTime); } else { + trace("Present Window for X11"); window.present(); activateX11Window(window); } ```
it did fix the problem - bug 932 above about window focus problems under Wayland was mine and was solved
@b4n tested the change from https://github.com/b4n/geany/tree/wip/present-window-time
It works! it fixes the problem.
Tested side by side fedora 27 geany (1.31) and your fork with the patch, on xterm with Wayland as GDK Backend. 1.31 opens new tabs but doesn't get focus, whereas the patched version opens the new tab AND grabs the focus / bringing the window to the front when needed.
@argit thanks for the input, but IIUC your last comment on [`#932`](https://github.com/gnunn1/tilix/issues/932) it works when you are using tilix on x11 on top of wayland. If you run Geany the same way it should work, but as the other comments say the problem is not fixed for tilix run on bare metal wayland.
The [wayland protocol](https://cgit.freedesktop.org/wayland/wayland/tree/protocol/wayland.xml) simply does not seem to provide any way for applications to control window/surface presentation, but the X11 protocol does. So the only way wayland compositors/window managers can present windows is from user interaction ATM. All the timeout stuff is for X11, to handle its asynchronism. It is unlikely to change the situation on bare metal wayland.
`<rant>` basically wayland is broken`</rant>`
@elextr ooops :) - you are absolutely right - I didn't even read my own comments there. Actually tilix works OK in my current setup b/c I changed the backend to X11 in the tilix .desktop file, that's still the case as of today.
On the other hand, the changes in geany by @b4n indeed fixed the problem on wayland, no "env GDK_BACKEND=x11" workaround needed
`GDK_BACKEND=x11` is the default, you need to set the environment variable to `GDK_BACKEND=wayland` [see](https://developer.gnome.org/gtk3/stable/gtk-wayland.html) and I suspect you need to have built Geany with `--enable_gtk3`, I don't think GTK2 supports wayland at all.
Yes - that's how I tested it, with GDK_BACKEND=wayland, which is also the default in Fedora 27 gnome-terminal. Yes - I built Geany with GTK3 support, using the Fedora 27 .spec with rpmbuild.
Confirmation from the debug window: 23:04:07: Geany INFO : Geany 1.33, en_CA.utf8 23:04:07: Geany INFO : GTK 3.22.26, GLib 2.54.2 23:04:07: Geany INFO : System data dir: /usr/share/geany 23:04:07: Geany INFO : User config dir: /home/ariel/.config/geany 23:04:07: Geany INFO : System plugin path: /usr/lib64/geany 23:04:07: Geany INFO : Added filetype Arduino (61). 23:04:07: Geany INFO : Added filetype Graphviz (62). 23:04:07: Geany INFO : Added filetype Scala (63). 23:04:07: Geany INFO : Added filetype Genie (64). 23:04:07: Geany INFO : Added filetype CUDA (65). 23:04:07: Geany INFO : Added filetype JSON (66). 23:04:07: Geany INFO : Added filetype Clojure (67). 23:04:07: Geany INFO : Added filetype Cython (68). 23:04:07: Geany INFO : Disabling terminal support 23:04:07: Geany INFO : Loaded: /usr/lib64/geany/addons.so (Addons) 23:04:07: Geany INFO : unknown : None (UTF-8)
Before building and installing the new RPM package, I tested compiling and running b4n's patch, directly from the source tree, and compared side by side with 1.31 that was installed in my system. 1.31 has the problem, 1.33+patch hasn't. Finally I replaced the orginal package with the new rpm build. The issue is gone.
Ok, don't know how or why it works, or if it will keep working, but fine for now. I know there are wayland users out there, I wonder why they havn't complained before?
I just checked - in Fedora 26 and prior, geany was built against GTK2.
They just switched to GTK3 with fedora 27, released two weeks ago.
Sure, thats the first mass release, even Arch is still GTK2, but there are other adventurous souls who have used it with wayland before I believe, have enquired, will see what the reply is.
@elextr they probably didn't notice or bother because it's not a terrible bug either, it "just" doesn't bring the window in front, which would also happen if Geany was slow enough to react so the user could have done other interaction in between.
Regarding my workaround, I read somewhere (after) that it should at least work on GNOME Wayland because the compositor there will use the same here as x11, that is monotonous milliseconds. Not sure if other compositors would work the same or not, but I guess it wouldn't be worse than the current status -- well, unless it leads to illegitimate focusing, but as we only do that on explicit user action it should be good in any reasonable situation.
@b4n sure no reason not to apply the patch, but as you say, no guarantees it keeps working, or works with other WMs.
PS s/monotonous/monotonic/ damn English :)
@b4n have you PRed your patch yet?
Found this while looking to see if another issue I was looking to deal with had already been reported or not, grabbed the patch and can report that the workaround no longer works. Checked gedit for a quick sanity check and gedit seems to have this implemented, so there's probably some inspiration that can be taken from there.
Still persists with GNOME 42.2 /Wayland. Cross-checked with other applications. Only Geany shows this behavior.
Nobody seems to have made a PR of the original patch, or (if its no longer working as reported above) the suggested alternative.
github-comments@lists.geany.org