There is any way (or if it's possible) to append or insert a workspaces in GObject Introspection in Python?

[Charles]

Hi, everyone.

I know in the gnome-shell extension we can append workspaces by calling global.workspace_manager.append_new_workspace.

I have searched the source code of gnome-shell. I found that the variable global is from Shell.Global.get(). And the Shell is imported like this:
const { Clutter, Gio, GLib, GObject, Meta, Shell, St } = imports.gi;.
The above code is in gnome-shell/js/ui/environment.js.
As you can see the Shell is from the js version of GI.

I tried to write this kind of code in Python like this:
from gi.repository import Shell.
But it seems that there is no Shell in the python version of GI at all, is this true?

Recently I’ve learned Wnck which surprised me at first. Now I know that it does not provide APIs to append/insert workspaces.

So is it impossible to append or insert workspaces in other language bindings like Python except js?

I’m writing some sort of application in which it need to append workspaces in some cases.

I know I can add this feature in a gnome shell extension, add schema and key, then access them via GIO.Settings.

I’m still looking forward to implementing this feature just in Python.

Thanks.

[fmuellner (Florian Müllner)]

@Charles

I tried to write this kind of code in Python like this:
from gi.repository import Shell .
But it seems that there is no Shell in the python version of GI at all, is this true?

Shell, St and Meta aren’t installed in the default path, because they are not meant for applications. In fact, I don’t expect much of its API to work at all when used outside the gnome-shell process (independent from the language used - C, JS or python).

There are ways to do workspace management from outside gnome-shell (forcing static workspaces and changing the num-workspaces setting, or talking D-Bus), but it is generally something that is considered under user control that applications aren’t meant to touch.

Unless you are writing something like a dock or taskbar (that will be limited to the legacy X11 session), I strongly recommend to reconsider whatever it is that you are trying to do

[Charles]

Thanks for your reply.

forcing static workspaces and changing the num-workspaces setting

This is a good idea. But I think it depends on some conditions.
1.Users prefer using Dynamic Workspaces
Then users may will be stuck with the Fixed Workspaces, they cannot add or move windows into new workspace due to any reason that they believe. I think it’s not a good idea to change this option to Fixed Workspaces for user.

2.Users prefer using Fixed Workspaces
Then perhaps it will be OK for users.

I know a gnome-shell extension named ‘Minimum Workspaces’ located at ‘Minimum Workspaces - GNOME Shell Extensions’ which works well on Fedora 32 and has a fixed numbers of workspaces but allow more workspaces to be added. Can you add this feature into gnome itself as an extra option along with the Dynamic Workspace and Fixed Workspaces? But I don’t expect this will happen…

or talking D-Bus

I don’t know D-Bus but will learn it later to see what it can do…

Thank you again.

[fmuellner (Florian Müllner)]

@Charles

I think it’s not a good idea to change this option to Fixed Workspaces for user.

I agree. In fact, I don’t think it is a good idea to change any workspace-related option for the user — including the number of workspaces — unless it is in response to a user action that is clearly marked as such (like a click on a “Add workspace” button for example).

@Charles

Can you add this feature into gnome itself as an extra option along with the Dynamic Workspace and Fixed Workspaces?

What exactly is the use case for that? Off-hand I can’t think of one that would be strong enough to justify a build-in option.

[Charles]

@fmuellner

or talking D-Bus

Hi,
Can you please provide some examples or demos to explain how to do it with D-Bus in Python?

[fmuellner (Florian Müllner)]

No, I can’t.I don’t know any application that messes around with workspaces.