GNOME Bugzilla – Bug 82337
Viewport navigation bug
Last modified: 2009-08-16 15:13:28 UTC
Adding this bug to get it tracked in bugzilla. Not sure what it is about actually :) On Sat, 2002-05-18 at 03:19, Havoc Pennington wrote: > > Luis Villa <louie@ximian.com> writes: > > And I see that we never did file the directionality issue for viewport > > navigation, at least not that I've marked to 2.0.0. If someone files > > that, please add the keyword. Thanks. > > I already fixed it except that I'm having to pull teeth to get it in > the WM spec, and it needs implementing in Sawfish. > > Havoc
John: to clarify this bug a little, in case you haven't been reading the lists: the biggest remaining issue with the dropping of viewports (as far as list feedback goes) appears to be the lack of ability to navigate workspaces in a 2D fashion- i.e., to specify up/down movement as well as right/left. We're really hoping you can add this before the 2.0.0 release :) Thanks...
Related to bug 75613. I don't have time for adding sawfish features at the moment. It should be easy enough to write a new lisp module that adds four new commands to switch workspace using logical directions.
Obviously this is not going to happen for 2.0.0. It will require lots of testing, especially to make sure deskguide/libwnck is happy with it. Looking at bug 75613 I see HP is trying to get discussions going to get this done properly as a wm standard. Luis: can we punt this to 2.0.x? It is a great feature for 'expert' users (I personally love it), but not a core feature.
The proposed standard is currently implemented by libwnck, also. If you know lisp and how to write a sawfish module, then this should be a matter of maybe 1 hour of hacking, and be pretty safe in terms of not introducing new bugs.
Well, it is 2.0.0 because it was 'promised' to desktop-devel during the mega-thread on this subject. For all intents and purposes it is punted anyway since John won't fix it and no one else can/will. We definitely won't be holding up the release for it, so in that sense it really isn't 2.0.0 anyway.
Punting, officially.
It should be noted that unless you can specify a direction (vertical or horizontal) where you do not want to flip edges, it will be very hard to reach panels that lie on the edge of the screen. Because of their usefull different behaviours, I made a 6x1x2 area (masking as if it was a 6x2 desktop) so I could have panels on top and bottom, and use change viewport when the mouse reached the horizontal edges, but not vertically (which would create a hell reaching the panels). If the general idea is of not having two different ideas but trying to merge them, then you need to handle such differences. A 2D layout is nice and commonly used, but it doesn't harm to be able to chose which direction will flip edges in a given set of workspaces, so you can have usability on the panels.
Created attachment 9416 [details] A simple way to get 2D-navigation with sawfish workspaces
Sigh, stupid bugzilla... Anyhow, the .jl-file above is not very much tested, and for some reason the docstrings doesn't show up in sawfish-ui. But it works for me (tm). But I do prefer viewports... they are much nicer...
well a patch. dang. Cool :) [Adding keyword, not just spam :)
The patch is kind of simplistic (e.g. moves past end of row onto start of next row), and doesn't hook up to the wm-spec geometry (is there such a thing? I haven't been paying attention) it's not a million miles from what is needed though
To be complete, there should also probably be equivalent move-window-to-workspace-<up,down,left,right> functions.
Peter: adding you to the cc: list so that you see John's last comments.
Created attachment 9572 [details] Re-vamped grid-based workspace switching functions
I took peter's file and: - Made it work for workspace switcher applets on vertical (as well as horizontal) panels - Kept the workspace from wrapping from the right side to the left - Refactored; beginnings of a "workspace-grid" abstraction It now has two customize variables (number of workspace switcher rows, workspace-switcher orientation) that need to be replaced with that wm-spec thing you guys are talking about. (newbie question: What does triaged mean?)
triaged, in the current GNOME case, basically means 'luis has looked at it and made sure all possible fields are set as well as possible.'
Created attachment 9578 [details] [review] A version that supports send-window-to-workspace-<down,up,left,right>
Created attachment 9601 [details] This version reads pager values dynamically
I started reading values from (get-x-property 'root '_NET_DESKTOP_LAYOUT), instead of using customize variables. This takes care of the last of John's complaints. However, the value that I get from that expression to be inconsistent with spec described in Havoc's proposed patch (from the wm-spec list). The x property A) doesn't reflect the horizontal/vertical orientation of my workspace-switcher, but rather always reports "horizontal" and B) has the x and y values switched. For instance, if I have a pager on a horizontal panel like: 1 2 3 I get the array [0 1 0] instead of [0 0 1]... And if I have the vertical panel: 1 2 3 it returns the array [0 1 0], which I think should be [1 0 1]. My interpretation of the wm-spec is that this tuple is [orientation width height]. Am I reading the right correctly? Is the spec implemented? I'm using the gnome2 release packages from debian experimental.
Sorry, I meant [1 1 0] where I said [1 0 1]. Wow, there were a lot of typos in that post.
Hmm, here is the metacity code, which (I think) works, or it appears to work for me anyhow: if (meta_prop_get_cardinal_list (screen->display, screen->xroot, screen->display->atom_net_desktop_layout, &list, &n_items)) { if (n_items == 3) { int cols, rows; switch (list[0]) { case _NET_WM_ORIENTATION_HORZ: screen->vertical_workspaces = FALSE; break; case _NET_WM_ORIENTATION_VERT: screen->vertical_workspaces = TRUE; break; default: meta_warning ("Someone set a weird orientation in _NET_DESKTOP_LAYOUT\n"); break; } rows = list[1]; cols = list[2]; Maybe the pager is broken? Let's look at the libwnck code... void _wnck_set_desktop_layout (Screen *xscreen, int rows, int columns) { gulong data[3]; data[0] = _NET_WM_ORIENTATION_HORZ; data[1] = rows; data[2] = columns; _wnck_error_trap_push (); XChangeProperty (gdk_display, RootWindowOfScreen (xscreen), _wnck_atom_get ("_NET_DESKTOP_LAYOUT"), XA_CARDINAL, 32, PropModeReplace, (guchar *)&data, 3); _wnck_error_trap_pop (); } That looks kind of suspicious, it always sets horizontal. And then if you look at pager.c it has a variable named n_rows always passed to this function first, that can be either rows or columns depending on orientation. So, short answer, looks like libwnck is hosed.
So should I be reassigning to libwnck then, havoc?
no I think this would be a new bug against libwnck, this bug was for the sawfish bit.
I created a new bug for the libwnck problem (bug 89373) and made this one depend on it.
Created attachment 10141 [details] Final version, ready for inclusion
I just attached another version of the patch. I think it's finished. John, can this be merged into sawfish?
I'm still missing interactivly moving windows up/down/left/right, they just move to the next/previous workspace. But I have no idea if it's possible doing this in rep only...
Are you talking about edge-flipping? If so, you want bug 75613.
Michael: thanks, that patch looks excellent. I made a few cosmetic changes (replaced defun by define and define-command, removed uses of defsubst, changed the swap macro) and will attach the result Perhaps you could look it over and test it? Then I'll commit it.
Created attachment 10241 [details] modified final version
I am on vacation until the 12th or 13th, and won't be able to check it out until then. If gnome is going to have a release before then, could you (or somebody else) test it instead? The changes you describe sound fine. I haven't quite figured out what accent of scheme/emacs lisp one is supposed to use yet. :)
John: Tested out your modifications. They look good, and work fine. One issue: you renamed the "view-workspace-<direction>" commands to "workspace-<direction>", but didn't modify the export clause: (export view-workspace-up view-workspace-down view-workspace-right view-workspace-left Should the "view-" be removed from these? Strangely, I find that the "workspace-<direction>" commands are available to the user from the sawfish configurator despite this typo... shouldn't they be hidden behind the define-structure? Also, now that bug 89373 has been fixed, this section can be removed: ;; Swap layout again because of libwnck bug (swap cols rows) ... as well as all other comments mentioning gnome2 workarounds.
doh, well spotted. I'll fix the export clause. Yes, it's normal that the commands still work, the export controls whether the functions are exported, but the calls to define-command "publish" command names pointing to the internal functions I removed that one "swap" line. I'll commit it later, then look at the edge-flipping changes. Thanks again.
w00t. :) Obviously, this won't be fixed in time for 2.0.1, so I'm removing that keyword, but if we could get a release whenever it is fixed, that would be cool. :)
John, we gotta re-insert the "swap" line temporarily. The patch for bug 89373 wasn't a complete fix. I doubt it will take too long for someone to fix it completely, though, and let us remove the swap again... so you might want to leave that operation in a mental write-back buffer for a little bit...
OK, I added that line back and committed the new file