Friday, March 11, 2011

panel hiding

With all the news of mobile and politics and what not, I thought it might be nice to hear about things we're working on related to the desktop that, while maybe not as earth shattering or exciting, are none-the-less part and parcel of what we do each and every day.

One of the things we introduced in recent releases of Plasma Desktop was panel auto-unhiding: if you have a hiding panel and something in it says, "Hey, I need the user to notice me!" then the panel will happily unhide. This was only possible because we have the ability to know things like the attention and input status needs of components such as Plasmoids and Status Notifiers.

Unfortunately we hit a snag: not everything sets the attention status sanely. This would sometimes lead to a panel being "stuck" in the unhidden position, unless you could find out what was "sticking" it and cause that component to become "unstuck". Not very elegant.

After stumbling through a few other random issues yesterday and today, I implemented an approach that tries to balance all needs. This was something that came out of discussions with hiding panel users who are also KDE contributors, particularly Kevin Ottens and Thomas Zander.

In the plasma/panelunhiding branch in kde-workspace, a panel will now auto-unhide and then rehide a few seconds after any user activity. That means that if you walk away from your computer, something happens and you return, the panel will still be there in a visible state to let you know. However, if you are using the system while something goes into "I need attention" state, then the panel will pop up but then mercifully slide back out of view in a few seconds time without you do anything.

I'll be testing it out more over the next few days and welcome others to do so as well, and then if all goes well with this approach then I'll merge it into master and, if it's really solid, maybe even merge it into 4.6.

12 comments:

adeus said...

On a semi-related note, anything hidden, or more precisely something you get visible by e.g. move your mouse close to it, pretty much destroys usability for the touch screen. One of the many little things that pretty much force you to redesign things for touch from the get-go.

Aaron J. Seigo said...

@adeus: yes, this is a set of features designed for mouse-driven usage. it is not meant to be used in touch environments.

for touch driven design, we have whole other sub-projects within plasma.

however, just because we have touch driven interaction doesn't mean we should suddenly wholesale ignore people who use a mouse pointer. there are several hundred million such devices out there in use with plenty more sold each year. :)

Moltonel said...

Thanks for the workaround, I'm regularly annoyed by a panel that doesn't want to hide, whatever I try. I think this might be exacerbated by using multiple activities but I'm not sure.

But then again it really is a workaround. What would be great (appart from fixing whatever component doesn't notice it got noticed) would be a visual clue on the panel of which component triggered the unhiding. A bit like the "dotted circle around the status icon when you iconize an app for the first time" trick.

I know the status bar has something like that, but it is very faint. And I believe that's the only component that has something. If you're going to request my attention, do it in a way that I actually notice and that I know who you are :)

Kai Uwe said...

Is there also a chance of getting some "intellihide" (how it is frequently called?) feature that a panel autohides when you maximize a window or something?
It acts like a normal panel, once you maximize a window it gets hidden and then moving your mouse to its corner makes it slide out?

xpete said...

I think that would be better to have some glow near the panel to show that the panel is asking fot atention...
like this:
http://forum.kde.org/brainstorm.php#idea91258_page4

pano said...

this is some good news! especially if this bug is fixed:
https://bugs.kde.org/show_bug.cgi?id=267735

It's about the notification widget preventing panels to hide *at all*.

:-)

Fri13 said...

And while tweaking the panel autohiding feature, how about fixing the visual/usability problem with the glow effect showing too near the panel?

I mean, the current range to start showing the glow of autohided panel when mouse gets near is too small.

If I remember it correctly it is something like 25px. It just means that you are already touching the panel.

And if you have multiple different autohided panels on edge, it is much faster and easier to go trough whole edge to check where they are.

The glow should at least have a option to choose the range so it would be 1/8 - 1/3 of the screen size.

That would mean if we have screen height 1200, the hided panel will start glow when mouse is 150-400px range.

That would make the glow function more usable instead just totally pure visual effect what no one can notice.

anders said...

Nice that you found a resonable workaround for the problem. But it is still frustrating that the panel may unhide without showing why. Would it be possible to only unhide if the reason is known and can be visually indicated?

anders said...

@Kai Uwe I use the "windows may cover" setting for the panel, which works a bit like you request: maximized windows () hides the paneland, and when my mouse goes near the panel on the screen bottom, it slides up.

gp said...

Great workaround!
Another great feature would be intellihide!

OT: I'm trying SAL, is amazing, fantastic.
In the future, why not implements it in Plasma Desktop via popup instead Kickoff?

Naproxeno said...

Will this feature play well with a locked screen? I mean, I would like to have an unhidden pannel for a few seconds *after* I moved the mouse and pressed some keys to enter the password to unlock my screen.

burkeone said...

OT: Congratulations! ;-)

Wow, Aaron, 161 comments on "collaborations demise" so far. That is even more than back in 2007 with the "we killed the desktop icons for folderviews sake"-thing. You sure remember.;-)

Obviously you sometimes attract important and long lasting debates.

Back to topic: as adeus said this is something for mouse driven environments. What do you have in the pipe for touch based ui's?

+1 for intellihide