Sonic 4

Sonic 4 has me in a froth. I am frothing.

If they could make a solitary boss room as epic as that of Lava Reef Act 2, but in HD, I could die happy. In fact it would be so awesome it would probably kill me.

Seriously, this crap be epic

Printer Applet and KStatusNotifierItem

In 30 minutes of hacking after lunch I came up with this:

The printer-applet has been ported to KStatusNotifierItem in all its glory. I like KStatusNotifierItem. Besides the obvious presentation improvements, I was even able to remove a few custom functions for hiding/restoring the main menu and the tray icon for free.  The less cruft, the better!

Unfortunately this is way too late for KDE 4.4. I probably would have tackled this earlier, except that the python bindings haven’t been in a working state this whole cycle, only starting to compile with 4.4 RC2.

I committed the patch to svn and only moments later realized I had made an i18n mistake. As long as you grab both revisions, the patch should be fairly safe to backport to distro packages. I’ve done a bit of testing to make sure nothing obvious broke, but it’s a new feature and as such may not be perfect. It’ll probably be OK since most distros aren’t releasing 4.4-based distros for another few months, which should be plenty of time to test. The Kubuntu packages for RC3 will have this patch, for the record.

Also in printer-applet trunkland, I did a few optimizations in regards to QStrings. (Using QLatin1String with QString.startsWith, using remove() rather than replace()-ing a char with an empty string, etc) Between switching to KStatusNotifierItem and this my unscientific testing shows that the printer-applet in 4.5 uses ~200 kilobytes less RAM than in 4.3.98. Not much considering it still takes up 19.1 MB of RAM on startup with my machine, but it’s still a bit better. It would be nice if somebody could port over the “don’t-start-the-gui-until-needed” code from the GTK+ printer-applet, as that would really help the situation a lot. Oh well, until either that or a C++ equivalent turn up, at least printer-applet integrates well with the systray in the meantime.

Edit: Include the fixes from r1084373 too, sorry ’bout that.

The Weather Wallpaper in KDE SC 4.4

Any avid followers of the weather wallpaper probably noticed that in KDE 4.3.80 the weather wallpaper configuration page sported an “Advanced…” button that opened up a dialog that looked something like this:

You may have also noticed, as attentive as you are, that the custom-wallpaper-for-different-weathers feature does not work.

The story behind that is that this summer right after trunk opened after KDE 4.3 I committed the initial code for that dialog and then went on a road trip with the family. I knew that the code had a few bugs in it, and it didn’t save the custom pairings at all, but figured I would get around to fixing it later. The trip was over in a week or two, but I found myself busy over the summer and fall with one thing or the other, and pretty soon it was KDE 4.4 beta time. Well, I wish I had gotten around to fixing it before KDE SC 4.3.80, but I didn’t and nothing can change that. The good news is that things should work reasonably better for KDE SC 4.4 beta 2.

The Good News ™

The bug where the custom wallpaper only changes in the wallpaper preview is still there, but your custom changes are saved and will take effect next time plasma-desktop is started. Sucks I know. That’s the one bug I really need to fix before KDE SC 4.4.0. But other than that things work much better, and the advanced config dialog even sets the weather condition combobox to the current weather condition. In KDE SC 4.4 beta2 the weather wallpaper will also have integration with the sexy new KNewStuff3 for getting custom wallpapers.

The Future

Unfortunately since I’ve procrastinated until after string freeze I’m not able to copy the advances that the regular “Image” wallpaper plugin has made in its config dialog. For KDE 4.5 I plan to scrap the advanced dialog entirely and smartly incorporate what was in the advanced dialog into the main dialog with some smarter layouting.

So, KDE SC 4.4 is going to rock, and SC 4.5 is going to rock even harder, though that shouldn’t surprise anybody.

P.S. Right before I posted I realized that I forgot to use “SC” in every instance of KDE, and had to go back and add it to all of them.

Kubuntu Notification Helper 0.4.85 (0.5 beta1)

I’m glad to be able to announce the release of Kubuntu Notification Helper 0.4.85, the first beta release for the 0.5 release! We would very much appreciate testing, though I must admit we don’t have anywhere for bug reports to go yet. It should enter Ubuntu soon enough, though, so we’ll be able to track bugs there in the quite near future.

For a general overview on what Kubuntu Notification Helper is, see my previous blog post. There have been new developments since then, though, which I will touch upon in this blog post. But first, let’s get to the release stuff.

Getting it

I have packages available for both Kubuntu 9.10 and Kubuntu 10.04 at my PPA. To get them, go to the “Settings” view of KPackageKit and hit “Edit Software Sources”. Go to the “Other Software” tab and click “Add”. Paste the following into the dialog:

ppa:echidnaman/ppa

Once you close the dialog, it will offer to update your package lists. Allow it to do so, and install the kubuntu-notification-helper package.

Using it

After installing it, you have two options to start using it. You can:

• Just reboot the computer

Or:

• kquitapp kded; sleep 2; kded4
• kquitapp knotify; sleep 2; knotify
• kbuildsycoca4
• kcmshell4 kcmkded
• On the bottom list of KDED modules, click “Notification Helper” and hit the “start” button.

It should now function just as Update Notifier KDE did, only better! (More efficient, more integrated with Plasma)

What’s new

Since my last blog, quite a bit has gone on development-wise. Primarily, Kubuntu Notification Helper now notifies of restricted package availability:

Clicking “Details” will bring up a dialog identical to the one in Kubuntu 9.04 and 9.10. With Kubuntu Notification Helper you can finally permanently ignore all restricted package notifications if you so choose. Oh, and before anybody asks, that’s the Oxywin Plasma theme, which I quite like.

On the subject of permanently ignoring things, we realized that, aside from editing configuration files, there was no way to get Kubuntu Notification Helper to watch/notify for permanently ignored things. To remedy this we added a child module to the “Notification” configuration module in System Settings:

Other than those two features, we have spent a fair amount of time making the code is as clean as it can be. We have all the features that we want for 0.5 done, so all we need now is a bunch of bug testing between now and April. Enjoy!

UDS Lucid – My Remote Participation Experience

I just wanted to give a shout-out to anybody who helped make remote participation for this cycle’s UDS possible. My experience participating in five or so sessions was very good. I could hear everybody loud and clear, and they could see my IRC messages. Compared to last year where you could barely hear anybody and IRC was virtually non-used, this is a very big improvement!

So, thanks for a good remote UDS experience those who made that happen! I hope to be able to participate in the next UDS in person.

On that note, let’s all make 10.04 rock!

Kubuntu Bug Policy for 10.04 on

I’m a bit late with this post. For some reason I couldn’t find the motivation to blog rather than do other FOSS stuff. But communication is important, so I will blog.

Starting with the Kubuntu 10.04 cycle (now), Kubuntu will be changing the way it handles KDE bugs in the Launchpad bug tracker. In the past we have tracked both packaging bugs as well as upstream bugs at Launchpad. Tracking upstream bugs gives the benefit of being able to follow upstream’s resolution of the bug more quickly and, hopefully, be able to provide a Stable Release Update (SRU) for the fix. However, at the present tracking upstream bugs at Launchpad does not make sense for Kubuntu for the following reasons:

We have too few bug triagers to effectively track or send on upstream all the upstream bugs that we receive. Many upstream bugs rot in Launchpad, never seeing the light of day until they are closed when the user stops responding. As a result upstream never sees this bug and never has a chance to fix it unless somebody else reports it to the directly.

At the present, we usually never SRU individual fixes, effectively negating the reason to track upstream bugs in the first place. This is because KDE has an awesome release policy where every month a bugfix point release is made. Perhaps in the future this could be useful for SRUing specific fixes to older releases (e.g. not the most previous stable release than the current) that normally would not receive the new KDE update. But until then we really do not have the developer manpower to do that…

Basically, it all boils down to an issue of scale. Do we have the manpower to track upstream bugs? If not, can we defer the use of Launchpad for upstream bugs until we have both the bug triaging and developer manpower to properly handle it?

The answer is that we are, as of now, going to be redirecting all current upstream bugs to bugs.kde.org. For 10.04 we will most likely disable apport-kde for crash detection for KDE apps (it was fairly buggy anyway) and switch back to using the fabulous Dr. Konqi from KDE. This will leave the Kubuntu bug tracker in a much cleaner state, where Kubuntu developers can see exactly what needs fixing in Kubuntu without wading through an ocean of upstream bugs.

This has been a public service announcement from Project Timelord. Project Timelord would also like to remind that contributing to Timelord is really no different than contributing to Kubuntu, so we invite you to join us!

Kubuntu Notification Helper

This is one of the first developing fruits that developed under the guidance of the Project Timelord roadmap. But before I talk about Kubuntu Notification Helper, I should give a little history about its predecessor, Update Notifier KDE.

Update Notifier KDE

One and a half years ago when work on Kubuntu 8.10 started, we found ourselves in need of a new update notifier. The new Adept didn’t have one yet, and the old Adept was incompatible with KDE4 due to the lack of a Konsole KPart in our kdebase packages. (Now at KDE4) So Riddell whipped up a simple PyKDE KApplication that would spawn KSystemTrayIcons when updates were available, upgrade information was available, apport crash notifications were available, or reboot notifications were available.

In Kubuntu 9.04 Update Notifier KDE gained the abilities to notify the user of installable nonfree software such as the Flash plugin and MP3 codecs. In Kubuntu 9.10 update notification was taken over by KPackageKit, but since KPackageKit only covered software update notification, Update Notifier KDE was kept around to do everything else it does.

It is right about now that I would like to talk about the Achilles heel of Update Notifier KDE, its RAM usage. This was worse when it actually notified of software updates, easily taking up 32 MB of RAM while checking for updates. But even now in Kubuntu 9.10, by my somewhat-unscientific benchmarks using KSysGuard (why hello there, seli), Update Notifier KDE still uses 10 MB of unshared RAM while doing nothing, waiting for things to happen. I believe, mainly, that this is Python overhead, demonstrating that Python’s niche is definitely not notification daemons. 10 MB is always too much RAM taken to do nothing.

Kubuntu Notification Helper

It was for the following reasons that Harald and I decided to start a C++ KDE Daemon-based rewrite of Update Notifier KDE:

• C++ would be much better on RAM usage.
• The old python script was sorta getting a bit messy
• It didn’t actually do update notification anymore, and we had to change the name anyway.

Before I continue on, I would like to emphasize that this is not a certainty for Kubuntu 10.04. While Kubuntu Notification Helper does do what it does better than Update Notifier KDE, it is also new. If it cannot meet the functionality that Update Notifier KDE currently offers then it will not replace Update Notifier KDE for 10.04.

That being said, it already does quite a bit of what Update Notifier KDE currently does. At the moment it does:

• Apport crash report notification
• Upgrade hook notification (e.g. telling you to restart Firefox)
• Reboot notification

It currently lacks the following features that Update Notifier KDE currently has:

• Codec installation notification
• Distribution upgrade notification (e.g. 9.04 -> 9.10 upgrade notification)

As I mentioned before, Kubuntu Notification Helper is a KDED module written in C++. Initially I did a quick port of the reboot and apport notification from Update Notifier KDE, making a simple C++ KApplication-based notifier that notified with your standards Plasma KNotifications. This alone used 5x less RAM than the current python script, so I got excited and moved from a KApplication to a KDED module, which saved even more RAM usage. Now at idle it only uses 0.3 MB of RAM, and only uses 1-2 MB or so when displaying a notification. (Except upgrade hooks… will get to that later) At idle, this is around a 50x improvement from update-notifier-kde, and at least a 5x improvement while actually doing things.

Around this time, Harald Sitter (apachelogger) came around with the idea of making a centralized Event class on which to base each of our things we wanted to notify. Instead of being functions in a declarative-script-type class, each Event is only created when needed. I must say that his design is superb, and it made the code base cleaner, more consistent and more efficient. Harald could probably wax on about the implementation details better than I can, so I’ll leave that up to him.

So, screenshot time. First off I will tackle Apport notification:

Now, I’m not a big fan of apport’s crash handler. Dr. Konqi ftw. But Apport still has its uses, for example reporting bugs for package upgrade failures. Even though there’s a good chance Apport crash detection will be turned of in 10.04, apport will still be around for things like package upgrade failures. Anyway, the UI is fairly straightforward here. Clicking “details” will launch the apport dialog, and ignore will dismiss the notification. “never show again” will free you from apport notifications permanently if you so desire. The current plan for “Ignore forever” is probably to make a config module where you can manage the notifications you want K-N-H to give. Perhaps it will be made a sub-module of the Notifications module in System Settings.

Next comes the reboot notification:

Not much different than what we currently have. Clicking reboot will bring up the standard KDE  dialog confirming that you really want to reboot. The Ignore buttons function as before. And yes, we will make the ignore texts consistent eventually.

Last is the upgrade hook notification:

It looks similar to the rest of the notifications. But we have to provide our own UI for presenting the notifications to the user, since there may be multiple notifications:

Here’s the second page, so that you can see it:

Mutliple hooks will show up paged as seen in the screenshots. The sidebar will go away (automagically thanks to KDE) when only one hook is available. This implementation is sub-optimal at best. Eventually it’d be nice to just make a KNotification for each upgrade hook. This is just the quickest way I could port the functionality over from Update Notifier KDE.

In fact, the whole hook parsing setup could use some love, as its somewhat inefficient and complicated. If there was a simple RFC822 parser in C++, I would gladly use it rather than my custom parser, which is quite RAM hungry. I should note that even though hook handling is RAM-hungry, it only uses 6 MB RAM, which still manages to only be 60% of what Update Notifier KDE uses at idle, which I find quite amusing. You don’t see upgrade hooks that often anyways, so it shouldn’t be a problem, especially since it is using the RAM to actually do something. Code first, optimize later, right? At the least it all works.

Conclusion

I sincerely hope we can implement codec and distribution upgrade notification in Kubuntu Notification Helper so that it can be included in 10.04. Less bloat is always good. If you know C++ (a bit of python knowledge wouldnt’ hurt) and would like to help us with this piece of software, feel free to jump in! You can find the code here, and all you need to do to get started is to do a bzr branch lp:kubuntu-notification-helper to check out the source.

I’m not the Doctor, but I play him on the Internet

Introduction

As you may have already seen, Project Timelord is out in the wild. While Kubuntu 9.10 is undeniably a decent release and undeniably better than previous releases, it is not an outstanding release. The potential to be the best KDE distribution in the world is there, but something is not quite right. For example, KDE translations are pretty much fixed, but our Kubuntu-developed often suffer from a lack of translators as well as a general inattentiveness to localization bugs, which is made worse by a lack of feedback from justifiably frustrated users. Kubuntu tools are written for KDE4, but perhaps stick out too much and don’t fit in with the system as well as they should. Our early KDE4 packages for Hardy left a bad reputation, and now any bug– KDE or Kubuntu’s fault– gives disgruntled and suffering users to brand Kubuntu as “just that buggy, second rate KDE distribution” on the internet. Kubuntu is good, but to break free of its past and at the same time become great, major changes will have to be made. What Kubuntu needs is a Doctor.

The Name

Hopefully, anyone from this generation or the previous has heard to the Doctor. The Doctor is a man with no name, the lone survivor of the Last Great Time War, and the last Timelord in existence. With the last of the TARDISes, he roams through time and space with his companions keeping the universe safe from perils both manmade and alien. Project Timelord was named that because:

• We thought it sounded good at the time
• Harald and I are both Doctor Who fans (Jonathan Riddell probably does too)
• Kubuntu needs repairing, and who better to fix something up than the Doctor?

What is Project Timelord About?

I really would recommend reading both the announcement as well as the complete Timelord specification, as they will do a much better job of explaining Project Timelord. They’d better do a good job too, since I spent a lot of time writing them. Basically Timelord is a roadmap of todo items, brainstormed by Kubuntu’s finest. Thought to maintaining the status quo was thrown to the wind, and we seriously took a look at what our biggest weaknesses or perceived weaknesses as a distribution are. The result is a list of solutions that may in some cases be radical change from the status quo. We will do whatever is necessary to make Kubuntu the best.

In essence, Project Timelord is taking a look at what we currently do and doing a sanity check on it. For example, Timelord asks:

- Do we have the resources to maintain translations in Launchpad?

Probably not at the moment, no. Launchpad translations is a solution for a problem we don’t have, and if we cannot maintain it without a massive amount of work or at the cost of people wanting to translate our Kubuntu-specific apps, then we should not use it.

Similarly:

- Do we have the resources to track bugs in KDE itself at Launchpad?

While tracking things at both places does have its benefit when done properly, it really cannot be done properly by two people. Until our bug team grows, the recommended course of action is to send upstream bugs upstream where the belong, lest upstream never sees them at all.

It is questions like these that Project Timelord attempts to answer. (Really, go read the spec for more details ) If we can follow the proposed roadmap, I am sure that Kubuntu will rock for Kubuntu 10.04 and beyond, eventually becoming the best Linux distribution possible.

But All of This Requires You

As a co-brainstormer of Project Timelord, I believe that if we follow Timelord’s solutions sincerely that Kubuntu will look into the heart of the TARDIS and become reborn! The best part about it is that you can help us make Kubuntu the best Debian/Ubuntu-based KDE distribution, nay, the best Linux distribution around! Feel free to hop onto IRC or fire a mail to the kubuntu-devel mailing list; we are looking for people of all talents! Whether you can triage bugs, write python or C++, help out other users on IRC, make great artwork or have any other skill, we look forward to you helping us making Kubuntu the best it can be!

 

P.S. I will actually probably blog in a bit about the first developing “fruits” of Project Timelord, kubuntu-notification-helper, soon. (A C++ replacement for update-notifier-kde)

New blog

I’ve moved to WordPress.com to see if that helps any with the major spam problem my old one had. This is more of a test to see if it works. (Or, rather, if I changed the Planet KDE and Planet Ubuntu config to work properly with my new one)

 

Um. On the subject of non-bloggy things, I did upgrade to the very early beginnings of 10.04. I’m going all the way crazy this time. I’m excited for 10.04, to say the least. :3

On the KDE front, hopefully I’ll find the time soon to fix up the weather wallpaper. (Meaning, “I hope I can find the time to re-set up my trunk install and then get down to coding)

I’ve heard that it’s broken in trunk, and I was meaning to give the code a loving kick in the drawers soon anyways.

Plimoth Plantation, Kubuntu; woo!

Plimoth

Unfortunately I missed all of the release hubbub for Kubuntu 9.10, which I usually enjoy very much.

Fortunately, I spent quality time with my family at Plimoth Plantation down in Massachusetts. (That’s how they spell it, to differentiate the settlement from the town) (This was a field trip for my younger sister’s class) It was really quite interesting, seeing how both the Native Americans and Settlers lived. The Native Americans in the Wampanoag village exhibit were dressed in traditional clothing, but did not role-play to the point where they didn’t speak any English or anything like that. This is so that we could converse with the exhibitors so that we could gain a fuller understanding of the culture back then.

The English Settlement exhibit was also very neat and authentic looking, though these actors did role-play, speaking the English dialect in use at the time. My weight (150 lbs) was put to use for holding a small log of wood down while the younger kids got to drive stakes and gluts in it to split it into fence railings with a hefty mallet. Very interesting stuff. I’m just glad they didn’t take the roleplaying too far and make stupid comments about our “strange words” and “strange clothing” that we as visitors had, and that a band of Burger King robbers did not take the settlement hostage. (First one to get the reference wins!) Very professional and authentic.

It would be at this point (or a few days ago, actually) where I customarily do a retrospect of the past cycle. Unfortunately I do not have any solid package upload numbers since there was no “Karmic Top Uploaders” page as their was in recent cycles. I think I can safely say that the number increased from last year, though it’s not all that important anyways.

I’m quite pleased with Kubuntu 9.10. KDE is awesome as usual, the graphics drivers have gotten better, Launchpad isn’t breaking translations as far as we know, and networking now works for most wireless cases and is overall better than Kubuntu 9.04. (If there have been Ubuntu-translator-inflicted mistranslations, please let us know. Hopefully big changes will be implemented for the future. All I can say for now is “the Doctor”.)

PackageKit is honestly for me a bit disappointing this cycle, though it is worlds better than what was released with 9.04. At least it works in general now, if it’s not a bit lite on features and is a bit wonky at times. It’s just one of those things where there’s not that good of a solution at the moment no matter how you look at it. (If anybody wants to step up and write a solid C++ apt-based package manager with nice search functionality, pleasepleaseplease step up )

Overall, in my quite possibly biased opinion, Kubuntu 9.10 is good. It takes the awesome work the KDE has done and adds compelling features to improve the experience. I’m quite proud of our new installer as well as the User Configuration utility integrated into System Settings. While I’m not too big of a fan of the Ayatana notification experiment, I think it will be interesting to see how it turns out. I am also glad that corporate politics did not disrupt the default KDE experience, leaving it as an opt-in dealie. I do think that GTK apps being able to have KDE notifications as a side effect of this work (which is enabled by default ) is a great win for Kubuntu as well.

Plans are being forumuated for 10.04, the next Long Term Support release, as I type this. I have great optimism for Kubuntu 10.04, and will be blogging about our plans hopefully in the coming week. (All I will say for the moment is “the Doctor” again, which happens to relate to a codename of something… suspense… In general I hope for our Kubuntu-specific tools to be given more polish as well as some optimization lovin’. General LTS-y things and such.

So, in conclusion, yay history, yay Kubuntu, and yay KDE!