So far the total diff is +47 -42 lines: a sum total of five new lines of code. For those lines of code we get a couple new features, including being able to tell the system tray that we are a hardware related item and that we're currently active.
The first neat thing I noticed when it appeared in the system tray was that it behaved like all the other icons: it glowed when it was hovered over, it grew smaller when it was pressed. It suddenly felt a lot more like it belonged with the rest of the things on the panel down there. It wasn't some odd alien anymore.
(Which reminds me: in 4.3 when you press on Plasma::IconWidgets the "get smaller" as if you are "pressing them into the canvas and therefore receding away". It's the same kind of effect I put into kicker back in .. oh .. 3.3? 3.4? Something like that .. anyways, it gives some nice "tactile" feedback for those icon buttons. Anyways, back to the system tray stuff .... )
The coolest thing, however, was when I started a second system tray using plasmoidviewer: now I had two trays in two different processes ... and the KMix icon showed up in both. None of the other icons did, of course. One more step towards closing a feature wish I first came upon years and years ago for Kicker: to have multiple trays for multiscreen systems. :)
The DBus protocol behind all this had all the wiring in place for stuff like wheel event notification, but not all of it wasn't plugged together in the actual system tray code. So I went off and did that bit of ankle-bone's-connected-to-the-mouse-wheel-bone work and there was wheeling goodness again in the KMix icon. Great!
There are still a few small things to take care of, like making the DBus calls on the system tray plasmoid side non-blocking so we don't end up freezing the whole of plasma-desktop due to a misbehaving app on the other side (the wheel event call is already non-blocking since I just put that one in there, but the others are synchronous), figuring out what kind of geometry information we want to pass back for main window activation (kmix likes to position it's slider popup using this information) and couple other minor points.
A current assessment of KNotificationAreaIcon is that it's a really long name but it works right out of the box, including with xembed-only system tray environments, with only a few minor (though quite fixable) caveats at the moment. It needs some tweaking and polishing, but it should be in great order before 4.3.0 given it's current state.
Support for this on the Plasma side is already in svn for 4.3, but we're planning and plotting how to go about the application side. Our current strategy is this:
- Port a couple of KDE applications to the new application side API, KNotificationAreaItem, to prove and stress the current system and APIs, fixing bugs and implementing needed features as they crop up. I've already done KMix, but we're looking for a couple more to join the game. Come find us in #plasma on irc if you'd like to try it out in your application, or just take a look in playground/base/plasma/libknotificationareaitem and figure it out on your own. :)
- Write up a detailed spec and put that on Techbase as documentation for the DBus interaction bits.
- Take it all to kde-core-devel for comment and hopefully approval for kdelibs. My personal goal is to have it in KDE 4.4's libs. I'm not sure we can (or should) make it in for 4.3: we can port select apps using a small helper lib for 4.3 that doesn't have the BC guarantees that kdelibs caries. We could perhaps install it as a static lib even that apps just "suck in" to avoid any BC issues of any sort. If there's both comfort and demand for this, we can put it into 4.3's kdelibs .. but we've lived with the current situation for years and years, another 6 months limping along with a static lib won't kill us. ;) In return we'll get good usage info and be able to modify the API or DBus service as needed.
- Assuming it goes well on kde-core-devel, then we will take it to freedesktop.org.
- Have some icecream, watch the lilies grow in the field
- Fast forward a few years to a time when we no longer have any of this xembed crap to deal with in the tray anymore.
Happy days are here again.
16 comments:
Cool! Any screencast? :)
That's some sweet poetry for sure! <3
Glad to see that work is being done on KMix, as it is indeed a little bit 'out-of-place' in KDE 4. I little question/suggestion: why is there in KCM a very nice icon (the speaker) for multimedia configuration while in the taskbar Kmix has a 'old-style' icon?
Regards, Harry
Good to see work being done on KMix. Sad however that Pulse-Audio still spoils the show for Linux audio. Half-assed semi-stable audio is the last falling-point, and more than likely the reason for many rage-quits. With Fedora 10 it's even harder to remove.
While I understand your role remains within Plasma, - I'd really like to see you change out the koolaid the guys on Pulseaudio are drinking. They're in dire need of some help/love.
I've always wondered this: what's the logic behind having the power manager, network manager, and new device notifier be Plasmoids, but the volume control, keyboard layout switcher, and clipboard manager be system tray icons? Or I suppose I should rather ask, given unlimited time and manpower, which of these should end up being which and why?
Regarding Kmix: why hasn't it been turned into a plasma applet? It's kind of a sore thumb right now and probably could use some phonon-per-app-volume-adjustment integration love.
@Spockfish: "KCM a very nice icon (the speaker) for multimedia configuration while in the taskbar Kmix has a 'old-style' icon"
good question. i'll ask the oxygen team about this.
@IvanT: "I'd really like to see you change out the koolaid the guys on Pulseaudio are drinking"
i have spoken about it in my blog and in some recent interviews as well. it tends to get yelled down by the pulse audio developer who obviously is very attached to his pet project. the people we really need to reach are the distribution decision makers, they are completely and utterly failing their user base right now by including pulse in its current state.
but they are another bunch of typically cantankerous, "we know better than everyone else" crowd. for all the talk of community, there is very little actual listening and collaboration that goes on outside each of their own little enclaves.
@illisius: "given unlimited time and manpower, which of these should end up being which and why?"
they should all be plasmoids imho; they don't need to be portable outside the workspace and would benefit from closer integration. but it's a matter of time and energy, indeed. we'll get there :)
@yokem55: "why hasn't it been turned into a plasma applet?"
two reasons:
a) time and energy; someone simply needs to be found to do it. since it currently basically works as it is, there's not a huge amount of pain being felt and so not a huge amount of hands are rushing in to improve things
b) there's a huge allergy in the KDE dev community around plasma these days and the idea of "kmix as plasmoid", even though it would still remain as a separately-launchable app just as it is now (something anlogous to `plasmoidviewer mixer`, but on steroids and called "kmix" ;), has been met with pushback.
this POV is based on a lack of understanding and information, so we (plasma team) carry at least part of the responsibility for this. there is, however, a distinct lack of care being shown by some who just couldn't be bothered to investiage, query and learn but are quick to offer opinion all the same.
it's getting better as we go along and prove the concepts in plasma more and more over time ... my day to day is still often an exercise in frustration, however.
Aaron,
I'm not a PulseAudio enthusiast, but it does need a little defense here from drive-by attacks.
Lennart Poettering obviously cares just as much about Pulse as you do about Plasma. Plasma is trying to redefine the desktop experience, Pulse is trying to reimagine the entire Linux sound infrastructure. You're both men on missions, apparently.
And people complained --and still do-- about Plasma too, many times without merit.
If I remember correctly, you yourself criticized distributions for their part in the release of KDE 4.0. You have made numerous references to the effort taken to express exactly the test-audience that KDE 4.0.x was meant for, and how that message was ignored by distributions -- at their peril, and at peril to KDE's reputation.
You can argue (in fact, you mostly just did) that the same thing has happened to Pulse. Not only was it best handled by a test-audience and a mistake for the casual user, but distributions were too adamant about splashing it in without actually caring how well it fit into the setup, despite user complaints.
In your defense, his project is arguably messing up yours, while even Plasma at its roughest state wasn't screwing up sound. But maybe you should cut him a little slack, as your comparative situations have been very similar.
One key difference seems to be that he has _no_ choice but to attempt to win developer mind-share; unless distributions use Pulse, it will never catch on. Your already have a guaranteed audience for Plasma (you have an effective monopoly on KDE users), but for Pulse to succeed, it does in fact need to be force-fed (to some extent) to the community. (I'm not saying I like that, but that's the truth.)
@Jud: "Lennart Poettering obviously cares just as much about Pulse as you do about Plasma."
absolutely. our passion doesn't make either of us right in and of itself, of course.
"Pulse is trying to reimagine the entire Linux sound infrastructure"
this is the part i don't get, much like i don't get the current notifications reinvention: we had arrived at a point where things were working and working well. there really was no breakthrough experience being robbed nor any breathtaking landscapes to bring us into before others got there.
with both efforts, we (F/OSS desktop) are breaking things that worked well enough to compete well into the future.
what i have yet to hear is why we should want to need PulseAudio. so far, what i've seen, read and heard was all addressable without breaking things by starting anew.
while doing so is fun or even the easiest route, it's not always the best route. rarely is, in fact.
case in point: with kicker/kdesktop we had simply hit a brick wall. there was no way to get it move beyond that wall without dismantling it piece by piece and rewriting it back up. (not to mention the effort added by the qt4 porting)
combined with the goals of changing how we write and conceive of primary user interfaces, there was a real reason to make the leap.
"you yourself criticized distributions for their part in the release of KDE 4.0."
.. because we advised them not to do exactly what they did.
"that the same thing has happened to Pulse"
i think it absolutely has, but with one big difference: the man behind PulseAudio doesn't see to be saying that this is a bad idea. it seems Lennart is just fine with PulseAudio being out there and not caring that it, for instance, breaks with one of the most popular audio chipset out there right now (that pesky Intel piece).
because Lennart is apparently complicit, evidenced by his actions and attitude, he's equally deserving of the "what are you doing?!" as the distros are on this one.
"Not only was it best handled by a test-audience and a mistake for the casual user, but distributions were too adamant about splashing it in without actually caring how well it fit into the setup, despite user complaints."
i completely agree. there is a real sickness amongst the big desktop distros these days when it comes to rushing into things without allowing pragmatism to balance their hands at judicious moments.
"his project is arguably messing up yours"
at least in this Pulse joins the company of several other projects who are busy wreaking havoc in the foundations of the f/oss desktop and having it shipped with "today latest distro upgrade" ;)
"One key difference seems to be that he has _no_ choice but to attempt to win developer mind-share; unless distributions use Pulse, it will never catch on."
the problem with that approach is that we then get a game where whoever is most belligerent and unreasonable will get their stuff "in". i mean, who cares about technical details or user satisfaction, right?
we have really lost sight of our goals in all this, namely to provide a good user experience by: allowing developers to push boundaries in safe harbour, package up experimental and stable issues (doesn't need to be the same distro even!) for users on different tracks as far as expectations and needs are, making technology selections based on technology fundamentals and agreed on by consensus.
so, how could PulseAudio get it's support going? i'd suggest the following:
* be released in $DISTRO experimental release $FOO
* have $DISTROS announce that in $TIMESPAN time they will be making PulseAudio the default unless there are unfixed technical deficiencies that remain, at which point they will either delay or abandon
* put the onus on the application developers to point out those deficiencies by actually using PulseAudio; if they don't say anything, then $DISTROS won't know, the default status will go ahead as planned and nobody has anyone to blame but themselves
* Pulse has some community media attention paid to it (this is one of the dangers of a dysfunctional community, btw: you can't focus lights where they need to be quickly enough or with enough intensity)
* app developers then start playing with it and experimenting with it
* a year later, we have goodness.
now, Pulse did kind of float around here and there for a while. but i never read about a roadmap for it, i never saw any outreach to upstream or tester base feedback from those making the decision to make it the default choice for their users .... etc.
honestly, the above is really what i expected to happen with kde 4.0. i was a damn fool, however, and completely misjudged how distributions are making these decisions, how the community media decides to spotlight things, etc. and so played my cards pretty poorly in light of the actual reality.
*sigh*
so no, i don't think Pulse is somehow inherently evil, i just think that it, as with many other pieces of the F/OSS desktop stack, are suffering from a lack of reasonable pan-community coordination and collaboration.
there's too much self-interest, too much navel-gazing and not enough "we're actually, really doing this thing together, not just talking about it as if we are" going around.
You bring up many good criticisms of Pulse, but even so I am not as critical of Pulseaudio's rollout. I no longer think of it as exceptional or weird. In fact, in comparison to your ideal "how we should rollout experimental software" template, I think the Pulseaudio situation was a logical conclusion of the free software community processes.
I think the problem is actually that no one really trusts a democracy of developers -- even the developers themselves.
In Lennart's case, he probably had no expectations that developers would spontaneously decide to abandon the spaghetti legacy Linux sound infrastructure and move to Pulseaudio. And why should he? You said yourself that everyone was very happy.
And with KDE 4.0.x. Why exactly, when the desktop was test-quality, was a public release pushed? Because the KDE community wanted more exposure to it. Which was understandable.
And why was that? Because otherwise, no one would have ever contributed to KDE 4.1.x and up. A movement requires _momentum_, and KDE4 needed an injection of it.
Most free software developers who have a vision and want to change the system don't have the benefit of A) programming the better system, and B) waiting for them to come.
"If you code it, they will come." It appears that the free software community really doesn't believe that (at least in regard to its own desktop platform), or forced platform changes would be less frequent.
And after all, I don't believe it either. If KDE 4.x was a perfect system from the very first beta, I highly doubt free software developers would move to it. As a whole, everyone is very attached to "good enough." It had to be pushed out, and it seems that the KDE community didn't anticipate all the difficulties in doing that. You say you were a fool in thinking that your ideal rollout method would work, and I wonder if your ideal version does in fact have flaws that contradict the trends of open source development.
This is what I see as the reality of Free Software. It is not outrageous, merely a little disappointing.
You said that "there's too much self-interest, too much navel-gazing and not enough "we're actually, really doing this thing together, not just talking about it as if we are" going around." And that perception is in fact at the root of it. How would you work in such a system? You might have taken Pulseaudio's strategy.
To my outsider self, there is little centralization of vision, and therefore no compulsion to follow a central vision. Anyone who wants to profoundly alter the system has little choice but to shout, and earn mindshare, and play crowd politics. That's why I don't really blame Pulse or Lennart, or the distributions. It is a synergistic effect of how the community operates, rather than a conspiracy to hurt users with experimental software.
I do think that KDE4 has a chance to be great despite all of this, because it is actually trying to posit a cohesive vision for the future desktop.
I commend you for working in such a strange system, I really do. Great things can be done. It just looks really darn difficult.
You totally don't have to approve this. It's a little long.
@Jud: "I think the problem is actually that no one really trusts a democracy of developers -- even the developers themselves."
...
"And why should he? You said yourself that everyone was very happy."
right, so if the people don't see a need for it, why does it therefore need to be pushed on us? no belief in democracy indeed; more realistically though we don't need true democracy in designing technology anymore than we need it in making icon themes. what we need is the ability to set good direction based on consensus. that's can be, but isn't necessarily, accompanied by a democratic system.
"Why exactly, when the desktop was test-quality, was a public release pushed? Because the KDE community wanted more exposure to it."
we wanted to draw a API stability line in the sand, get back to doing evolutionary releases at regular intervals, get it to application developers to start working with, get it to packagers to start prepping their build techiques around it ...
it wasn't about "more expoure" in the sense of "get it into everyone's hands asafp".
"no one would have ever contributed to KDE 4.1.x and up."
well, not no one, but certainly fewer people and we'd have gotten less feedback from our bleeding edge crowd.
"A movement requires _momentum_, and KDE4 needed an injection of it."
4.0 was not about building momentum among users, though: it was about moving across the line from "blue sky development" to "working on the conclusions"
"forced platform changes would be less frequent."
i agree; i'd just also note, however, that kde4 was not a forced platform change. we even continued to do 3.5 releases.
"This is what I see as the reality of Free Software. It is not outrageous, merely a little disappointing."
it's not outrageous, no. but it's highly disappointing, mostly because we can do much, much better.
"How would you work in such a system? You might have taken Pulseaudio's strategy."
i'd work to change it. oh, look, i am! ;)
"To my outsider self, there is little centralization of vision, and therefore no compulsion to follow a central vision."
that's completely fair. as an "outsider self" you have no obligation to provide coherence in vision.
"Anyone who wants to profoundly alter the system has little choice but to shout, and earn mindshare, and play crowd politics. That's why I don't really blame Pulse or Lennart, or the distributions. It is a synergistic effect of how the community operates, rather than a conspiracy to hurt users with experimental software."
but it's the Lennarts, the Aarons, the $DISTROs of the world who define the community operations. it is precisely us who crafts this thing, together.
so for us to then hold up our hands and say that we can't do better because we're hostages to the runaway natur of our own systems .. that ludicrous.
imagine if Martin Luther King Jr or so many other such people had thought that way?! we are, as direct participants, able to shape and form that which we are a part of.
that is not theory, that is the fact of the matter as proven countless times in history by those who stood up and had the determination to see it through.
giving up is to be complicit with the ills of the system and therefore guilty of them.
as for kde4, we did a lot of structure creation, community consensus building .. we didn't need centralized vision, we employed a system of consensus building, idea sharing, valuing efforts over words, crystalizing process and inspiring each other. people on the outside perceived it as centralized vision when really it was a community of people learning to speak a similar language; that's a very different thing.
"because it is actually trying to posit a cohesive vision for the future desktop."
and we can do that at a much broader level, too.
those of us who are part of it need to just wake up and stop playing stupid games of coercive politicking that hurts everyone working on behalf of F/OSS.
and yeah, it's a big job. and yeah, it'll take a number of us to get it done. i'll continue to try and help in the KDE project as well as here and there as i can and encourage others to do the same.
It is true that I'm a little hypocritically cynical. And you're absolutely right, "things look bad" is no excuse to just give up on reforming community processes.
When I think of how inspired the free software developers are for the projects they nurture, I do feel a little less cynical, and wish them the best in finding a way to cooperate for the sake of the platform.
I did not mean that democracy rant as a knock against developers, by the by. Reading back I thought "Goodness, that's gonna be a mistake." But there was some point I wanted to express there, just needed less rude language.
@Jud: "I did not mean that democracy rant as a knock against developers"
honestly, i didn't take it as one. i do see your POV reflected in a lot of people's faces these days in the f/oss enthusiast community and it tells me that we are, as a group, generally failing to provide you something better and more hopeful to hang on to.
and thanks for sharing your thoughts on this, long as they were. i'm not particularly a fan of brevity myself ;)
To contribute to the off topic: I still don't know what's the user visible difference between dmix, aRts and PulseAudio.
The user-visible difference between PulseAudio and Arts,Esd and so on, the way I see it, is simple:
- A central volume control from which you can directly take care of all involved apps. This enables me to quickly mute firefox, while letting Amarok still go on, without taking it to the apps themselves.(Ever had a flash-applet make a sound and didn't know which of your 60+ open tabs is the one playing it?)
With the PulseAudio-manager you can even control audio-devices via network, enabling you to control your whole multimedia-network on the fly.
- On the developer-side there's still the fact that Alsa(and anything in the kernel) is not Api-stable, thus requiring constant maintenance to be up-to-date(Yeah, I know it's not THAT bad :D ). So in a perfect world PulseAudio would provide a clean, stable API to play sound on all modern Linux-systems, although they kind of messed that up to, and now everybody's stuck with a crazy mix of Alsa-compatibility-modes and a sound-server that just now gained the ability to switch audio sources on the fly.
Also, wasn't Phonon, like, providing the same thing, only without being insane?
@aaron: back on topic, are we going to see the fruits of your work with a better systray (and kmix already ported) in 4.3 or 4.4 timeframe?
Thanks for the clarification :)
Post a Comment