Gedit from the command line: new window or tab?

Applications
1

Modified 4 days ago

Viewed 31 times

0

I’m trying to customize the behavior of gedit when I launch a new instance from the command line. In the past, the default was “open a new tab if there’s a existing window in the current workspace, otherwise open a new window”. At some point, this shifted to “open a new tab if there’s a gedit window open anywhere, otherwise open a new tab in another window seemingly chosen at random”. The new behavior is kind of annoying, and I’d like to recover the old behavior.

After some searching, the closest I could find was this thread configure gedit to always open in new window - Ask Ubuntu, where the author wants to always open a new window when a text file is double clicked. That’s not what I’m looking for, but it does suggest editing gedit’s behavior with gsettings. After looking through my gsettings options, the only one that seems to be related is show-tabs-mode. Currently, it’s set to “auto”. When I set it to “never”

gsettings set org.gnome.gedit.preferences.ui show-tabs-mode never

I get the behavior that when I open a file with gedit from the command line, the new window replaces a tab in an existing window, even if that window is in another workspace. That’s really not what I want.

I’d be grateful for any ideas!

For context, I’m running xfce on a gentoo system. It’s possible that xfce just doesn’t play well with gnome applications, but I’m optimistic since this behavior did exist in the past.

1 Like
2

Hi,

Thank you for asking the question.

Short answer: because of Wayland.

Longer answer

Wayland doesn’t support this feature. Wayland (instead of X11) is the future, and it’s the window manager (gnome-shell, or the one from Xfce, etc) which decides more things related to open new windows, where to place new windows on the screen, etc.

So… unfortunately the gedit feature you describe (with the workspaces awareness) has been removed.

BUT! It would be possible to bring the feature back. gedit still uses GTK 3, and GDK 3 (GDK is part of GTK) has X11-specific APIs with the workspaces etc.

I think that, if one day gedit is ported to GTK 4, the feature would no longer be possible (easily).

Also, how it was implemented in gedit, it used a X11 library directly instead of using the friendlier GDK 3 API.

Since gedit used (and needed to be linked against) the X11 library, gedit with Wayland relied on XWayland to work on a Wayland compositor. Now, when running gedit on Wayland, it’s a native app (“pure Wayland”).

By adding some GSettings keys and by using the GDK 3 APIs, the feature can be brought back for those still using X11, and still be a native Wayland app.

So, if you want, you can take an older version of gedit where the feature isn’t removed. After all, it’s free software :wink: Read or search the NEWS file to know when that feature (related to Wayland) has been removed.

If someone is motivated, contributions are more than welcome to implement what I said. Or (easier), a branch can be maintained and rebased from time to time with the old implementation that relied on the X11 lib directly.

Edit: I know that Xfce uses X11 and not Wayland currently, a sentence above was not really clear about it (I was talking about window managers).

3

If you didn’t understand everything, don’t hesitate to ask questions. My longer answer above is quite technical.

4

The only explanation I can find that makes you find it annoying is that you have set gedit as your shell $EDITOR, and when the shell prompts you to edit a file it returns immediately without waiting for you to save the file.

If that is the case, you must set $EDITOR to gedit -w. That means:

export EDITOR="$(if [[ -n $DISPLAY ]]; then echo 'gedit -w'; else echo 'nano'; fi)"

EDIT: After better reading your message I understood that you were annoyed by something else. So please ignore this message.

1 Like
5

Nice tip nevertheless :wink:

6

Neat, I wasn’t aware of the $EDITOR environment variable!

swilmet, thanks for the context here. If I was more of UI developer I’d probably jump in! But, it sounds like rolling back to an older version of gedit might be the answer. Actually, this is really useful to know that it’s in the application, not the configuration files. I was convinced that I could solve this with gsettings.

8

(Sorry I was wrong about the previous reply, that doesn’t seem to work anymore)

9

Oh, there was already a GitLab issue about this:

(it shows which functions to use from GDK).

10

Okay, I’m trying to install an older version of gedit from git

gitlab.gnome.org/GNOME/gedit/-/tree/gnome-3-38-fix-build?ref_type=heads

But, I’m getting this message when I follow the steps in build.md

…/meson.build:32:19: ERROR: Subproject exists but has no meson.build file.

This is my first time using meson, or building from a gnome git. Any ideas? Or, should I get the source from somewhere else?

11

There are easier approaches, for example with a Flatpak manifest: either the one from Flathub, or the one from upstream gedit (in the build-aux/ directory).

There is JHBuild also.

Or since you are on Gentoo, perhaps take an older version of the ebuild file for gedit and gedit-plugins.

Edit: BTW, Flatpak (or Snap) has been designed explicitly for this kind of purpose (among others), to choose the version of an app that we want, decoupled from the OS.

12

I wanted to add: building gnome modules has always been a bit difficult, due to the nature of the multiple git repositories that are involved (the libraries in addition to the app).

13

Just to close the loop here, I attempted to install an older version of gedit via my OS’s installer. At first glance, this was not an option, since only very recent versions are available. After some digging, I did find a tutorial on how this might be done, but I actually had to start another thread on the gentoo forum to figure it out. This was a really informative experiment, but the consensus was that it probably wouldn’t work. Here’s a link that that thread.

https://forums.gentoo.org/viewtopic-p-8809695.html#8809695

Thanks all for helping with this! Although we didn’t find a resolution, maybe the gnome development team will weigh in some of the thoughts here for future releases.

14

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.