0

I am working on an extension for moving workspace, https://github.com/raonetwo/MaximizeToWorkspace.

For the windows that start maximized, the workspace switching is happening as expected. The new application appears to be in focus, mouse left and the right click (and keyboard too) is working as expected. The window shows up in activities overview and workspaces as well as application preview when hovering over an icon. But it is not visible/drawn in the workspace/display it is present on. If I minimize and unminimize the window (as seen from video), it starts to draw window correctly. What can I do to fix this?

Code can be found at https://github.com/raonetwo/MaximizeToWorkspace/tree/72d7f82d8930de1484fd2afa3caf9f20b245a1e2

0

global.run_at_leisure.bind is not the solution, because on fast machines it will be called too early.

If the problem is switching the active workspace: Don't switch.
On the "map" signal use workspacemanager.reorder_workspace(workspace,new_index) to place the active workspace on the right index and move the windows around.
reorder_workspace doesn't call workspace.activate().

| improve this answer | |
  • This is not what I want to do. I have since switched to using window-created signal as 'map' wasn't working out for me and extension would cause shell to crash. I was suggested to use Glib.idle_add github.com/raonetwo/MaximizeToWorkspace/pull/3 but it didn't work out like earlier no window got drawn. I will continue to use run_at_leisure as in my testing, it has consistently ran as expected and runs the callback function after rendering the window. You can check out the extension from extensions.gnome.org/extension/2857/… – Andrew Apr 12 at 14:21
0

I have fixed the issue. I needed to add lazy moving of window to the new workspace until all the other processing is complete. This is achieved through global.run_at_leisure.bind . The working code ca be found in the GitHub repository.

I jumped into this code first copying through examples, perhaps reading documentation would have gone better for me. Overall there is no issue and the extension is working as expected.

I have since modified the extension code to use 'window-created' signal on global.display instead of 'map' signal on global.window-manager as it did not work out and would cause gnome-shell to crash with signal 11 eventually due to some reference to destroyed object. I have also added minimal multi-monitor support and provided a fix for shell crashing due to drag and drop emitting the window-created signal but object getting destroyed.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.