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
On Sat, 2002-05-18 at 03:19, Havoc Pennington wrote:
> Luis Villa <email@example.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.
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.
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
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
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
- 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:
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,
if (n_items == 3)
int cols, rows;
screen->vertical_workspaces = FALSE;
screen->vertical_workspaces = TRUE;
meta_warning ("Someone set a weird orientation in
rows = list;
cols = list;
Maybe the pager is broken? Let's look at the libwnck code...
_wnck_set_desktop_layout (Screen *xscreen,
data = _NET_WM_ORIENTATION_HORZ;
data = rows;
data = columns;
XA_CARDINAL, 32, PropModeReplace,
(guchar *)&data, 3);
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
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:
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