Reverse scroll direction in Icon TaskList applet

I was wondering if anyone knows of a hack/trick/workaround/config file to reverse click/scroll behavior for icons (with only one instance running) in the icon task list?

Currently, if an active app has one instance open, to display the app window if minimized or bring it back to focus (if not minimized) you have to click on the icon and to minimize you can either scroll or click.
I would like to be able to scroll instead of (or in parallel to) clicking to display/focus the app window, as I configured in dash-to-dock. Since Gnome is still my daily driver, it is disturbing me that I can’t scroll on the icon to show the window.

And even weirder, scrolling on the icon works to display/focus windows with several instances of an app running, additionally to simply switch between them.

With a bit more research, I found out that you need to scroll up to display/focus, and down to minimize. To be more specific regarding my request, I would like to scroll down in both cases (diaplay/focus and minimize) as it is a more natural movement.

I think it’s pretty natural to scroll up to bring up or raise a window,

and scroll down to minimize.

Am probably a wrong example as Gnome is for me the most counter-intuitive thing I’ve ever used.

You may have a look into dconf editor to see if there’s any key to set the way you like, somewhere in org solus ( use the search tool ).

It feels so natural for me to scroll up that I didn’t even think about trying… :-p

I had to look it up and found on a similar request on Solus that they changed to an upward scroll at some point in the past. That’s how I got it.
I agree on theory the logic is indeed more obvious. But you know what they say, no one’s ever been to Theory… Hence, the practical logic often supersedes the theoretical one.

And on the practical front, that gesture might be less annoying on the scroll wheel but on a touchpad the two-finger gesture is easier going down. At least for me.

I agree vanilla Gnome is not the most intuitive DE. That’s the very reason why I’m giving a shot at budgie (and I am mostly positively surprised). But dash-to-dock is an absolute gem of an extension and make up for a lot of Gnome shortcomings.

I would really like to find a way to scroll down also for displaying/focusing. It already works with grouped instances so it’s at arm’s reach.

I looked into dconf to no avail, I found the dash-to-dock “cycle windows” action on scroll, but nothing for budgie.

Ah yes, the touchpad.

Touchpad are evil, lol.

So today do you agre we have :
⋅ for a single instance window→ scroll up brings up / scroll down minimizes
⋅ for many instances → scroll up OR down brings up first OR last window / then scroll up OR down cycles through from first OR last window
?

With mouse, these are the most reasonable gestures, to my opinion.

I can’t say about touchpad - I don’t use them especially because they don’t have wheel, I did not even know there were gestures to emulate it, lol !

I think only upstream Solus may modify this.

Anyone can have a go proposing a patch … !

Anyone skilled enough to code - but yeah that was the underlying idea, but I don’t dare express it being myself unable to propose any patch.

Then if any patch proposed, that should be something « configurable » not « hardcoded ».

Yes, that’s how it works today.

I’m not sure it “should” be something configurable, but if it “could” it would be really nice. That and pixel saver applet not offering the possibility to grab a maximized window by the top panel to shrink it back are my main blockers right now.

I prefer the soft double finger sliding on a touchpad to the strenuous index finger scroll on a scroll wheel. Haven’t tried budgie with a mouse on my desktop (and primary leisurestation) yet.

Unfortunately, I’m not a developer, I can tweak config files and already defined css but coding is a no go.

Yep that would be nice but window control buttons are not far ?
And keyboard shortcut [ super ] + [ ↓ ] does that too.

I’m not the biggest fan of keyboard shortcuts. I’m a power user with lazy average Joe mouse reflexes. Most of the time, the hand not on the mouse/touchpad is resting away from the keyboard.

The top panel has an upper screen border (in my setup), and there’s very little effort to throw your cursor up in a big gesture without any kind of precision (it’ll be blocked) and grab the window from there. It’s always faster than to calculate your gesture so that your cursor is precisely in that narrow title bar, or to reach precisely for these tiny little control buttons and RRRRrrrzzzzzzzz.
Don’t know if my explanation is clear enough. and of course, we’re talking about tenth of seconds, but on a constant basis it’s a game changer. Unite extension in Gnome does that very well.

Oh ? It’s not broken in 20.04 ?

I was not saying it’s perfect for all, just offering some workaround, given that keyboard shortcuts with [ super ] + [ arrows ] are easy to remember.

Unite is not broken in 20.04.

Thanks for taking the time to offer me some alternative. Although Super + arrow doesn’t seem to work.

I’ve just discovered an acceptable workaround though. Double clicking on the window title in the top panel unmaximizes the window. I will use this and hope for a better solution in the future.

I guess I’m still in the process of finding similar behaviors I’m used to, but I will have to re-learn. It’s a bit confusing though between Windows (work), Gnome and Budgie to remember to adapt your habits.

Should… Which Settings - Keyboard shortcuts do not work (or do) in budgie?