- General hiding:
- unhides triggered only where the panel is, not along whole screen edges, making non-full-width panels behave a bit nicer
- unhides on drag enter, hides again on drag leave. I actually ended up implementing the first half of the XDnd protocol (X11 doesn't actually do drag and drop natively!) by hand using xlib calls to make this work. Every time I touch xlib I am reminded how much a I love Qt and KDE libs for making it possible to never touch xlib for anything sane. (Unfortunately, desktop shells involve all sorts of insanity. ;)
- Auto hiding: when the mouse leaves the panel, the panel hide; when it hits the screen edge it unhides. General features/improvements:
- will not hide if a popup is shown, hides when the popup goes away if the mouse is not in the panel
Compositing-only features:- Glow: when the mouse approaches, a small glow on the screen edge appears, brightening as you get closer, to let you know there is a panel there.
- Animation: animates in/out of the screen. Works fine with the system tray now (well, mostly; it's not pixel-perfect, but as close as we can get it) as well as with multiple screen setups (e.g. it won't "hide" by moving to the other screen as kicker would)
- Windows-can-cover: windows are allowed to cover the panel and while the panel never disappears off-screen, it can be pulled back to the top by mousing over the screen edge it is on
- Does not flicker madly after unhidden if the mouse doesn't leave the screen edge
- No glow effect since the panel is actually always on screen
The last of open hiding-related bugs on bugs.kde.org were closed, save one that has to do with how to unhide a panel that is hidden on the screen edge between two panels (which is hard to do, of course, as there is nothing "stopping" the mouse cursor from moving right past the unhide trigger area).
The hide/unhide animation speed is not configurable; I'm really not sure it needs to be. We'll see. 4.2 will ship with a sensible setting (1/10th of a second to unhide, 1/5th of a second to hide).
Things left in terms of panels for post-4.2 development include:
- Positioning of multiple panels that overlap; right now there is no code there to automatically manage such situations; you need to configure the panel widths yourself. Kicker used to stack panels, but that leads to all sorts of sad situations. This is could be an interesting not-too-complex research project.
- Optional per-virtual-desktop panels, much as we now have the experiment per-virtual-desktop Activities.
- Activity aware panels, so when the desktop activity changes, the panel could too.
- Other panel types (Containments), like a dock style.
- Manual hiding, though I'm not sure there's actually sufficient demand for that to warrant it's inclusion?
So there is still a few interesting avenues to explore with the panels in the Plasma desktop shell, but they are getting fewer. With 4.2, Plasma has virtually all the features Kicker panels did and a few it didn't.
All I know is that, barring new bug reports coming in, I probably won't be touching the panel code for a couple months. =)
15 comments:
Thanks for the fixes!
I do have one little question though, it's also about the hiding. I can't test this for the moment so I don't know for sure if it is still there, but a few weeks ago notifications would appear at the height of the panel, even if the panel was hidden. It would be nicer if the notifications were on the screen edge when the panel is hidden.
I can report a bug for this, but can't test it now.
I also have one small feature request (post 4.2), it would be nice if the systemtray would glow (like the panel does) if something needs your attention when the panel is hidden. I don't know if this is possible because I read a lot about the *bad* systemtray but I think it would be nead feature.
Again, thanks a lot for the great work.
KDE rocks!!
One situation where manual hiding is handy is for netbooks with small screens. An autohiding panel can be annoyingly easy to trigger on a small screen where most applications are run maximized. Perhaps a plasma-on-netbook user wouldn't even bother with panels, but it is worth considering before you completely rule it out for future releases.
How's it work on MacOSX and Windows? :-) (I just ran the experimental plasma.exe on XP, not quite sure what's going on.)
Every time I touch xlib...
When will KDE/Qt migrate to the XCB interface, it's supposed to be slightly more pleasant to use and has the possibility for better performance through request batching and threading improvements?
Thanks for all you do.
I have to chime in again about the importance of per-activity panels! The idea of activities is great, but because they don't include panels, the concept falls a touch flat for me. It would be great if people could set up and switch between truly different ways of interacting with the desktop depending on what they are doing, but because panels contain such fundamental functionality and because there is a the common panel setup, I don't think the activities can really be too different at all. Instead, I think that they can only really be used to shuffle around the more non-critical plasmoids.
Ideally, I think it would be great if you could hit a hotkey for a new activity and be presented with a completely new desktop- at that point, the desktop would truly become transient and disposable for the immediate purpose (i.e. just delete it when you're done, or not, if it will be useful later). Thus, one would be able to truly play with different ways of working with the computer and never be trapped with a "default" (either one that is imposed by designers or one set up by the user herself). As it stands now, it's too much of a hassle to change your panels to be useful for whatever you're doing at the moment without affecting your day-to-day setup.
Again though- great work. So impressed with 4.2.
"Activity aware panels, so when the desktop activity changes, the panel could too."
when this will be reade, kde4.2 or kde4.3 ??
How about XCB instead of Xlib?
Hi Aaron
Ive been following you blog for a year now and finally got the courage (and knowledge) to post :) Your amazing work is greatly appreciated!.
I have a question/request though I know it wont be ready anytime soon. I used to use a dock up until i switched to kde 4.2.Now i use the kde4 panel since I just love all the kde4 look and feel. What I loved in a dock was that every running program was always in the same place (for example firefox is always in the utmost left side of the dock etc..). right now in the task bar the tasks/programs are either random or alphabetically sorted and jump position everytime a new program is added. I would love to see an option to define where in the taskbar the programs will be placed every time.
Also I noticed you mention dock like features for the taskbar in the future, the would be an awesome addition.
Once again thx for all your work and effort, kde4 really rocks and is greatly appreciated
Zeltak
Yes, manual hiding of panels is one of last not implemented but needed things :-).
Maybe this could be achieved by creating plasmoid (very big placement possibilities) that could trigger behavior similar to that of auto hiding.
Also different per-virtual-desktop panels would be very interesting :-).
Hi Aaron!
I am using neon packages for KDE 4 wich as far as I know are very close to trunk.
My, albeit tiny, issue with panel autohiding is that the unhide-effect produces a little flicker that does not look very nice. Just an instance before the blue glow and respectively before the taskbar appears for the fraction of a second there is sort of a "bar" in that same place. The bar is of similar color as the background but not identical.
I am only reporting this so you know (wich you propably do already) not to complain. It does not cause any troubles at all - apart of not looking to good.
(I don't know if maybe it is due to the Nvidia drivers?)
Otherwhise thank you very much for what you do. Your way of working is very impressive and inspiring.
Johannes.
About the manual hide thing: I always liked the feature in compiz where you can choose a side and a key or mouse key to trigger a effect. It would be cool to have that feature for panels (and for desktop effects for that matter).
For example: I'd like to raise a panel on the left side of the screen when i point the mouse cursor to the the left of the screen (not just the panel) and pressing the right mouse button. Now that would really help me, cause now I get like 'harassed' by panels and desktop-effects at times I really don't want them. (Like when I try to close a full screen window and the 'present windows'- desktop-effect suddenly shows).
I don't know if this is the place to make a feature request, but I don't know where to do it otherwise.
Thank you very much and best wishes for 2009!
I think the glow effect is going to be very popular. I know I will come under fire for suggesting that one should possibly copy Microsoft, but what about a panel OPTIONAL feature to only show icons as opposed to icon/text akin to Windows 7? One one hand, it uses less space horizontally, and it looks nice. On the other hand, it is hard to differentiate from an icon that it is a shortcut and an icon that represents open windows if there is no distinction between the two.
i updated kdelibs and kdebase from svn last night to check this new functionality and plasma didnt load ..just updated both kdelibs and kdebase and plasma still doesnt load ..
..just though i should share so that people who ran kde4 from svn not try to update at this moment ..
for tablet users it might be nice to allow the hot zone to be larger than the screen edge. It can be kind of annoying to hit the exact screen edge when you're using a tablet. "flyout" panels that appear when you pointer-over a small rectangular region (e.g. about the size of the kde 3.x manual hide buttons, though not necessarily visually represented) might be nice, though it'd only be a small savings on just clicking the manual hide buttons I guess.
There's one feature in the Kicker that is still missing in the plasma panel. Per-panel transparency. With the Kicker, I could set the transparency for each panel separately. One of my favorites was to have a single panel, center-aligned, with just app icons and full transparent. It was real cool, sort of like the OS X dockbar. I still can't do that in the plasma panel. Transparency is there, but only system wide and only through the plamsa theme.
Just my 2c.
I use KDE 4 (Mandriva PowerPack 2009) with all updates on a laptop and my TV server. Sometimes, a white bar will appear just above the panel (as if it were being themed by KDE) and will not go away unless I rename my .kde directory. It seems to happen when "allow windows to cover" is selected, but will not reset when this feature is deselected. I run smplayer for my videos, and it has erratic behavior with the panel, sometimes covering it in fullscreen, sometimes not. That is why I tried selecting "allow windows to cover"
Post a Comment