I’m looking to see if there’s some way to make gnome-text-editor handle opening files the way gedit did.
The way gedit used to work was something like this (when clicking on a file icon):
If there isn’t a text editor window open in the current active workspace, open the file in a new text editor window.
If there is a text editor window in the current active workspace, open the file as a tab in it.
The way gnome-text editor is operating is like this:
If text editor isn’t running, open the file in a new window in the current workspace.
If text editor is running in any workspace, open the file as a tab in that window and alert that the file is open.
In short – I’d like to get gnome-text-editor to ignore instances running in other workspaces.
The closest I’ve found to this is to configure gnome-text-editor to always open a new window… but that’s not ideal, since tabs really do a nice job of keeping things uncluttered. I would just like to be able to keep groups of files separated in different windows more easily.
We would need to add some new API (probably a Wayland protocol?) to allow apps to figure out what workspace they’re using. gedit was using libwnck for this, but that only worked under X11.
You definitely don’t want applications to query the workspace they are in, and store that information.
At most, we’re going to need a Shell-specific protocol that says “please activate the application within an existing workspace”, but even there it’s quite complicated to handle at the toolkit level.
You probably confuse libwnck with something else, because gedit has never used it. But you’re right that gedit supported the workspace feature (but it has been removed).
Because workspaces are a compositor functionality: there’s nothing in the Wayland protocols that defines “a workspace”. Workspaces are part of the window management and stacking order, and that information is not available to clients, so they cannot manipulate it. It’s the same reason why there’s no programmatic way to put an application window stack on top of everything else, or positioning it using screen coordinates: those are user operations, and are not under the remit of an application developer. It would be far to easy to create a window that overlays on top of a password prompt and steals your input, otherwise, which is something that X11 allows you to do.
A shell specific protocol IMO is a non-starter, we shouldn’t have apps or toolkits start to hard code behavior specific to what the current shell design might be.