GNOME Bugzilla – Bug 130308
added workspace switching by mouse wheeling over applet
Last modified: 2015-03-24 13:00:45 UTC
I think it's considerably easier to wheel around on the applet bar than
clicking around on it, and it's not a very intrusive feature. I'm not sure
if my patch does the right thing (esp. regarding adding and subtracting WS
numbers), but it works perfectly for me. :-)
Created attachment 22803 [details] [review]
I really like this feature; it's consistent with the mouse wheel
support in mixer-applet. Thanks!
This is definitely a good idea, I'm surprised no one thought of it sooner.
It seems more natural to have GDK_SCROLL_DOWN paired with
GDK_SCROLL_RIGHT and GTK_SCROLL_UP with GDK_SCROLL_LEFT, since the
progression of workspaces in the grid moves from left to right and top
Created attachment 22837 [details] [review]
modified version of patch to correct scrolling direction
I agree completely, and now I feel silly for using the opposite
Patch looks good.
Could you update it with the coding style like the one already there?
Created attachment 23351 [details] [review]
patch with consistent coding style
Sorry for taking so long -- I thought I had already submitted this
weeks ago. :-)
Hmm, this takes no account of setups where you have more than one row.
That's true -- it just moves left to right and wraps to the next line,
akin to how moving the text cursor with the left<->right arrow keys
works. I'm actually using it with two rows, and I like this behavior.
How do you think it should work?
Basically, I would have expected it to work the same as Ctrl-Alt-<arrow>
UP/DOWN would go up and down ...
I'm guessing that typical scroll buttons just generate UP/DOWN events
which is pretty useless (if we don't wrap) to people using a single
row, so we probably want to do the wrapping thing.
Okay. I promise to change it when we all have two-dimensional
scrolling balls, though. :-)
Okay, look. You can get UP/DOWN/LEFT/RIGHT scrolling events. If I was
implementing this without knowing the details of how these events are
generated I'd implement it so that you move in the direction the
scroll event suggests until you hit the edge, and then wrap.
Your implementation does exactly this in the case where you only have
a single row.
Oh, now I get it! Yes, that's a much more elegant solution, and
should be great for people with two-dimensional scroll wheels, too.
Created attachment 23359 [details] [review]
patch with cleverer behavior
Mikael: the patch looks pretty good now, but we're going to have to
punt until 2.8 since we've missed the feature freeze for 2.6.
I only have trivial coding style comments remaining:
+applet_scroll (PanelApplet *applet,
+ GdkEventScroll *event,
+ PagerData *pager)
+ WnckScreen *screen = applet_get_screen (GTK_WIDGET (applet));
+ WnckWorkspace *active_workspace =
+ wnck_screen_get_active_workspace (screen);
+ int workspace_index = wnck_workspace_get_number (active_w...
+ int workspace_count = wnck_screen_get_workspace_count (scr...
+ int n_columns = workspace_count / pager->n_rows;
+ int n_rows = pager->n_rows;
+ int new_index = workspace_index;
+ WnckWorkspace *new_workspace;
+ Align every argument name and variable name like this:
foo_bar (char a,
+ Don't initialize local variables in their declarations -
except for trivial initializations like foo = NULL;
*** Bug 119023 has been marked as a duplicate of this bug. ***
Okay, here's a cleaned up version of the patch. I'd commit it but I'm not
convinced this is actually going to work with more than one row. Need a scroll
mouse to test it.
Created attachment 28270 [details] [review]
cleaned up patch
This works pretty nicely for me.
A request -- when the last or first workspace is reached, it should wrap. The
mouse wheel spins freely -- it's confusing to suddenly be 'stuck'.
I find it most convenient to use only two workspaces, and I don't really have a
concept of order -- it's either the visible one, or not. Without wrapping, I
have to think about which one I'm on; with, I can just flip.
ping : could this patch be applied ? This feature could be really useful.
This is potentially really confusing, I regularly just fiddle with the scroll
wheel... what if it happened to be on the applet?
Nobody is going to find this feature on purpose... it's a completely hidden
thing and so in its intended role might not get used much, only by people who
happen to read about it online or something.
This seems like quite logical behaviour to me - when a user scrolls the mouse
wheel, it seems entirely reasonable to expect the object the cursor is on to be
adjusted up or down (or left or right, depending). I personally don't see
scrolling the mousewheel as being much different to clicking, in the context of
activating UI elements - if a user was idly clicking away at the mouse and
something happened, the reaction would probably be different.
In any case, after the first time that it happened, I suspect that the average
user would be able to figure out the interaction, and it's not exactly a
critical, irreversible operation even if it is accidentally activated.
I don't see any reason why this couldn't at least be added as a
gconf-configurable option. Opinions?
Your objections also apply to the volume applet, Havoc, but lots of users seem
to know of and appreciate its wheeling capacity.
I agree, this feature is probably not something that users will discover on
their own (at least it never got onto my mind to use the scroll wheel with the
pager), but the logical connection is there and quite obvious. It's not much
different from accidentially clicking on the pager, which can be confusing for
users not familar with the concept of workspaces/desktops. And still, GNOME has
a pager applet in its default config if I remember right.
My objections definitely don't apply to the volume applet, that applet is
clearly a slider/scrollbar type of thing, and the wheel moves said
slider/scrollbar. My objections might apply if when you scrollwheel on the icon
the slider does not appear; it needs to appear for feedback.
The workspace switcher doesn't look slideable, or scrollable. I guess thinking
about it, the feedback in the switcher itself is probably decent - you see the
highlight move as you adjust the scroll wheel. I was thinking you'd just see
windows come and go.
Seems a heck of a lot easier to me to click on the workspace you want directly
_anyhow_... but whatever.
See also bug 107702 which suggests an alternate way to accelerate workspace
switching (but which seems even more geared towards a single row of workspaces)
Havoc -- if you have to click directly on the specific workspace you want, you
have to engage fine motor skills to hit the exact right little box -- and you
have to actually look and select that box correctly as well. With the scroll
wheel, I just move to the far bottom right corner (where I have the applet) and
flip the wheel -- the same easy action no matter where I am and where I want to go.
I find multiple workspaces so much more useful when it's trivial to switch
between them. Having carefully defined distinct areas with a relatively high
"switch" barrier can be useful for some things -- but being able to switch
*without thinking* enables a more powerful behavior that integrates better with
actual day-to-day work.
Gentlemen, I just stumbled in here after googling for "scrollwheel desktop pager
gnome". I just switched from KDE to Gnome and this is the only thing that I
sorely miss. I used to set the pager on the bottom right hand side of the screen
and when I needed to switch desktops, I just throw the mouse pointer hard right
and bottom and scroll the wheel until I come across the needed desktop. Much
faster and practical than having to find the right little square to click on or
BTW, will this patch work on gnome-panel 2.6.2?
*** Bug 152471 has been marked as a duplicate of this bug. ***
Hello all, I also switched from kde to gnome and this is one feature I would
very much like to see in gnome-panel. Is this patch going to be used in the
distribution in future?
This is very consistent to the volume-applet and is really gnomish. It's also
consistent to the zoom-buttons like in nautilusbrowser and such. Please add it :D.
I tested Mark's patch and it worked. So it's in HEAD now.
*** Bug 167921 has been marked as a duplicate of this bug. ***
I can't quite follow the discussion about scroll wheel directions so it may be a
good idea for some of you guys having a look at <a
href="http://bugzilla.gnome.org/show_bug.cgi?id=130308">bug 320751</a>. It's
about the 2-row scrolling order (1-3-2-4). Would it really be
Great, bugs are linked automatically. Sorry, didn't know.