Plasmoiding notifications and notificating plasmoids

Ok, I finally got to blog about the stuff I was doing lately

As I wasn’t quite satisfied with the current visual representation on KDE notifications (KNotify uses KPassivePopup ATM), I decided to try to improve them. Also, hearing all the buzz about plasma I was interested to see how it works and to play with it. And so I went to #plasma, asking for advice on how would it best to proceed with giving more cutie look to KDE notifications
Aaron immediately suggested me a nice way to go, explained me some details, pointed to the existance of galago spec - so thanks, Aaron!

I think I’ll start my short description of what have been done with a screenshot:

What you can see above is the very beginnings of the Notify plasmoid - which is capable of showing notifications. It is by no means finished, but it already supports clicking on that “action links” so you’re able to open a new chat :). Also as you can see on second notification - the applet supports showing “timing out” state of notifications - there’s an animated circle that gets sliced as notification’s timeout expires.

Now about how this is works:
I developed a Plasma DataEngine which implements (to some extent) a Galago project’s Desktop Notifications DBus interface. And also I patched KNotify’s NotifyByPopup plugin to forward notifications to this DBus interface when it exists and to fallback to passive popups if DBus interface doesn’t exist. This was what aseigo suggested and it works fine. So here’s a workflow on how things might work on a someone’s system:

- KDE session is started, bringing up KNotify
- KNotify searches for org.kde.Notifications DBus interface, doesn’t find one, so it uses passive popups
- User adds a Notify plasmoid to desktop: plasmoid instanciates its DataEngine which makes org.kde.Notifications appear on a session bus
- KNotify notices this and starts to forward its popups to org.kde.Notifications and stops showing passive popups
- Notify applet reacts on data changes in DataEngine and provides visualizations for coming notifications
- If user clicks on some action in notification in plasmoid, the DBus signal is emitted - KNotify reacts on it by performing assosiated action
- User removes a Notify plasmoid: DataEngine gets destroyed, org.kde.Notifications gets unregistered from session bus.
- KNotify notices this and starts showing passive popups as usual

Nice, isn’t it?
Even more: after patching KNotify, it will be able to use *any* implementation of Galago spec, not necessarily this plasma one.
And therefore notifications might be shown using a native user environment.

So as basic things of DBus interface are now implemented, next will come improvements on visual side - plasma artists will eventually provide me with an applet mockup, so I can make it more good looking and behaving
Also in #plasma we discussed some ideas about making it an extender in future (Hi, pinda!)

I’m also thinking about merging my KNotify improvements back in trunk eventually - they’re not very obtrusive as they simply add a couple of new methods to NotifyByPopup plugin.
And KNotify continues to work as it does now, unless DBus interface org.kde.Notifications will be found.
I wonder when it will be best to do this merge - as I consider KNotify part mostly complete (of course I’ll post a patch for review on k-c-d prior to merging)

Last but not least, thanks to Thiago and all who worked on QtDBus - it proved to be simple enough to learn and use even for such a newbie as me, who wasn’t experienced with DBus at all
Ah, and of course, techbase tutorials are very nice - thanks for them too!

KDE3 and KDE4 bugs

It still isn’t fully clear to me what to do with bugs of KDE apps that have a KDE4 version.

Let’s take any game from kdegames for example.

KAtomic has some bugs from its kde3 times. Let’s take the bugs that aren’t applicable or fixed in kde4 version of the game.
What to do with them?

The thing that confuses me is that as someone said on kde-core-devel “KDE3 is not disapearring anywhere”.

So should I close these bugs saying they’re fixed in KDE4? But then KDE3 version of app will still contain this bug. And I must say I don’t feel like fixing kde3 bugs. For the following reasons:

- I don’t have kde3 development environment
- I don’t have motivation on fixing kde3 bugs
- I consider myself as a maintainer of kde4 version of an app, not kde3 one

Of course I can just ignore them and wait for someone who will be willing to fix them, but these bugs are still assigned to me and I’m supposed to be the person who deals with them.

And they show up in bugzilla queries

I guess the final question is this:
Should KDE4 versions of kde apps be considered like their next versions, or like absolutely separate ones?

Any thoughts on this?

Feeling like KBugBuster

Hello, Planet KDE!

I decided to start a blog I can write to when I have programming-related-blog-writing mood

I hope my English is mature enough for you to understand it at least roughly.

Actually it is already since some days ago I want to write about my work on kbugbuster.

It began with a feeling When I heard someone mentioning Deskzilla (that’s a proprietary bugzilla client), I thought about kbugbuster. I knew it was in a not-very-good shape. Suddenly I feeled like resurrecting it. I wasn’t sure if I’ll have time for that though. But in one of the weekends it happend - I created a branch in kde repository and started to hack.

And now I’m continuing to hack on it as I happen to have free minute and /dev/hands demanding action

At first I wanted to just bring it to shape, with possibly some code restructuring and adding some features that’ll naturally emerge.
All my previous contacts with existing KDE apps (written by someone else) - namely katomic, klines, kmines, kreversi - ended up being a major rewrite. I thought I can do different with kbugbuster.

No luck After two days of hacking I suddenly understood that I’m missatisfied with existing API and code to a degree where I end up “restructuring” so much that I put a lot of “TODO remove this, do another way”. So I just started all over I didn’t throw away an old code - to keep it for reference.

And this rewrite has a great influence on my kde/qt learning curve - I started to learn Qt model/view framework, I learned how to use KIO (never tried it in action before - kudos to its devs - KIO rocks!)

So. The summary of current state of things:

1. I wrote a “backend” stuff which is currently able to perform basic queries and do very basic bug parsing (only ID and Summary are extracted ATM). Queries are asynchronous (kio), parsing is synchronous - but this *should* change.
2. GUI stuff - sidebar treeview/model and bug list/model. Sidebar already supports adding items with any query attached to them. This can be viewed like bugzilla’s “saved searches” I guess.

This all currently operates in online-only mode.
Actually I wanted to ask you - what do you think about kbugbuster having an offline mode?
How do you see it?
Should it do it like Deskzilla does - syncing to bugzilla and offering complete offline browsing and working with bugs?
Should it behave like an old kbugbuster did - just cache any retrieved info, but not the whole picture?

Is it needed at all?

Any other thoughts about kbugbuster in general (and in detail) are welcome

Thanks to all who read until here, this was kind of lengthy post - it’s difficult to keep first posts short

P.S. No screenshots for now - they’re boring Partly broken GUI, sidebar with servers and products + bug list with several items in “ID:SUMMARY” form - that’s all it currently has