GNOME Bugzilla – Bug 496830
compiz workspace switcher integration patch
Last modified: 2020-11-06 20:24:41 UTC
We apparently had a patch in F7 to integrate the workspace switcher better with compiz and recently added it to F8 as an update. See: https://bugzilla.redhat.com/show_bug.cgi?id=375691 CCing Soeren, since I think he was the original author of the patch
Created attachment 99106 [details] [review] the aforementioned patch
I believe the hsize/vsize configuration options were something else I patched into the FC6 version of compiz, so at the time this panel patch couldn't really be submitted upstream.
Ah are those bits in upstream compiz now?
I don't think this is the way we'll go. Let's just move the gconf keys about the number of workspaces and the number of rows in a stable place that compiz can use too. I don't want to have to do this again for another WM, and then another one, etc.. If a WM wants to integrate with GNOME, just use the stable gconf keys. (note that the number of workspaces is already stable in some way since it lives in /apps/metacity, iirc)
(In reply to comment #3) > Ah are those bits in upstream compiz now? > yes upstream compiz seems to have them now. (we don't have any vsize/hsize related patches in the f7/8 rpms) (In reply to comment #4) > I don't think this is the way we'll go. Let's just move the gconf keys about > the number of workspaces and the number of rows in a stable place that compiz > can use too. I don't want to have to do this again for another WM, and then > another one, etc.. If a WM wants to integrate with GNOME, just use the stable > gconf keys. (note that the number of workspaces is already stable in some way > since it lives in /apps/metacity, iirc) > there is one problem with this compiz does support both viewports _and_ workspaces. So I am not sure how this should work.
(In reply to comment #5) > (In reply to comment #4) > > I don't think this is the way we'll go. Let's just move the gconf keys about > > the number of workspaces and the number of rows in a stable place that compiz > > can use too. I don't want to have to do this again for another WM, and then > > another one, etc.. If a WM wants to integrate with GNOME, just use the stable > > gconf keys. (note that the number of workspaces is already stable in some way > > since it lives in /apps/metacity, iirc) > > > > there is one problem with this compiz does support both viewports _and_ > workspaces. So I am not sure how this should work. I have never seen anybody using both at the same time. I don't think I ever saw anybody using compiz with workspaces. Anyway, that's up to compiz to internally decide if it wants to use viewport or virtual desktops. For the end user, it's still about workspaces. The gconf key would only tell you about the number of workspaces and the layout, and doesn't force the WM to use virtual desktops.
Created attachment 113453 [details] [review] new, simpler patch The attached adds the compiz support in a different way then the old one. It reuses the existing UI (so no glade file changes and new strings), is multiscreen aware (the old one had screen0 hardcoded) and uses the already existing compiz check. While at it I fixed it to detect compiz correctly (its wm-name is "compiz" not "Compiz"). Thoughts?
This has been used in Ubuntu for ages, ok to apply the patch?
It's not the right way to implement this. wm_get_workspace_count() is wrong, for example: - it won't work if compiz doesn't use its gconf plugin - it should be fixed in libwnck Same for num_workspaces_value_changed(): what happens if gconf doesn't use the gconf plugin?
*** Bug 628147 has been marked as a duplicate of this bug. ***
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.