wm161.net

Bubblemon in 4.3!

A few hours ago I moved Bubblemon out of kdereview and into kdeplasma-addons.

Keep an eye out when 4.3 ships. You’ll like it :)

Plasma speaks!

Last night I committed a quick patch to Plasma’s plasmaclock library that almost all plasma clocks use. It changes the configuration interface a little bit to add one neat feature: speaking the time.

Now, you can configure any plasma clock to speak the current time every Nth minute of the hour. I was inspired by a neat little Android app I found the other day for my G1 called “Talking Clock”, which speaks the time every hour. Very handy.

As part of changing the configuration interface, it renames the “Calendar” page to “General” and uses Applet::icon(). I also went in and changed the analog-clock and digital-clock plasmoids’ “General” pages to “Appearance”. Now there aren’t a whole mess of clock icons in the settings :)

The Future of Glovebox

The middle of last year, I started working on Glovebox, a rather ambitious project for a car computer environment.

One of the biggest choices I made was to write my own set of UI libraries on top of Qt to mirror the kind of integration that KDE has. This was mostly because I didn’t want to drag in the few hundred MB needed for Plasma.

Wow, that past me was an idiot. Lets all point and laugh.

Ever since Plasma got moved into kdelibs, I’ve been thinking on and off about building Glovebox on top of KDE. For some reason over the past few weeks I started thinking more seriously about it.

At any rate, I’ve decided to go ahead and do that. I’ve also thought about another good idea. I’ll allow Glovebox’s UI to run under an X server in addition to the original idea of using Qt Embedded’s framebuffer stuff.

So most of tonight will be spent hacking the build system and Launchpad into shape, followed by restructuring the page plugin system to use KParts.

So, yes, perhaps I was an idiot

So in my last post, I said this in reference to bubblemon:

While writing this, I found a few possible bugs in plasma. I say possible, because I’ve been known to be an idiot sometimes

Turns out using setAspectRatioMode(Plasma::Square) fixes it:

You’d think, however, that using KeepAspectRatio (as I previously was) would suffice. If I manually resize, plasma should keep my aspect ratio. I understand now why plasma shouldn’t keep the ratio constant in the panel, but the apidox doesn’t seem to explain that.

Anyways, I added two important (and two mundane) features to bubblemon this morning at some ungodly hour. Anti-aliasing, smooth value transitions, label scaling, and support for any ksysguard sensor. To get the last one, I added some code to the systemmonitor dataengine that supplies various metadata, such as maximum, minimum, translated name, and translated units. Now its a lot easier for anyone to get, say, the current total memory on the system without having to request mem/physical/free and mem/physical/used.

The label scaling is the other important feature. Quite simply, when the label is too big to fit in the sensor, the text gets word wrapped and the font keeps shrinking ’till it fits. If the text is too small for even a 1pt font to fit it in, it won’t even bother showing text. After all, text at that size is just impossible to read. IMHO, I think this makes bubblemon as complete as it can be.

Now I can go back to helping hack KPackageKit into a form resembling a release. And sleeping.

Hello, planet!

So, uh, hi there. I’m new to the planet.

To get things started, I’m Trever, a 20 year old CS student from the good ‘ole US of A, which may or may not be true depending on your opinion of the united states. Your call. Anyways, I’ve been hacking on KDE on and off since 2007ish. The most I did was make a few patches for Amarok and just go bug hunting. Oh, and coding a lot of PHP. Apparently I’ve grown out of my PHP phase and moved on to bigger things with C++ and python. I’m one of the two people (the other one is Daniel) who work on KPackageKit, the KDE frontend to PackageKit. KPackageKit was the big reason I started hacking on KDE for real. It has also been rumored that I help work on the KDE bits for PolicyKit in fits (this rumor was started by me).

Cool, now that bit is out of the way. Now for something completely different, and really neat. I call it “Bubblemon”:

You can find it in playground/base/plasma/applets/bubblemon.

I’ve had the CPU plotters provided by the system-monitor plasmoid bundle, but I thought they were too boring, hard to see current usage at a glance, and I couldn’t really shrink them small enough. I think bubblemon addresses those shortcomings. Bubblemon is a glass sphere that fills up with some kind of goop depending on what it is monitoring. The cool thing is, the more full it is, the more it boils. Yes thats right, this is a cool animated plasmoid. It is guaranteed to wow your friends^[1]. The hotter it gets, the faster it boils with more bubbles.

In addition to monitoring your CPU usage, you can also monitor your memory usage. Soon, I’ll be adding temperature monitoring once I rework some of the internals (its all about plugins, man).

While writing this, I found a few possible bugs in plasma. I say possible, because I’ve been known to be an idiot sometimes. For instance, there’s this:

Putting it in the panel doesn’t seem to respect the plasmoid’s aspect ratio. I’m not entirely sure why this might be happening, as the battery plasmoid doesn’t have this problem, and I used it as reference for most of the code. I also haven’t updated my kdelibs with kdesvn-build since a month ago, so I’m not sure if it is fixed or not. Another issue I found was the lack of a plasma API to handle my animation. Bubblemon is forced to create its own QTimer, which is then connected to a slot that moves the bubbles and calls for a repaint every 40 ms, giving a 25fps animation. This gives plasma an ungodly number of wakeups per second. Not entirely sure if that can be helped though. However the methods that actually move and draw the bubbles take up 50% of my CPU (10 of which is system), which is unacceptable even on this dual core 2Ghz thinkpad.

The good news though, is that when my laptop goes on battery power, Applet::shouldConserveResources() returns true and bubbles are no longer bothered with, dropping CPU usage down to about 3%. If there’s any C++ gurus around who can figure out what is being such a resource hog, you’d be doing something pretty awesome for me. I’ve ran it through valgrind a few times, and it seems like most of the work is spent blending textures together in Qt. Later this week I might try 4.5 to see if that fixes anything.

¹ Not an actual guarantee.

Python Plasmoid on TechBase

Most of this weekend I spend digging through some of the lightest documentation around, trying to figure out how to make a simple plasmoid in python. Took me over two days, but I finally got it done. I even wrote a tutorial on how I did it!

The fruits of my labor:

And of course, powerchart-pre0.1.plasmoid

Glovebox Widgets

Glovebox is still rolling around on my laptop. I managed to sit down today after a few weeks of on-and-off thinking of how to best solve my current problem: how to do widgets.

One idea was to hack the KDE bits out of Plasma and just stick it in there, but there’s a few problems with that:

• Near impossible to update libplasma
• I’d add kdelibs as a dependency, if I didn’t hack out the bits
• Would take forever
• Its a shameful, ugly hack.

Over time, I came to the conclusion that I won’t use plasma, but I’ll use it as a reference for some of the really great ideas it has.

Plasma’s main goal is for a slick looking desktop, be it for a PC, internet tablet, embedded device, or PDA. I’m sure someone from the plasma team would like to say that its great for my project, and I’d like to agree. I can’t really think of a good reason to not have it in, other than the fact that I don’t want kdelibs as a dependency. Perhaps I’m just bullish and falling for the Not-Invented-Here thinking.

If someone out there in kdeland can figure a way to jam plasma into Glovebox without requiring someone to install the whole kdelibs package, I’d like to hear that.

Anyways, I wrote my own little widget system. Its very simple for right now, as I don’t have any kind of theming in. Thats next I think.

Oh yeah, the obligatory screenshot:

Here you can see, what else, a clock. Its just a proof-of-concept clock though. I’m working on theming next.

The State of Glovebox

First, I’ll show off the logo for Glovebox:

Second, Glovebox development has stalled a little bit over the last few weeks due to college starting up again for me. So, I’ll just give a quick overview over whats changed since I first announced the project.

Gloveui

Much like KDE’s libraries, Gloveui is the name for the base library I forsee all Glovebox components using. This will allow for super easy theming and other bits of consistency. As of now though, it only has an implementation of the Freedesktop icon and sound theme naming specifications, along with GIcon and GNotify classes.

A GIcon has a simple constructor. You pass it the fd.o icon name, and it uses the QIcon methods to load up images. Icons are still drawn using the basic QIconEngineV2, so it doesn’t always draw the proper size. Thats coming soon though.

The GNotify is a rough outline for a much more broad system. I soon home to have something similar to the galago-project implementation of the fd.o notification specification, where information bubbles can pop up on the display somehow. But for now, GNotify only does one thing: plays fd.o-named sounds. Since it is static, you just call GNotify::global()->sound("desktop-login"); to play the startup sound. GNotify uses Qt’s Phonon classes to accomplish this with minimal effort.

Launchpad Improvements

Over on the right is the current view of the Launchpad main window. Nothing too exciting to look at, I know, but there is now a fully-functional GPS data engine! And on the map page, I’ve implemented two handy widgets: A compass and a signal chart. The two widgets are independent of Glovebox, so any other Qt developer is welcome to use them. The only issue with them right now is the size hints aren’t working properly.

Coming Soon

With a full school schedule (class and work from 9-6 on a good day), I don’t have a whole lot of free time. I try to hack on Glovebox when I get a chance, and I’ve got a quick list of things I’m working on from time to time:

• Text-to-speech (via festival or flite) as part of GNotify
• Implement a new QIconEngineV2 to draw icons properly
• Improve hiding of the page bar (current method is drag it over to collapse)
• Proper copyright headers
• A KDE-esque plugin pattern
• A port of Plasma

That last item is a bit troublesome to me. A main feature of my Launchpad is to show a dashboard with widgets for the home page. Idealy, I’d like to implement this using Plasma. Unfortunately, that means I’d have to add KDELibs as a requirement. Right now, my plan of attack is to strip out all the KDE-specific code and replace it with Glovebox code.

Its bothering me though that I seem to be duplicating the efforts of KDELibs just to import one (awesome) feature (set). With all the recent work on getting Plasma to work great for embedded devices, it seems like I should just bite the bullet and link in KDELibs. I feel that goes against my biggest design goal for Glovebox, in that it should be small as possible and depend on as few libraries as possible.

So, lazyweb, any input on this problem?

KDE4 is A-OK

Critics everywhere are saying it, KDE4.1 rocks.

However, some aren’t. Some, like Steven J. Vaughan-Nichols, are saying that “4.0″ must mean “100% complete”. In fact, he goes on to attack Aaron Seigo for not making it clear enough that 4.0 isn’t a user-ready release.

For those confused, here’s some quick background info. Long before KDE4 was first released, the powers that be decided that to prevent development stagnation, they had to push a release of KDE out to the world. That way, it would get some visibility, and everyone would know all the new technologies that were going to be in the complete KDE4 series. Technologies such as nepomuk, plasma, strigi, and kwin compositing. Those technologies weren’t going to be feature-complete as one would think a x.0 release would be, but they were going to simply showcase the building blocks that developers would be building on in the future. Aaron repeatedly said that even Plasma’s API wouldn’t be stable until KDE 4.1 was released. Even so, some users found that KDE4.0 was a usable desktop. More users are finding that 4.1’s beta release is almost on-par with KDE 3.5.

However, Steven is taking Aaron’s implications that 4.1 would be “the big one” word for word. 4.1 isn’t the big one, it is a big one. When comparing 4.0 to 4.1, you see a few huge differences, both in terms of stability and features. As Ars Technica writer Ryan Paul writes,

I have used both GNOME and KDE extensively over the years, but have been mostly committed to GNOME in recent times. When KDE 4.0 was first released, I was extremely skeptical about Plasma. I saw a lot of innovation under the surface, but didn’t see anything at all to impress me in the parts that were visible to the end user. The work that has been done in the time since the 4.0 release is very compelling and has completely convinced me that the strength of Plasma’s underlying architecture can be translated into very real and tangible improvements to the end user experience.

The critics are wrong: KDE doesn’t need a fork – Ryan Paul

Ryan is right. KDE4 wasn’t meant to be like Vista, where you first turn it on and are supposed to get the “wow”. Even Steven himself admits that Microsoft doesn’t get their releases right. If a huge corporation with some of the best programmers in the world can’t push a finished product out the door for the big 1.0 release, why should open source developers be criticized for not getting it finished when everyone else wants it? Open source has a totally different view for the importance of releases. Open source depends on fresh developers and insight to stay alive. Microsoft depends on people buying their products. When the money goes low, Microsoft needs to scramble to push out a new product, regardless of how complete it is. Once its out there, they can still keep tacking on new features, which is why Vista’s SP1 is in the pipeline.

As for open source, when the developers think they have reached a certain point where they think others can start building on their work, they push it out to the public. New ideas come in, and get put into later releases. Its the same thing, really. Just a different currency.

The content of wm161.net by Trever Fischer is licensed under a Creative Commons Attribution 3.0 United States License unless noted otherwise.
See http://wm161.net/copyright for more details.