After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 130308 - added workspace switching by mouse wheeling over applet
added workspace switching by mouse wheeling over applet
Product: gnome-panel
Classification: Other
Component: workspace switcher
Other Linux
: High enhancement
: ---
Assigned To: Panel Maintainers
Panel Maintainers
: 119023 152471 167921 (view as bug list)
Depends on:
Reported: 2003-12-31 20:48 UTC by Mikael Brockman
Modified: 2015-03-24 13:00 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement

the patch! (2.12 KB, patch)
2003-12-31 20:49 UTC, Mikael Brockman
none Details | Review
modified version of patch to correct scrolling direction (2.12 KB, patch)
2004-01-02 12:09 UTC, Sam Stephenson
none Details | Review
patch with consistent coding style (2.40 KB, patch)
2004-01-14 14:04 UTC, Mikael Brockman
none Details | Review
patch with cleverer behavior (2.89 KB, patch)
2004-01-14 19:27 UTC, Mikael Brockman
none Details | Review
cleaned up patch (2.18 KB, patch)
2004-06-02 13:13 UTC, Mark McLoughlin
committed Details | Review

Description Mikael Brockman 2003-12-31 20:48:47 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. :-)
Comment 1 Mikael Brockman 2003-12-31 20:49:19 UTC
Created attachment 22803 [details] [review]
the patch!
Comment 2 Sam Stephenson 2003-12-31 21:39:04 UTC
I really like this feature; it's consistent with the mouse wheel
support in mixer-applet. Thanks!
Comment 3 Keith Lea 2003-12-31 23:10:04 UTC
This is definitely a good idea, I'm surprised no one thought of it sooner.
Comment 4 Sam Stephenson 2004-01-02 12:08:44 UTC
It seems more natural to have GDK_SCROLL_DOWN paired with
progression of workspaces in the grid moves from left to right and top
to bottom.
Comment 5 Sam Stephenson 2004-01-02 12:09:58 UTC
Created attachment 22837 [details] [review]
modified version of patch to correct scrolling direction
Comment 6 Mikael Brockman 2004-01-02 12:48:31 UTC
I agree completely, and now I feel silly for using the opposite
direction. :-)
Comment 7 Vincent Untz 2004-01-06 14:55:29 UTC
Patch looks good.
Could you update it with the coding style like the one already there?

Comment 8 Mikael Brockman 2004-01-14 14:04:35 UTC
Created attachment 23351 [details] [review]
patch with consistent coding style
Comment 9 Mikael Brockman 2004-01-14 14:05:18 UTC
Sorry for taking so long -- I thought I had already submitted this
weeks ago. :-)
Comment 10 Mark McLoughlin 2004-01-14 14:10:32 UTC
Hmm, this takes no account of setups where you have more than one row.
Comment 11 Mikael Brockman 2004-01-14 14:18:36 UTC
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?
Comment 12 Mark McLoughlin 2004-01-14 14:32:51 UTC
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.
Comment 13 Mikael Brockman 2004-01-14 14:50:55 UTC
Okay.  I promise to change it when we all have two-dimensional
scrolling balls, though. :-)
Comment 14 Mark McLoughlin 2004-01-14 14:59:20 UTC
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.
Comment 15 Mikael Brockman 2004-01-14 19:26:25 UTC
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.
Comment 16 Mikael Brockman 2004-01-14 19:27:39 UTC
Created attachment 23359 [details] [review]
patch with cleverer behavior
Comment 17 Mark McLoughlin 2004-02-13 17:49:00 UTC
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:

+static gboolean
+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,
         int   b,
         void *c)
   char  x;
   int   y;
   void *z;

   + Don't initialize local variables in their declarations - 
     except for trivial initializations like foo = NULL;
Comment 18 Vincent Untz 2004-02-25 10:13:36 UTC
*** Bug 119023 has been marked as a duplicate of this bug. ***
Comment 19 Mark McLoughlin 2004-06-02 13:13:04 UTC
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.
Comment 20 Mark McLoughlin 2004-06-02 13:13:47 UTC
Created attachment 28270 [details] [review]
cleaned up patch
Comment 21 Matthew Miller 2004-07-01 05:09:00 UTC
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.
Comment 22 Vincent Noel 2004-08-06 18:46:57 UTC
ping : could this patch be applied ? This feature could be really useful.
Comment 23 Havoc Pennington 2004-08-08 04:43:48 UTC
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.
Comment 24 Justin Wake 2004-08-08 12:26:44 UTC
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?
Comment 25 Mikael Brockman 2004-08-08 12:31:23 UTC
Your objections also apply to the volume applet, Havoc, but lots of users seem
to know of and appreciate its wheeling capacity.
Comment 26 Sebastian Kapfer 2004-08-08 20:58:28 UTC
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.
Comment 27 Havoc Pennington 2004-08-09 03:21:38 UTC
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.
Comment 28 Elijah Newren 2004-08-09 03:56:21 UTC
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)
Comment 29 Matthew Miller 2004-08-09 18:48:24 UTC
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.
Comment 30 Victor Herrera 2004-08-30 20:57:46 UTC
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
using ctrl-alt-arrow.

BTW, will this patch work on gnome-panel 2.6.2?
Comment 31 Vincent Untz 2004-09-13 08:29:11 UTC
*** Bug 152471 has been marked as a duplicate of this bug. ***
Comment 32 Jonty Pearson 2004-12-17 16:53:20 UTC
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?
Comment 33 Karel Demeyer 2004-12-26 20:27:34 UTC
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.
Comment 34 Vincent Untz 2005-01-01 11:59:14 UTC
I tested Mark's patch and it worked. So it's in HEAD now.
Comment 35 Vincent Untz 2005-02-20 14:43:59 UTC
*** Bug 167921 has been marked as a duplicate of this bug. ***
Comment 36 Daniel Link 2005-11-05 15:05:59 UTC
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="">bug 320751</a>. It's
about  the 2-row scrolling order (1-3-2-4). Would it really be 
Comment 37 Daniel Link 2005-11-05 15:06:47 UTC
Great, bugs are linked automatically. Sorry, didn't know.