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 :P) 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.