Bug 96570 - old behaviour wanted: mouse wheel scrolls through app windows of only the app you're hovering over
Summary: old behaviour wanted: mouse wheel scrolls through app windows of only the app...
Status: RESOLVED FIXED
Alias: None
Product: kicker
Classification: Plasma
Component: taskbarapplet (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Aaron J. Seigo
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-08 11:15 UTC by Marcel Partap
Modified: 2008-12-15 21:38 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcel Partap 2005-01-08 11:15:33 UTC
Version:           3.3.91 (using KDE 3.3.91 (beta1), Gentoo)
Compiler:          gcc version 3.4.3 20041125 (Gentoo Linux 3.4.3-r1, ssp-3.4.3-0, pie-8.7.7)
OS:                Linux (i686) release 2.6.9-gentoo

back in the old days I moved the cursor over 'Konqueror [14]' and could scroll through the konqi windows; nowadays it scrolls through ALL windows which I don't see as an advantage or even feature. What do people think?
If people think this is still useful, that behaviour could be kept with modifier keys, but IMHO the old behaviour should return as default, it's cool.
Comment 1 Marcel Partap 2005-01-08 11:15:55 UTC
[ooops sorry wishlist]
Comment 2 Aaron J. Seigo 2005-01-08 11:53:29 UTC
the change was purposeful to bring it into line with the rest of the elements on kicker. i understand how changes in behaviour can be uncomfortable, however the goal is to achieve consistency.

there is no way to satisfy all people, so i've opted for consistency over favouring a unique behaviour.
Comment 3 Marcel Partap 2005-01-08 13:22:06 UTC
well consistency is nice and good but with what? and where is the feature in there? I mean you could simply click on the programs instead of swapping through them without even a hint which might be next?
I think the old behaviour makes more sense and is more userfriendly, to sacrifice that for 'consistency' doesn't seem the best idea to me. Anyways, you're the dev. I hope more people complain, though, if that is the only way to revert the change.
As said, why not make the old behaviour default and keep the new if you scroll with modifier CTRL f.e. ?
Comment 4 Marcel Partap 2005-02-12 11:07:54 UTC
ok it seems you wont be making up your mind about the default, but PLEASE implement an additional middle button action 'Cycle through windows of same application' (previous behaviour) in the KCM then. The new behaviour is totally useless as you just randomly go through the opened programs. You could aswell have a random button for that. If I could I would, but. Having it in 3.4 would be wonderful, and imho it should be default again, as it actually does something usefull. I wonder noone else has complained yet.
Comment 5 Aaron J. Seigo 2005-02-12 11:18:10 UTC
> The new behaviour is totally useless as you just randomly go through the
> opened programs

it's not random, it's in the order they are in the taskbar; in fact, the ONLY difference compared to the old behaviour is that it wraps around and starts from the beginning of the list. hyperbolizing doesn't change anything, especially not my decision. i understand that you and i don't agree on this matter and that's unfortunate. someone needs to make a decision and i feel i've made the best one possible with all things weighed. 

that includes things like "how many configuration options should the taskbar have?" and "will users even understand this as a configuration option?" and "how do people expect it to behave?" ... see, i had bug reports asking for the current behaviour! you want the other behaviour! i need to choose one or the other or make it configurable.

now, on the matter of re-opening bugs, do not re-open bugs that are not assigned to you. you may notice that this bug is assigned to me. this makes it my bug. every comment you add to this report gets CC'd to me. if your comment warrants re-opening the bug i will do so. you re-opening it simply serves to waste my time. =(
Comment 6 Marcel Partap 2005-02-13 01:51:38 UTC
ok, I DID hyperbolize here, but I like the old behaviour, I am sure I am not the only one and it is very easy to make it an option for those. Changing the default and _removing the option_ just because you consider it more 'in line' (heck, with what?) is quite debatable imho. I have exams to do right now, else I would just dig through the CVS and paste a patch. But I have abs. no experience fiddling with KDE code, and it really is a one liner, so again I kindly ask you to at least add an option for the old behaviour to scroll through button groups only. And really, what is worse, 8 instead of 7 options in that wheel action combobox or dissatisfying bold KDE supporters by enforcing own judgement?
I just fear because of all the fuss it won't go into 3.4, and it will not be default again even though I personally think it is more usefull especially for newbies. Even if it is indeed not random, I cannot quite see the advantage of the new behaviour. It is just confusing to me, and I don't think confusement should be default behaviour for software. Well, whatever.
[And trying to convince you of implementing this is wasting MY time, by the way, I didn't think it'd take that long. I just do it because I love KDE and think it should stay the best.]
Comment 7 Aaron J. Seigo 2005-02-14 01:41:10 UTC
> I cannot quite see the advantage of the new behaviour.

it's consistent with other kicker elements, and it allows you to scroll through your windows just using the scroll wheel.

> It is just confusing to me

you are not kicker's sole audience. you are one member of kicker's very large audience. you may not be a developer, but you could do random sample testing of the old versus new behaviour and share the results of such data collection upon which we could make a perfectly informed decision. basically, you'd sit 3-6 people in front of the old behaviour, 3-6 in front of the new behaviour, and get them both to scroll between windows using the wheel. record your observations of their actions, and get some feedback from them afterwards. preferably we'd have a mix of kde and non-kde users. and preferably you'd do another session a few hours/days later where you switch the two groups around and repeat. 

i don't think it's confusing to the general user base; you do. here's an opportunity for you to contribute to kde =)

> And really, what is worse, 8 instead of 7 options in that
> wheel action combobox or dissatisfying bold KDE supporters
> by enforcing own judgement

8 options is worse. =P and yes, sometimes decisions must be made. and not, you can't satisfy everyone, no matter decision is made. there are people who will find the 8 options, especially how this one would end up worded, to be difficult and confusing. there is no "zero footprint" decision available here.
Comment 8 Marcel Partap 2005-02-14 02:31:05 UTC
oohh COME ON please, why should I do that. With how many developers or users of KDE have you communicated about this issue, how can you be so sure about your decision? I simply do not have the time to do just a behaviour poll, nor do I consider it necessary. Why not just add this one more option? KDE is full of thousands of options, and people love it! Why should I put that much energy into fighting for a behaviour which was once default, costs nothing to readd and probably makse happy hundreds of people all over the globe? Honestly, this is not the KDE spirit I expected. It is not a truth, it is a thing of perspective. I myself have used the previous behaviour to hover over an group of app windows (be it konqi, mozilla...) and switch to the other windows quickly. Now that is lost, I either have to click twice, click-drag-n-release or wheel my way trough ALL windows. BUT I DO NOT WANT to see ALL windows, therefore I EXPLICITLY moved the cursor over a certain app group. I people want this all-window-slideshow - hey, that's fine with me. If the majority of users prefer this (which I don't think) and accordingly the default behaviour gets adjusted - sensible. But REMOVING previously default _more efficient_ behaviour without leaving the option to have it if you prefer it - that's doing things the Microsoft way. I for one do not like sacrificing efficiency or rationality for the masses, even if it much too often happens. All this arguing about such a simple thing is useless and demotivating. I'm not trying to push my ego here, whereas I am not so sure about your motivation keeping this wish unheard. I mean I'm accustomed to swim upstream, but sometimes it unnecassarily sux. For what. This is FOSS for heavens sake please just give me the freedom to choose the old behaviour, I have explained why I prefer it. If you absolutly need random sample testing backing for this, I have no recourses atm then pls do a poll on your blog or whereever.. And I couldn't even do it without installing an old version too, for which I do not have enough disk space left. Do I really have to beg for this whereas every whining gnome gets his will here...
and please, don't be ridiculous about 7 or 8 making a difference. And I gave examples of the wording:
Cycle through windows of same application
Cycle through windows of same kind (only)
Cycle through application group
I'm sick of putting any more energy into this stupid debate and choose to resignate if you wont move on this issue. All the time I have used this feature before, by typing the whole report I overcompensated the saved clicks/keystrokes a zillion times. Even if you consider it funny, you really really annoyed a big KDE fan to his limits. Bah. Peace out.
Comment 9 Jesus Cea 2005-11-20 23:04:59 UTC
When I upgrade from SUSE 9.2 (KDE 3.3) to SUSE 10.0 I found the new behaviour extrange. In fact I found this bug entry while filing a new bug about this issue.

At this moment I have 5 consoles , four konkeror windows, 15 Thunderbird windows and 31 Firefox open. I really really really miss the old behaviour. The current one is of no use to me. Just random window popups.

I would like a configuration option. Even undocumented, needing a file configuration edition by hand.

Any that I can do to improve the situation?.
Comment 10 Jesus Cea 2007-11-07 15:49:49 UTC
Two years and counting... I'm stuck in Suse 10.0 because this behaviour! :-(.

Voting +5 to resolve this issue.
Comment 11 Marcel Partap 2008-12-15 21:38:35 UTC
Wo0t. SVN finally behaves sanely: scroll through group if cursor over group, else scroll all ungrouped windows. Niiicccczzzzzzeeee ;p