Hello guys and girls!

I always felt excited about Qt for S60 port, so I decided to give it a try.

And now I’m excited to see how KLines are running smoothly on my Nokia 5800
All animations are working, you can see svg theme being used.

Here’s a photo of the device with KLines running:

After I set up all needed tools and SDKs, porting itself was not very complex (mostly commenting out code, yeah). Of course the major pain was that I had to do all this on Windows – I’ve lost my Windows development habits long ago and don’t feel like I want them back

I thought about recording some live video, but my camera is too lamish for that

For those of you who are interested in trying the ported version on their 5800/n97 devices, here’s the sisx file:
http://www.dpimka.org/files/klines_s60_gcce_urel.sisx

NOTE: You’ll need a qt symbian port libs to be installed on your phone to run it.
Take them here:
http://pepper.troll.no/s60prereleases/demos/qt_libs_armv5_udeb_50.sisx
More info here:
http://pepper.troll.no/s60prereleases/

NOTE1: I didn’t test it much. I didn’t test it to run on some phone other then mine. It won’t run on symbian 3.x phones. It may crash, it may … well, no warranities

Hello!

Recently I’ve added a few things to klipper and I thought some of you might be interested to know about them. As for me I’d like you to test this and to report me any bugs you might find

Basically I’ve added two things. First: now when you copy some file path to Klipper, it can automatically determine a list of apps that can handle this filetype. Here are some examples of action menus it will produce:

Klipper action menus

So, now user has no need to add a lot of custom actions for a basic file types

Second, i’ve added a dialog which allows you to edit action properties or to add a new action. It looks like this:

"Action Properties" dialog

This dialog pops up when you click on “Add Action” or “Edit Action” in the “Actions” config page:

"Actions" configuration page

That’s all folks!

I decided to post a little update on the state of Notify plasmoid which currently resides in playground (it is planned to move it to 4.2’s kdebase once 4.1 is out).
Well, I can say that I already use it on a daily basis since quite some time ago and it looks stable from crash-free POV

After Riccardo (ruphy) provided me with great mockup and further feedback on how it should behave, I started to work.
Actually, a new look was implemented rather quick and later I did only some minor things + code reshuffling from time to time.
I just didn’t blog (for some unknown reason )

Currently the applet evolved into something you can see below:

Details:
- Now it sits in panel as an icon and shows notifications in a popup as they arrive (it still can be added to desktop – it’ll look like what you see in a popup)
- Notifications from one application are grouped. Notifications in a group can be switched with arrows (soon: this will be animated too)

Issues (some of known ones) – so you don’t keep spamming me by reiterating over them
- Layouting of action buttons (like “Chat” on a screenshot) looks screwed – too close to the text, too little space for the text. To be improved.
- Perhaps other visual layout changes pending.
- Action buttons visual look is WIP. It’s actually a stub – i expect them to be drawn more nicely.
- You must have noticed ugly whitish corner edges around the popup. I’m having issues with setting proper mask for the widget that actively resizes itself – to be investigated.
- Whole applet doesn’t react to plasma theme changes and it currently respects only one theme – oxygen That means, I develop it with oxygen theme being set in plasma and didn’t even take a look on other themes. yet.
- Perhaps something else I forgot.

So as you can see most of the issues are on visual side. Functionality wise – it works. Notifications are displayed, actions are triggered
Well, visual side is a very important one. That’s what will be my main focus for now.

I’d be grateful for any testing of this applet – if you find any crashes or some other bugs, please ping me on irc (dimsuz) or mail me at: <irc_nick>@gmail.com

P.S. To ehamberg: wrote this using kate vi mode

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!

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?

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