The people behind the software in Debian. (List of feeds).
If you prefer, there are also jwz-free and rms-free versions, as well as a lowvolume feed that omits both posters.
We recently had our Plasma release cycle planning meeting, and here is our list of goals for central Plasma technologies in 4.4 (in no particular order):
- Improve kiosk based lock down and deployment management: We are communicating with some large deployments in Europe about the process of migrating from KDE 3 to KDE 4 and how we can make KDE 4's desktop shell an even better experience than Kicker and KDesktop provided. We've started a wiki page here that we are working on with these downstream users. Expect a lot more to find its way there over the next few weeks and months as we continue to work out the needs and use cases with them.
- More
CowbellJavaScript: A full JavaScript AppletScriptEngine that provides access to all of Qt and KDE core libs and JavaScript DataEngines.
- Plasma Netbook: A Plasma shell optimized for the netbook use case of a small-ish screen, hardware accelerated video and online usage. It features no taskbar (relying on the "display windows" desktop effect instead), an integrated panel and window title bar, Plasma widgets and a full screen search and launch interface. Hopefully we'll be able to add a media interface as well.
- Media Center Components: A first release of media center
components for browsing, collecting and playing media in a full
screen Plasma containment. This will not replace Amarok, Dragon,
Kaffeine, etc. It's designed for casual full screen usage and will
also sport Plasma widget support. Oooh! Full screen widgets!
Essentially, we believe that a basic media center experience should
be easy for the home user to get at, which means it needs to be
integrated with the desktop shell and be readily available with it.
As a first release, it won't have tons of bells and whistles
(something we hope to eventually get by integrating this work with
existing media center projects in the future) but it should get us
on the right road.
- Remote Plasma: Send your data or your widgets to another computer or device or receive Plasma components on your device. No-configuration local area announcement of services over UPnP, working with all Plasma components without modification, integrated authentication and access control and extensible delivery mechanisms will allow us to share components around a table (e.g. at a meeting), control other systems (e.g. a media center) in the house or even run Plasma services on headless systems on the network. No other widget system out there has this, and even the web hasn't yet achieved this level of relocatability.
- Pluggable Containment Actions: Want to have Control+Alt+MiddleClick open up a list of running windows? Scroll wheel on a panel skip through desktops? This plugin based system for defining contextual actions for containments opens up all those possibilities as well as the more mundane but much wanted consistency between containments. Now Folder View Activities can have all the same options as the default Desktop Activity without any duplication of code. Best of all: you get the final say by selecting the plugins and the activation sequence for them if you wish in the integrated control panel.
- Widget Explorer: A more "Plasma" widget explorer that integrates better with the panel controller, looks hotter and is generally just more usable.
- Improved KWin Integration: We've been working on this in
4.3, and we'll try and take it to new levels with the KWin
developers. This includes moving some of the effect inside of
Plasma into KWin for greater performance, taking better advantage
of some of KWin's effects and seeing more Plasma based theming
options for KWin (such as window decorations). A good portion of
this work will be done by the KWin developers, but I figure it
makes sense on this list as well.
- Social Desktop and Geolocation Improvements: Building on our start with the Social Desktop features in Plasma in KDE 4.3, we will be adding more features to the existing widgets, adding new widgets where needed and using geolocation in more of our components. We are also looking at ways to improve the geolocation DataEngine itself, though no concrete for 4.4 plans have been committed to yet.
- Plasmate: The 0.1 release of the Plasmoid and DataEngine creator will follow with the KDE 4.4 release. Transparent revision control, live previews and minimal-clicks-to-get-to-work workflow will lower the bar considerably to making scripted Plasma components.
- KUIServer Resurection: KUIServer has received a facelift and an internal resurrection. Now jobs can talk to KUIServer and it updates Plasma for its job notifications. This means applications like Dolphin can now also consume that data without Plasma getting in they way and if Plasma should crash the jobs will still be there on restart.
- Notification Improvements: Notification summaries, queueing and logging, making the notifications area more robust against applications flooding it and more useful by keeping the latest information at your fingertips. We're also exploring the best way to show only the new stuff when it arrives, while letting you click through to the older stuff, too.
- Kinetic: Plasma in KDE 4.4 will be the first release to start using the new Qt animation and state machine framework.
- Plasma Desktop D-Bus Access: A full D-Bus service exposing the widgets, containments and more in your currently running Plasma desktop session.
- More KRunner: In 4.3 KRunner received a lot of interface, performance and stability love. Now we need to keep the runners coming. I started a Kopete chat runner the other day based on a request received on identi.ca.
- Plasmoid Updates: Working with the KNewStuff developers, we want to provide an easy way to check for updates to the Plasmoids you installed over the network as well as check the installed ones for integrity.
- Notification Item Goes Prime Time: With the new D-Bus based system tray protocol in place and under real-world usage in 4.3, we will be porting as many apps as we can get our hands on to it. A formal specification is being written which will be submitted for consideration at freedesktop.org and we hope to move the KNotificationItem class into libkdeui. Next to the ability to put Plasmoids in the system tray (and possibly elsewhere like the quick launcher), this is the single most exciting thing that's happened to the system tray since I've been following KDE. Finally we have a modern system tray / notification area with the ability to have multiple views on the same entries, have non-graphical representations of them, separate the entries into different groups in different widgets, integrate them with the taskbar, react to the internal state of the entries (e.g. for autohide) and theme them properly for the host desktop shell (icon theming, sizing, etc).
- Improved Documentation: Work on extended JavaScript Plasmoid tutorials is underway, and we're growing the general body of documentation around Plasma.
- New Configuration Dialogs: A revamp of the existing activity and wallpaper configuration as well as Plasma global settings is planned. Beauty and usability are the goals.
That probably seems like a lot, but most of the above items have already had significant work done on them and are currently in active development. We do have more plans, such as improving the Lion Mail Plasmoid and working on improved Akonadi integration, but the above sums up the big changes coming to the core components. The usual incremental improvements in other Plasmoids, performance and stability work can also be expected. (They just make crappy line items in a "OMG! What colour poniez are they making?!" list.)
There's so much more that's possible, too: a dock PanelContainment, improved pager usability, getting kdewebkit to a place that we can replace our use of QWebPage with KWebPage for Plasma::WebContent, a Plasmoid based on the Kickoff internals that shows a menu of just a certain sub-menu in the application menu hierarchy, .... there's lots of cool stuff just waiting for eager hands.
Maybe those hands belong to you? If so, come find us on irc.freenode.net in #plasma or on the plasma-devel at kde dot org mailing list. Either way, enjoy riding KDE 4.3 while we work away on KDE 4.4.
Growing up without any noticeable athletic skills, the nerd-jock duality was a pretty important part of my childhood. Nerds were the kids who carried calculators, wore glasses, dressed poorly, read books for fun, liked to be right in class, and had few friends. Jocks were athletic, well dressed, and popular, but probably stupid as well. Every person in my class could have listed, by name, the “nerds” and the “jocks” among our classmates, and if we’d transferred to a different school, we could have identified them on sight. It was, for me, and I suspect for many other kids like me, the primary sorting system for my peers (I guess there was also “goth” and “punk,” but we only had one of each at the entire school, so they didn’t count).
Both these terms are pejorative, but “nerd” was my stigma. At dinner one evening in 3rd grade, I explained to my parents that my friends and I were the nerds, and that we were proud of it. I still remember my father’s horrified reaction. “You’re not a nerd!” he said.
Of course as you get older you find that the labels that dominated your childhood don’t make any sense - but early childhood perspectives sometimes linger, lensing your experiences in ways you don’t notice.
So when I moved to Germany, and found myself having to explain this whole concept to bewildered friends and colleagues, I started to think about the nerd-jock duality a little deeper. What I realized is that, in Germany, engineering is not stigmatized in the same way that it is in the US. It is possible to self-identify as an engineer, even at a very early age, without being a nerd.
Germany is, in fact, a country of engineers. It has to be. Think about it: a cold, cloudy country ranked only 62nd in land mass, 14th in population, and yet in 2008 Germany was #1 in the world in exports by dollars! Yes, ahead of the US and ahead of China. How is that possible? Nerds! Oops, I mean engineers; engineers who design and build high-quality cars, engines, tools, machinery, scientific equipment. This is what happens when you don’t stigmatize engineers: you get a country full of engineers, self-identifying as engineers, growing up dreaming of being engineers.
But what kind of country do you get when you do stigmatize nerds? I’m afraid you get a country of importers. A country of investment bankers and “famous for being famous” celebrities and television “news” shows that are frighteningly reminiscent of some of my worst memories of grade school. A country of people who don’t make things.
My 20 year old sister informs me that the “nerd” thing has softened a bit in recent years, but maybe not always for the right reasons. Lots more people spend time with technological devices now, and to be part of the priesthood that creates them, tweaks them, hacks them is more impactful than it used to be.
But one of the reasons “nerd” isn’t such a dirty word now is because some nerds get rich. And that’s the wrong reason to appreciate nerds. Because only very few nerds will get rich, but we need lots of engineers to build our society.
The archetypes that you have as a country matter. They affect the kind of society you create. We have a lot of good archetypes in the US. We have the pioneer, the frontiersman, the individualist, the entrepreneur. Let’s keep those. But we can do without the whole nerd/jock thing. It isn’t helping.
And I think we’d do well to celebrate the engineer archetype again. I hear it was a big thing in the 50s. Can we bring it back?
The white breadboard in the picture is 4.3 centimeters along the wider side. One day in the not-too-distant future a Plasmoid will live on the above device and I will be able to access it using Bluetooth and then control the device from my Plasma desktop.
Rob L. and I put some more work into the wire protocol and looked further into what will be needed to integrate it with Rob Scheepmaker's remote Plasma work. Rob L. wrote some code for the device and we got a couple steps further.
I have no idea if this idea will ever see the light of day in a commercial product, but I also don't really care to be honest. It's a fun hack that I'm spending some of my free time on and it stretches Plasma out to a whole new area. Wheeee for having fun.
Obama has been strangely weak in opposing the coup in Honduras.
Honduras' government has declared an emergency and suspended basic human rights.
One of the articles I previously read said that the "unanimous" vote that named Micheletti president was made "unanimous" by excluding Cesar Ham's party. I would guess that this party is too small to have changed the outcome, but claiming it was "unanimous" based on exclusion of those who would have voted against is dishonest.
More lies by the coup-established rulers are explained here, including the phony resignation letter from Zelaya.
The right wing are condemning Zelaya for having an association with Chavez and say that he has promised to take control of Honduras for Chavez.
Those accusations seem absurd to me, but it seems that the ballots for the non-binding poll were printed in Venezuela after Honduran government agencies refused to do it.
It seems to me that Zelaya ought to have confronted that disobedience by replacing officials rather than by inviting foreign help. However, the mere fact of getting such help does not prove anything was wrong.
It doesn't prove the contrary either. Zelaya said, in exile. that if the constitution were changed to allow a president to be reelected, that would only apply to his successor, not to him. But this may not have been clear all along.
Pharma's phony 'gift' to Health Care Reform
How Hollywood systematically makes lousy movies.
I learned about another systematic cause in a book called "Save the Cat", whose purpose is to explain how to write scripts and sell them to Hollywood. However, without quite intending to, it also explains how the system demands stories that can be fully explained in a few words.
When the movie companies demand more power to control our computers, saying it is needed to keep them going, this is what they want to keep going.
Wild sheep on a Scottish island are evolving to smaller size, apparently due to warming climate.
After Israel seized the Gaza aid boat, the crew and escorts are now in prison in Israel. At least one may face long term imprisonment.
Israel has kept Cynthia McKinney and others from the Gaza aid boat in prison after they refused to sign a statement which would have put them in the wrong.
This is Bram's Cube, an idea I'm very fond of. It's very interesting to solve, since the middle layer and everything else can be thought of independently and solved on their own, but that scrambles the part you weren't thinking of.
The purge is complete
As of a week ago or so, HAL is no longer required by either NetworkManager or ModemManager. This helps streamline the hardware detection process and cleans up that code a lot. It was a fun ride and a lot of other great stuff came along with the udev port, because rewriting everything to use udev pretty much required cleaning up a bunch of other stuff. The udev parts were a lot easier than I thought they would be; what was complex was rewriting a ton of ModemManager to be more flexible and work better with multi-port modems on the one hand, and really stupid quirky hardware on the other.
For everyone in the US, have wonderful 4th of July. To everyone who’s not, have fun at the Desktop Summit. Had prior plans meaning I couldn’t attend, but I’m sure the Red Hat team will honor my absence by spreading the love and drinking all the liquor. Rock on, GNOME.
During the last weeks I've been spending some time to start a wireshark dissector plugin for GSM 12.21, which is the Organization and Maintenance protocol between BSC and BTS. Using this protocol, many aspects of a BTS are configured by the BSC.
I have already implemented the BSC side of 12.21 inside OpenBSC, and OpenBSC contains parsing code and debug logs about what is happening on this protocol. However, I think it is much better to remove most of that debug printing code from OpenBSC and move it into wireshark. Whoever needs per-message debugging, can start wireshark and look at the output - with the advantage of extensive filtering capabilities.
The protocol is quite complex and has many different messages with each their own set of attributes. So the current work is far from being complete, but it's already at a point where it is really useful.
I've put a specific focus on implementing the vendor-specific bits for ip.access, since those are hard to figure out and much more difficult to implement for anyone who hasn't spent as many weeks looking at hexdumps from their Abis-IP protocol as me. Parsing standard 12.21 messages is easy, just read the publicly-available spec and add wireshark code for it.
In case you're interested, the plugin is available from this path in the OpenBSC git tree
The distros tried to get packages out to testers to make sure the packages worked for launch day; fair enough. KDE also spent nearly eight days between the first tagging of rc1 and the eventually final release of it; that's too long. As far as I know, no users were informed of the situation and so took to testing the rc1 packages in good faith. They have done a great job uncovering bugs we've already fixed in the process.
I'd love to see our betas and rc's have much shorter tag-to-release cycles, even if developers come up with last minute fixes: just release another rc a day or two later. I'd rather have seen us put out rc1, rc2 and even rc3 if needed over those eight days.
I'd also love to see distros inform their users much more clearly what those pre-release packages are so that they test what they should be testing: that the packages install cleanly.
In the meantime, for all of our valued testers out there: if you download a beta or rc release and it hasn't yet been announced on dot.kde.org ... it's not the actual release. It's a pre-release. Hold off on reporting bugs until the announcement is up on dot.kde.org and you've updated your packages one more time to make sure you've got all the updates.
Cheers
In a recent comment, I wrote:
Oddly enough, our cat often does come when called, and is rather good at figuring out what humans want and doing it. A few days ago a photographer came out here to take snaps of me for an AP story on NedaNet and was quite startled when I asked the cat to turn around so her head would face the camera, and she did it.
Our cat’s behavior is not doglike servility, though. She pays careful attention to human hands because she associates them with being petted, and she’s a total friction slut. As a result, you can often fetch her, or get her to move, with hand gestures. I made one that directed her attention towards the photographer.
By an odd coincidence, my wife Cathy insisted less than an hour later that I should watch a video of the Moscow Cats Theater (I’d post a link, but I haven’t found that exact one from here). And we both noticed something; as the cats are walking tightropes and so forth, the human trainers are using encouraging, guiding gestures that seem…familiar to us. And, in fact, the cats often seem visually fixated on the trainers’ hands.
Wild! It looks very much as though Cathy and I have accidentally trained into our cat one of the same responses the Moscow Cats Theater people use to program their far more elaborate tricks.
I am reminded of something I heard a lion-tamer say once; training big cats is not about dominance, it cannot be; it’s about pleasure and reward. Nor does it seem irrelevant that the cats in the video looked happy. I think what we were seeing was not work to them, it was guided play - motivated not by fear of doing poorly but by love of their trainers.
Our cat behaves the same way; she walks towards a gesturing human hand because she loves getting attention from her humans and believes the hand will pet and cherish her. Everything in her experience confirms this. (On the rare occasions we have to discipline, we do it with a shout or a squirt bottle.)
More cat ethology: some time back, I examined the mystery of the purr. My commenters and I never arrived at an explanation of why the cat’s purr is so appealing to humans that I found entirely satisfactory. Now, science may have provided one.
It seems there’s a woman named Elizabeth von Muggenthaler (wonderful name, so redolent of mad science and gothic castles!) who has discovered that cats purr in a range of acoustic frequencies that are widely known in the medical literature to stimulate tissue healing, especially of bone and connective tissue.
Ms. Muggenthaler does not propose to junk the conventional account that cats purr to express sociability and/or contentment, but she suggests that cats purr as a form of self-healing as well, and has designed various clever experiments that appear to confirm this.
She may also have explained why humans enjoy the sound. Like purring itself, the healing effects of gentle vibrations in those particular frequency ranges have probably been significant in the mammalian line long enough for humans to inherit a mild instinctive tropism for them. I wouldn’t be at all surprised if the human ability to be come fond of certain varieties of repetitive mechanical noises has a similar ground.
DNA Lounge update, wherein the War on Fun is engaged.
You are hereby advised:
Thu, Jul 02: The Coathangers @ Hemlock Tavern Thu, Jul 02: Emilie Simon @ Cafe du Nord Fri, Jul 03: Stripmall Architecture @ Hotel Utah Thu, Jul 16: Girl in a Coma @ Bottom of the Hill Fri, Jul 17: Le Tigre @ Bottom of the Hill Wed, Jul 22: La Roux @ Cafe du Nord Sun, Aug 16: Jill Tracy & Nicki Jaine @ Cafe du Nord Thu, Aug 20: Stripmall Architecture @ Cafe du Nord Tue, Aug 25: The Prids @ Bottom of the Hill Thu, Oct 22: Dragonette @ 330 Ritch
Many others have weighed in on the matter since, and it seems there are huge numbers of comments on each of these blog entries. I haven't read the comments as I don't have time to do so today (I have a couple hours to close out some bugs I want to kill and then I have to dash out to the outskirts of the city for a farewell dinner) and I'm not sure I even want to open that Pandora's box, to be honest.
For those who are discussing it, here are some thoughts that rattle about in my head, in point form, that others may find useful in the discussion:
- This has nothing to do with Konqueror beyond "we'd like to use Konqueror, so we need a suitable rendering engine for it". The discussion is really about web rendering stacks.
- That we need to have this discussion says nothing negative about the KHTML developers, their efforts or those who use KHTML. The people working on KHTML enjoy doing so, have their reasons for doing so and do great work. They can and should work on KHTML for as long as they enjoy doing so.
- The discussion should remain centered on what application developers need and what our users require so as to make decisions that serve those ends properly.
- There are two contexts for web content: web browser (e.g. Konqueror) and application usage (we use web content in Plasma, throughout Kontact, in application intro screens, in some control panels, in educational apps, in ... a lot of places). These two contexts may not have the same answers. There is C++ API currently missing in QtWebKit that make it not a great option for some applications (though it seems Qt 4.6 is addressing a lot of this issue), but which is pretty well irrelevant to its use in Konqueror as a web browser. There are vice versa examples as well. So keep in mind that there is not, at least not right now, a "one size fits all" solution availalble to us and the discussion ought to reflect that. We need to pick the right answers given the specific questions.
- The reality is that some applications are already using WebKit, so this isn't particularly revolutionary.
- Equally real is that KHTML will be with us at least until KDE 5 and there will be users of KTHML for quite a while yet no matter what happens.
- QtWebKit is not perfect. It's moving forward nicely in Qt 4.6, but to be perfectly blunt: I am disappointed with its progress to date. I had hoped it would be much farther along than it is now. I see all kinds of cool demos for it, but it's mostly for embedded application and usage. We aren't testing it enough on the desktop and we aren't creating enough pressure to move it forward in those directions. Those responsible for QtWebKit would, imho, be wise to put more human resources on it as well.
- The biggest asset WebKit has going for it is broad usage and broad development by numerous entities. The web has become stupidly complex and is ever evolving; it needs a large developer base to keep up, and this is why WebKit works "better" than KHTML on today's "web 2.0". (As a related aside to the Gtk+ WebKit developers: naming your library libwebkit is not only ballsy it's downright ridiculous, divisive and offensive. It's a shameful decision.)
- Here's the most important point, and thus the one I'll end with: this discussion will not matter one little bit in the least unless people commit to a solution and write code for it. Words are great, but they are just words. It is the effort that turns those words into something that matters. You don't have to ask for permission to work on something, either. Just do it, where "it" in this case is the webkit part in playground/libs/webkitkde.
