Nautilus / wayland integration: bring Geany to front when opening a new tab in existing instance

[arigit]

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 Geany's window is not brought to the front nor put in focus, it remains in the background.

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

[codebrainz]

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?

[b4n]

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.

[arigit]

I switched to wayland full time 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

Tested with Web/epiphany (gnome's web browiser, Wayland/native, tabbed UI), it shows the same issue as Geany under wayland, a new instance is created with the first file opened, and the second one creates a new tab, but the app is not brought to the front. Not sure if this shows that this is a GTK / wayland backend bug - or both Web and Geany have the same bug

[elextr]

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.

Try gedit on wayland or better yet file a bug report to get Gnome to work properly so apps don't need workarounds.

[b4n]

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 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).

[elextr]

It is reported but doesn't seem to be going anywhere https://bugzilla.gnome.org/show_bug.cgi?id=766284

[Edit: note the number of duplicates, just about all apps listed]

[arigit]

A while ago, tilix (gtk3 terminal emulator) had a similar problem and they got it fixed

gnunn1/tilix#849
gnunn1/tilix#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.

gnunn1/tilix@84abb55?diff=split

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

[arigit]

@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.

[elextr]

@argit thanks for the input, but IIUC your last comment on #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 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>

[arigit]

@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

[elextr]

GDK_BACKEND=x11 is the default, you need to set the environment variable to GDK_BACKEND=wayland see and I suspect you need to have built Geany with --enable_gtk3, I don't think GTK2 supports wayland at all.

[arigit]

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.

%build
%configure --docdir=%{geany_docdir} --enable-gtk3

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.

[elextr]

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?

[arigit]

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.

[elextr]

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.

[b4n]

@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.

[elextr]

@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 :)

[elextr]

@b4n have you PRed your patch yet?

[Davidy22]

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. A quick grep of the gedit source tells me that they do a gtk_window_present on the main window after opening a file, while geany seems to only do it with little popup dialogs

[rhersel]

Still persists with GNOME 42.2 /Wayland. Cross-checked with other applications. Only Geany shows this behavior.

[elextr]

Nobody seems to have made a PR of the original patch, or (if its no longer working as reported above) the suggested alternative.