It doesn't work with QWidget based popups yet, though there's no reason it couldn't; Plasma::Dialog just doesn't have the logic for it yet. That means that things like kickoff or the device notifier still behave a bit magically.
I'm pretty sure that when we do extend it to all "things that come out of an edge docked panel" that we'll need to make it configurable (though it turns off automatically when animations are cut in plasma as a whole or when there is no compositer around) since some people will likely absolutely hate it for reasons of personal taste. I think it's jolly good (to use a quaint Britishism), but I can just tell it's the sort of thing someone, somewhere will take umbrage with.
It also occurs to me that this would be so much better as a compositing plugin. However, at least to my knowledge (and please correct me if I'm wrong, window manager people), there's very little interaction possibility between individual windows and the compositing effects. While usually this is perfect (you don't want random windows doing random things because their app developers feel they really ought to have spinning-breaking-apart-windows), in this case it makes me put code in a place it really doesn't belong (the application).
It would be terrific if a window could say "Ok, now slide me out into that other window over there on these positions." We actually already do this for the minimize effects by publishing the location that a window should minimize to/from. I actually tried using that but the results weren't exactly what I wanted because it meant positioning, minimizing then restoring the window and even then it didn't exactly work right (perhaps because the window is set to skip taskbar?).
There are a few such things that would be just awesome to be able to do with more comprehensive application<->window manager interaction possibilities. Which led me to think what now seems like the bleedingly obvious:
It would be beyond awesome to have a window manager developer sprint that focuses on application <-> window manager interaction issues
Such a thing would be attended by people writing high-energy window managers (KWin and Compiz would be two "must haves" there IMHO .. who else? E17, XFCE, Metacity?) and people writing applications or frameworks that could take advantage of such things (e.g. Plasma for the obvious reasons; Qt and KDE lib for thing like document modal dialog (aka "sheets" on MacOS) .. there must be others out there too :).
The goal should be to walk away with a set of agreed upon capabilities, interaction patterns, trigger mechanisms and even some initial implementations in the apps and window managers. It would be great to see things like the "slide 'n hide" window effect we now have in Plasma, sheets, the ability to ask for specific groups of windows to be shown in the currently active window switching style (e.g. present windows or cover flow or whatever the user has selected) for use by things like grouping task bars ... so many possibilities.
I really don't have time for such a thing before the summer is out, but maybe I'll try and hook something up after then. Or maybe one of you could hook it up. The world neither revolves nor depends on me, after all. :)
p.s. Apologies for the lack of screencasts lately, a lot of the stuff I have going on looks best with compositing and my compositing screencasting set up is in pieces atm.
p.p.s. Rob's been doing some rather nice work on improving the feedback when jobs and notifications are hosted in the systemtray; can't wait for that to settle in and for him to screencast that stuff. :)
12 comments:
It would be fantastic to have an animation that shows where applications that are minimized into tray "are going to" (Just like for normal minimizing). Will that be possile with the new tray?
@gissi: yes; we now have the ability to treat the systray icons like proper first class citizens.
we can also even merge them into the task bar itself now if we wanted to go "all the way" :)
I think that the argument for natural behavior has a hole: Computers behave unlike anything in the physical world in many more instances than just window management (e.g. popup menus, tabbed interfaces). That does not make what you suggested a bad idea though.
My number one wish would be a fix for the annoying popunder problem, i.e. modal dialogs that block the main window, from *behind* the main window.
While it is not the normal behavior it is quite easy to trigger with a minimize at the right time.
So, is there any chance that we will be able to turn panel animation on or off independent of the rest of compositing? (or better yet, allow us to set the speed on the animation as was in KDE3).
Personally i prefer it when my hidden panels appear as quickly as possible when i need them. Animating their appearance is just a nuisance to me.
As is panel transparency for that matter.
Speaking of improving jobs and notifications: I have two problems with current notification system:
1) notifications stay either for too long. For example you receive a bunch of messages with kopete and you are currently busy doing something else, extenders are stacking up to a huge tower covering the screen and apparently never disappearing.
2) or notifications stay too short: sometimes I get notifications on KDE startup, which disappear usually pretty quickly, including the i-symbol in the tray, with no apparent way to read them later. Also e.g. copy jobs usually disappear, before you know that you download is running fine. However when the job extender is visible and the job is done, it's staying forever (see 1)
(as a side note the finished state is not really visible, you have to detect the word "finished" to be sure).
Oh, and dragging extenders makes plasma usually crash ;)
But basically I love plasma. The first time I'm actually doing something useful with my desktop. Keep it up!
This is interesting because I've been talking with the kwin guys about making an effect (hopefully still for 4.3) that would allow an application to request that its window be made to appear and disappear via a slide animation, using a _KDE_SLIDE window hint to set an origin/target screen edge/corner and an animation duration in miliseconds.
The purpose being to move Yakuake's crude XShape-based animation into kwin to make it smoother (I maintain/develop Yakuake). The thought came up that Plasma could make use of the same effect for its auto-hide panels feature.
@maelcum: "Computers behave unlike anything in the physical world"
it's not predicated on computers behaving like things in the physical world; it's predicated on the concept that there are patterns of behaviour that our mind have evolved to work with and so just work better with the human being.
@Dirk: "is there any chance that we will be able to turn panel animation on or off independent of the rest of compositing?"
no plans for that at the current time.
"As is panel transparency for that matter."
not all themes have a transparent panel. you could, for instance, use Aya.
you can also use the theme customizer in the control panel.
@redm: "extenders are stacking up to a huge tower covering the screen and apparently never disappearing."
this is already fixed in trunk/4.3
"with no apparent way to read them later"
we plan to offer a log at some point, though you can already log things via knotify directly as well. and this problem is nothing new.
"as a side note the finished state is not really visible, you have to detect the word "finished" to be sure"
already fixed.
"dragging extenders makes plasma usually crash"
already fixed.
@Sho: yeah, spoke with Zarin about this last night. are you actually working on it? if not, we need to get some work happening on this. it's just too important a feature and it really does belong in the WM.
@Aaron: I've been playing with it, but I've not yet produced anything really workable, largely due to lack of time :(. If anyone else wants to jump on it that wouldn't be a problem with me. I'd like to be kept in the loop, though, so I can weigh in from the perspective of Yakuake's needs :).
I did add it to the feature plan, though, so despite soft freeze, there's still a window of opportunity for 4.3 :-D.
Yeah maybe you can fix that annying old drag-and-drop bug. Try dragging something from a maximised background window to one in the foreground. Doesn't work in linux because it is instantly raise, obscuring the target.
Have you seen Kmess' bugs/wishes/etc report system? I think it's a great idea (although it could be improved, like everything in the world). It's very comfortable to the user, and easy to use.
I think its use across KDE would be very useful and would help it to improve, because users could report stuff in an easier, faster and more comfortable way.
For example, you could add fields for username and password for the KDE Bugzilla, so that nobody could spam it, and could be an entry in the "Help" menu.
By the way, thanks for your work!
Here's an extra bit on the animation duration thing since someone supplied me with an IRC log of your chat with Zarin: Yakuake has a user-visible setting for the duration of its animation in miliseconds. And I need to keep the old animation code around for older KDEs and non-KDE desktops. The duration setting is very useful with the old animation code since it helps with compensating for performance differences between the various graphics drivers, but people also generally like to be able to control the duration of their Yakuake animation.
I'd prefer not to have to figure out how to communicate to the user why the length option in the config dialog gets disabled depending on the environment/the animator used, or some other such complication ... hence requesting the animation time was one of my requirements :).
[OFFTOPIC]
It's possible, or, better, does make a sense to develop a plasma container (aka the old desktop) like bumptop?
Post a Comment