Bug 177736 - When I set the taskbar to autohide, the taskbar appears and disappears too quickly.
Summary: When I set the taskbar to autohide, the taskbar appears and disappears too qu...
Status: RESOLVED FIXED
Alias: None
Product: plasma4
Classification: Plasma
Component: panel (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 193736 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-12-14 00:08 UTC by Nick DeWaal
Modified: 2009-08-27 15:45 UTC (History)
3 users (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 Nick DeWaal 2008-12-14 00:08:22 UTC
Version:            (using KDE 4.1.0)
OS:                Linux
Installed from:    SuSE RPMs

I set the taskbar to auto hide which is a nice feature.  However, because the taskbar is a small area on the bottom of the screen, my mouse cannot move even a tiny bit above the taskbar before it hides again forcing me to try harder to keep my mouse low to keep the taskbar visible.

It would be nice if there were to either:

1.  A delay of maybe 0.25 seconds or so before hiding the taskbar after the mouse pointer leaves the taskbar, or

2.  Require the mouse pointer to be a little bit higher above the taskbar before it auto hides.


Also, the reason why I use the auto hide of the taskbar is so that I can use the part of my screen that would usually be covered by the taskbar.  But as soon as my mouse pointer hits the bottom of the screen, the taskbar is activated when in fact I really wanted to use the mouse pointer for something in my browser for example.
This could be fixed if the taskbar had a time delay of maybe 0.25 seconds or so (not too long) before re-appearing.  (Be careful not to set it for too long though because then people will say it is too slow to activate)
Comment 1 Aaron J. Seigo 2008-12-15 17:21:40 UTC
i don't like the idea of a delay on show, but on hide that'd be fine. would have to wait for 4.3, though, as this would be easy to get wrong so i'd prefer to do it earlier in a dev cycle.
Comment 2 Gary Krueger 2009-03-07 21:49:56 UTC
Howdy Aaron!  I'd also like to see a delay to auto-hide/auto-show for panels.

It is a bit irritating as I'm zipping the mouse around on the screen, and the panels keep sliding in the way, and I have to run back around with the mouse to get them to go away.

If I had thin panels, it would be no big deal.  But, my bottom panel takes up 1/3 of the screen.  Why 1/3 of the screen?  Well, I like to use the pager in such a way that it shows a visible representation of each workspace (with workspace name).  And, I've configured all 20 of them.

If you'll notice, the Gnome panels have a small delay with auto-hide and a small delay with auto-show.  It is hardly noticeable in the course of a day.  But, not having the delays is quite distracting through the course of a day.

The biggest reason that I like KDE, is that I can have a miniature representation of each workspace in a panel that hides away.  I cannot get that in Gnome.

Besides, KDE looks way too cool (to use anything else).
Comment 3 Christoph Feck 2009-05-28 04:40:16 UTC
*** Bug 193736 has been marked as a duplicate of this bug. ***
Comment 4 Maciej Pilichowski 2009-05-28 08:39:01 UTC
Ad. #0.
1) and 
2)

Me too, I hope everybody think about configurable behaviour (values).
Comment 5 Gary Krueger 2009-08-24 18:13:18 UTC
I have found that reducing my mouse acceleration and threshold keeps the display from getting too nutty.

Still, a little bit of delay on the panels would be nice.
Comment 6 Aaron J. Seigo 2009-08-27 12:25:12 UTC
there's still no delay on show (nor will there be), but there is one on hide now.
Comment 7 Maciej Pilichowski 2009-08-27 14:12:21 UTC
Aaron, could you please explain the reason for no timeout on show. It is problem because if you touch the edge by accident you get the panel, now to get to the app part (which panel covers now) you have to move out, and move back again.

One size shoe does not fit everyone, and there are handicapped people around, or even simply -- older, with rather mild reflex.
Comment 8 Aaron J. Seigo 2009-08-27 14:31:29 UTC
> could you please explain the reason for no timeout on show.

perceived response / sluggishness.

> One size shoe does not fit everyone

indeed; and the only way to satisfy the use cases you mentioned thoroughly with autohide is to make the delay configurable as the needs change from person to person. autohide is an option itself, and can be turned off. adding more options to tweak an option so that (non-default!) option works better for a small group of people at the expense of every one else isn't great. if auto-hide was the default (or under a handful of other conditions), it'd be a different matter.
Comment 9 Maciej Pilichowski 2009-08-27 15:00:16 UTC
> > could you please explain the reason for no timeout on show.
> perceived response / sluggishness.

Aaron, you are mistaken. For older people time passes at slower pace. So it is exactly what I pointing at -- one size shoe does not fit all. For you/me response time below 0.1ms is snail pace, for older people 2 seconds is quick reaction. I constantly observe how much time they need to grasp what is going on screen, when at the same time I have the "answer" from the start.

> the only way to satisfy the use cases you mentioned thoroughly with
> autohide is to make the delay configurable as the needs change from person to
> person. autohide is an option itself, and can be turned off. adding more
> options to tweak an option so that (non-default!) option works better for a
> small group of people at the expense of every one else isn't great.

In what way the majority of users pay this "expense"? Is their time taken? If they are suited with 0ms time response, that's fine. But if somebody would like to change the timeout, there is a chance to do it.

Hiding panel is a must for any smaller screen, because the rest of KDE apps cannot handle low-res screen.

I am really concerned with ignoring a11y issues in KDE (especially in plasma) -- I am not saying all issues, it would be exaggeration, but many of them. Handicapped/older people are not second rate citizens in computer world, and there is no harm done I think it would be nice gesture to consider their needs.
Comment 10 Aaron J. Seigo 2009-08-27 15:14:33 UTC
"For you/me response time below 0.1ms is snail pace"

that's what i was referring to: the majority of our users.

"for older people 2 seconds is quick reaction."

for _some_ older people (higher % than amongst younger users). and for _some_ younger people this is the case well.

"In what way the majority of users pay this "expense"?"

for the last time: configuration options add weight to the configuration UI which rapidly becomes a usability issue (not to mention creates issues with small screens, which you seem to also care about) and make the code harder to maintain. for options that really don't impact many people and which have other answers, that makes it not worth it.

i've explained this before.

"Hiding panel is a must for any smaller screen"

hiding is a useful feature, but it's neither a must as you put it or on by default. one can also get a screen with better resolution.

"I am really concerned with ignoring a11y issues in KDE (especially in plasma). I am not saying all issues, it would be exaggeration"

well, you're still exaggerating. or rather, what you are advocating is that whenever there is a possible a11y issue, even in an optional feature somewhere, that it should trump _all other concerns_ regardless of the severity of the issue itself or the consequences of the fix or how many people the problem affects in the first place.

such a narrow a11y-at-every-cost approach comes at the expense of everyone else. do we need a11y features? yes! we don't need every single possibly imaginable a11y improvement, however, and we can't provide that without degrading other aspects of the experience.

"there is no harm done"

that's not correct.

(final comment on this report from me)
Comment 11 Maciej Pilichowski 2009-08-27 15:45:06 UTC
> "for older people 2 seconds is quick reaction."
>
> for _some_ older people (higher % than amongst younger users). and
> for _some_ younger people this is the case well.

OK, KDE is for healthy people. And minority can be ignored.
Further reading:
http://www.joelonsoftware.com/items/2007/09/11.html
start from "In one of Gerald Weinberg's books".

> for the last time: configuration options add weight to the
> configuration UI which rapidly becomes a usability issue 

Yes and now, I would not mind option in rc without UI frontend. This would allow solve a11y issue without adding anything to UI. Mean does not mean candy.

> "Hiding panel is a must for any smaller screen"
>
> hiding is a useful feature, but it's neither a must as you put it
> or on by default. one can also get a screen with better resolution.

You cannot get both -- suitable computer for traveling with big screen.

> such a narrow a11y-at-every-cost approach comes at the expense of
> everyone else. do we need a11y features? yes! we don't need every
> single possibly imaginable a11y improvement, however, and we can't
> provide that without degrading other aspects of the experience.

If you are not even interested in considering them, they won't happen. And this improvement is not imaginary, it is real-life case.

Do you have the guts to say to older people "hey, buy a bigger screen and hire somebody to carry it around" (rhetorical question)?

I wish you you won't have to learn the big lesson first-person and hearing this nice, smooth, cruel "helpful hand -- won't happen".