PaperWM

PaperWM copied to clipboard

Problem

I often need to add different workspaces to my workflow. at some point, some of them I don't need anymore but I don't have the possibility to remove them leaving them there as zombies (sucking up useful memory for other operations)

Request

is it possible to implement a function that allows me to remove one or more workspaces that I no longer need?

@hedning I would like to work on this. I am facing the same problem and would like to see a fix for this Video demo of the problem

https://user-images.githubusercontent.com/57226514/104541573-dd46bf00-5647-11eb-82e6-f790ebe6e413.mp4

I have just stumbled into this extension just now and am already liking it. Thank you for your work

why is it overriding gnome's default functionality of dynamic workspaces?

is it possible to implement a function that allows me to remove one or more workspaces that I no longer need?

Yes, there's already some utility functions that removes workspace preferences here: https://github.com/paperwm/PaperWM/blob/f6e9ab4d901e00ade4acb1caef28e33b31540c59/settings.js#L162-L177

I would like to work on this

I'd happy to review a PR for this, can't promise doing it super swiftly, but this is something we'd really like to support.

The above utility functions are a good place to start, as they make it fairly OK to delete specific workspace preferences. We probably want a delete button here:

why is it overriding gnome's default functionality of dynamic workspaces?

Gnome doesn't support transient workspaces (ie. no name/workspaces specific config), and they've built dynamic workspaces with that in mind.

We opted for a hybrid model between static and dynamic workspaces, since users might want a fixed set of workspaces being visible all the time. The number of «static» workspaces is configurable, but it's not documented or exposed all that well. This should probably be part of the preference gui. In the mean time you can tune it like this:

dconf write /org/gnome/desktop/wm/preferences/num-workspaces n

An input field to configure the number of static workspaces here would be nice:

Hi @nsrCodes. Great that you want to contribute :) I'll answer the email here supplementing @hedning's answer:

Development environment

Nothing is needed besides a text editor. The paperwm installation symlinks the code to where gnome looks for extensions, so changes will take effect the next time gnome-shell is restarted (Alt+F2, then "r" is the default shortcut I think).

We have created a gnome-shell-mode for emacc which makes development much more enjoyable (but naturally require more setup).

JS docs for most of the gnome libraries: https://gjs-docs.gnome.org/ (but the gnome-shell libraries are notably missing)

Workspace removal

The helper in settings.js only modifies the stored settings. I'm not sure what happens if you try do delete the settings of an in-use workspace.

Some rough hints:

Space is paperwm's representation of a workspace. space.workspace holds the gnome-shell workspace object. global.workspace_manager.remove_workspace removes the actual gnome-shell workspace Spaces.workspacesChanged might be helpful to study reorderWorkspace@examples/keybindings.js might be helpful to study https://github.com/paperwm/PaperWM/#development--user-configuration

I'd start with implementing a function inside the extension which delete a workspace. If you choose to not setup emacs, I'd test this function using a custom keybinding (see examples/keybindings). If you're lucky it's enough to delete the gnome-shell workspace. I think that should trigger Spaces.workspacesChanged which will clean up the corresponding Space.

What should happen if the workspace isn't empty?

To make removal from the GUI settings work you could try to connect to the list of of workspace uuids in the extension: workspaceList.connect('list', handler). Iterate through the paperwm workspace (aka "spaces") and look for the space without a maching space.uuid in the workspaceList settings in the handler.

Some things to be aware of when working on the settings GUI (prefs.js)

The settings GUI is run as a separate process. It can not use gnome-shell related code, which effectively limits usage of paperwm modules to settings.js.

settings.js is designed to be importable from both prefs.js and the extension. No top-level imports from paperwm modules or gnome-shell are allowed in settings.js

You don't have to restart gnome-shell to test changes in prefs.js [1].

The extension can listen for changes to the settings. (see the settings.connect in [email protected]. init only runs in the extension)

Settings are stored using GLlib gsettings system. See schema.xml for the paperwm settings schema.

Might be helpful to look at the output of dconf dump /org/gnome/shell/extensions/paperwm/

[1] Unless the code (in the extension) listening to setting changes also have been changed.