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] the patch!
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 to bottom.
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 direction. :-)
Patch looks good. Could you update it with the coding style like the one already there? Thanks
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: +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;
*** 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 using ctrl-alt-arrow. 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.