Ubuntu22.04 desktop with LUKS, GNOME 42.9 FileManager: Nautilus (alias Files) 42.6
I set Geany as the default application to open text files from the FileManager GUI if i click on a .txt file then Geany doesn't get focus, instead an alert/dialog is displayed which disappears after a few seconds, this alert/dialog contains the geany logo and the file name, to be able to assign focus to Geany I have to switch between running programs with ALT+TAB
I checked what happens with other editors with Gedit and Libreoffice it doesn't occur, it only occurs with Geany more specifically, it does not occur if you double-click on the file, then all works however, it occurs if you open the context menu with the keyboard menu key > open file >
with Dconf Editor searched the Nautilus configurations also searched in geany configurations ~/.config/geany/geany.conf still didn't solve
Since it works from the file manager this looks most likely to be your desktop setup. Set the keyboard shortcut to run exactly the same command as the file manager runs on double click.
The dialog with Geany logo and the filename is not something Geany creates AFAIK, its more likely to be your desktop.
It is not a mystery, and has nothing to do with Geany. I have the identical issue, and have been researching and studying the topic for months. I am also using Kubuntu 22.04.2, and its GTK/Gnome relative, Linux Mint Cinnamon 21.2.
The initial focus acquiring behavior was taken over by the window one is working in. In this context, the desktop is counted as a window. This also applies to opening Firefox where the home page is DuckDuckGo.
Running Geany, or any other software, from a .sh file, is the only quick solution I can think of. This would set the focus after Geany is open. ` 'xdotool click window = activetitle_ 1' `. I haven't tried this particular code but most of my apps' .desktop files use .sh files to accommodate shell commands before or after starting an app.
I hope this helps, but I feel that this is not a good long term solution.
Correct, X11 tools don't necessarily work on Wayland systems which is where the world is going.
On the other hand, this may be resolved from within Geany.
This part cannot, see https://github.com/geany/geany/discussions/3538#discussioncomment-6648470
Same here, Ubuntu 22.04 & 23.10. Very annoying, I have to click twice every time. Even if I reload a file from Filezilla, I have to click on Geany to get it on screen. Please, find a way to fix this.
First a comment, with Linux Mint Cinnamon, default settings, open-in-geany in the file manager (Nemo) always brings Geany to the front with the notebook page containing the selected file having focus, both when Geany is first started, and when the selected file is added to an open instance.
Everybody who is complaining, the problem is not with Geany, it is with your window manager and/or the settings you use that tell the window manager not to grant Geany's focus request. Perhaps enquire on your window manager support what settings need to be changed, or if you need to use a different window manager.
Any other apps, working perfect. They get focus. Everything exept Ver.38 of Geany. Damn, I wish had never update!
As I said, it works for me, and I presume for other main contributors to Geany since none have commented. Since it can't be reproduced "somebody" who has the problem needs to provide a reproducing environment and debug what if anything other apps do different to Geany if they work.
Note that Geany is a portable GTK application available on Gnome, KDE, Xfce, Windows, Macos so it does not use any desktop specific APIs that other less portable apps might use. But if "somebody" wants to contribute and support a desktop portability library for such specific functions it would likely be accepted.
I forgot to mention that my comments are exclusively about the X11 windowing system. Also, that apps can monitor movement and easily set focus to themselves. Of the two apps mentioned, I know observed that LibreOffice has a history of increasing sophistication.
Note that Geany is a portable GTK application available on Gnome, KDE, Xfce, Windows, Macos so it does not use any desktop specific APIs
To be clear, Gedit is a [Gnome](https://wiki.gnome.org/Apps/Gedit) application, it is "integrated with that desktop" to quote the linked page, not a plain GTK application like Geany.
As @ineuw says Libreoffice has the resources to maintain integration with individual desktops, so for example Debian has a [libreoffice-gnome](https://packages.debian.org/sid/libreoffice-gnome) integration package and I am aware of an evolution integration package and I am sure it has specific integration with Windows and Macos.
From the OP, specific to the use case of Geany and Nautilus under Gnome... this is mutter's focus-stealing prevention at work.
I found this still-open issue here as I was searching for a feature request with Geany to implement the [XDG Activation protocol](https://wayland.app/protocols/xdg-activation-v1).
A nice explanation and discussion of [how it all works](https://discourse.gnome.org/t/understanding-gnome-shell-s-focus-stealing-pre...) was recently posted on Gnome Discourse. That reminded me...
...For a long time now, and specifically to solve the use-case noted in the OP, I've been employing [a very simple extension](https://extensions.gnome.org/extension/6385/steal-my-focus-window/) to work around this issue, and to immediately focus Geany when opening files from Nautilus file manager.
One key point missing from the OP is that if Geany is not running, the first time a file is opened from Nautilus, a Geany window will open and gain focus. I.E..
1) With no Geany instance running, click to open txt file from the Nautilus UI (Geany opens a new window and it gets focus). 2) Click to open any number of subsequent files from the Nautilus UI (files _are_ opened in Geany, _but_ the existing Geany window does not get focus (and the ["...is ready" notification toast](https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/358) is displayed) in Gnome. This is the focus-stealing prevention.
Should a new issue be filed specifically to request the XDG Activation protocol implementation in Geany?
Thanks for the research, that looks like the cause of the Gnome problem and why it works just fine on other compositors that don't try to enforce their idea of how things should work.
Should a new issue be filed specifically to request the XDG Activation protocol be supported in Geany?
It should not need anything in Geany. GTK is what is communicating with the Wayland compositor (or X11 or Windows or Macos) but Geany does not know which backend is being used by GTK, and also there is no way of passing a token to GTK when [requesting focus](https://docs.gtk.org/gtk4/method.Widget.grab_focus.html).
GTK knows which backend it is using and if it should get the token and supply it to the compositor on Wayland or not on other platforms. Probably GTK hasn't caught up with the activation yet, and the Wayland activation protocol is still "Warning! The protocol described in this file is currently in the testing phase.". And if/when it is added it will be to GTK4, GTK3 which is used by Geany will probably never get the capability.
So its probably not worth adding a Geany issue that will likely bitrot, but maybe you could raise it with GTK.
PS I'm not sure it will work anyway, how does Nautilus know which process will want to focus, its the first Geany that subsequent files open in new tabs, not the no GUI process that Nautilus runs that sends the request to the first Geany. So how does Nautilus know what window to get the token for?
Thank you for the rationale you explained here.
As an example... I don't use chrome/chromium (also a GTK3 app) as my browser, but it was big news this year when they [started supporting XDG Activation](https://chromium-review.googlesource.com/c/chromium/src/+/5280365), allowing links from other apps to bring the browser window to the front, closing a [long-standing issue](https://issues.chromium.org/issues/40747285).
I was under the impression apps (at least on Wayland) needed to be modified to support this behavior. I'll poke around with the GTK folks to see if I can glean anything further in regard to this behavior with Geany under Gnome/Wayland (no X11 or Xwayland here).
EDIT: Oh, yes... GDK3 support [landed](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3489) in v3.24
I don't use chrome/chromium (also a GTK3 app)
I thought chromium used skia not gtk and did everything itself.
I was under the impression apps (at least on Wayland) needed to be modified to support this behavior.
Well [the merge](https://gitlab.gnome.org/GNOME/gtk/-/commit/2703e420ae9519205cf1b351edcd19b0...) has no documentation so it would be reasonable to assume it all happens inside GTK and no changes are required of the apps?
I'll poke around with the GTK folks to see if I can glean anything further in regard to this behavior with Geany under Gnome/Wayland (no X11 or Xwayland here).
Ok.
GTK3 apps like Firefox and LibreOffice
Don't think they are gtk either, didn't look at firefox but libreoffice has backends based on qt, skia, quartz, win, but not gtk.
Hmm, okay. Perhaps I lack some fundamental understanding here. If so I apologize for the noise.
Going back to the original Wayland protocol [merge](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/50) itself, we see it's pretty toolkit-agnostic at this point:
- Qt client support: https://codereview.qt-project.org/c/qt/qtwayland/+/321246 - KDE server framework: https://invent.kde.org/plasma/kwayland-server/-/merge_requests/130 - KWin's implementation: https://invent.kde.org/plasma/kwin/-/merge_requests/434 - Mutter: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1845 - GTK: http://gitlab.gnome.org/GNOME/gtk/commits/wip/carlosg/xdg-activation-3-24 - wlroots: https://github.com/swaywm/wlroots/pull/2718
And currently has been, or is being requested to be, implemented by apps across these various frameworks [Electron](https://github.com/electron/electron/issues/30912) recently was a biggee for many folks, similar to this year's Chromium support.
As for chromium, FF, Libreoffice apps, I think you're correct but referring to their rendering engines, whereas they all use GTK to present their windows/decorations and widgets?
Firefox has been GTK3 for 7 years now.
Libreoffice (GTK3): `Version: 24.2.6.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 24; OS: Linux 6.10; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US 24.2.6-4 Calc: threaded`
Off-topic here... but I'm sure you can find relatable... they all have their respective user's clamoring for a GTK4 port haha!
Both LibreOffice and Chromium have experiment support for GTK4: https://wiki.documentfoundation.org/Development/GTK4 https://chromium-review.googlesource.com/c/chromium/src/+/1187197
Firefox not so much: https://bugzilla.mozilla.org/show_bug.cgi?id=1701123
Anyhow, I'll investigate further my assertion that some change needs to be made to the Geany client to support the activation mechanism. Thanks for taking time with meaningful responses here.
IRO libreoffice, I think you are right, GTK is the default UI library and is built in to the code so it doesn't have a gtk directory in https://github.com/LibreOffice/core/tree/master/vcl where all the alternative UI libraries are, and that confused me.
Something similar might be the case for the other apps you listed too.
One thing to be clear about, listing large well supported projects like Libreoffice, Firefox, or Chromium is pretty irrelevant to Geany which is a volunteer project and is unlikely to add backend specific code (Wayland in this case), we have in the past expunged an amount of X11 specific stuff, and we expect GTK or other portable libraries to handle backend specifics, not us. We simply don't have the resources to do Wayland specific token handling that big projects might do.
As I said before, I can't see where GTK makes Wayland activate tokens available to applications so they can handle it, and in my opinion it should not require the application to do anything.
Although I havn't examined it closely, possibly the activation token is one of the things handled by the `GtkApplication` object in "primary and local" mode in a way that it should not leak to the application. Geany does not use `GtkApplication` as it was written long before that existed, and last time it was examined `GtkApplication` didn't handle Windows or provide some of the features that Geany's primary/local implementation gave. If somebody wants to examine in detail that might be useful.
The reasoning behind preventing "evil_app" for example from popping its own version of the password dialog over the top of the real one to read the password is good. But IMO the implementation is wrong, the password dialog should be able to be identified as secure and prevent any interaction with any other windows so it is guaranteed the password will go to that. Sure its complicated for the secure password feature, but that way it does not impinge on every other application.
As for GTK4 ....... [deep breath] ...... (bearing in mind I am not a GTK expert but I am quoting one ;-) ... GTK4 is missing a number of features that Geany (and likely other complex apps) use. IIUC we would have to make our own widgets to maintain those features, but in C (not C++) that is a lot more work than the port from GTK2 to GTK3. And the Scintilla editing widget which is the main window is not planning to include GTK4 support "soon" due to how much [difference](https://groups.google.com/g/scintilla-interest/c/RX4kQkWJBk8/m/80XWNgucAwAJ) there is.
So Geany has put GTK4 on the nearest backburner and turned the gas down to off.
@tekstryder Does #4071 fix your problem?
Closed #3531 as completed via #4071.
@tekstryder Does #4071 fix your problem?
Sorry for the delay.
Indeed, https://github.com/geany/geany/pull/4071 allows me to disable the Gnome extension and use Mutter's default focus-stealing prevention without issue now.
This is awesome. Thanks so much!
github-comments@lists.geany.org