Every year Red Hat Czech offers a list of topics for bachelor and diploma theses to students from local universities. The topics are usually suggested and posted by Red Hat employees who then work with the students as technical consultants and mentors.

We see this as a good opportunity for students to learn about open source software, communities and collaboration and for us to find potential future employees :-) (so there's a great motivation too). We want students not to see their diploma or bachelor thesis as some boring obligation, but rather a "fun" way to learn new things, meet people and gain experience. And last but not least they are potential contributors to the projects they are involved in.

This year I managed to get several students I'm mentoring to pick a topic related to KDE.  Although all projects are somehow related to KDE Telepathy, it's a good start ;-)

Today I want to introduce work of first two students, Stanislav Láznička and Artur Dębski.

Makneto++

Stanislav Láznička is doing his bachelor thesis on Brno University of Technology. His topic is "Shared Board - Makneto", more specifically, his task is to port Makneto to Telepathy. Makneto is a whiteboard-sharing application for KDE, similar to KWhiteboard. It has been written some time ago as a diploma thesis. Since then several students have based their theses on this project (not all of them successfully though). Stanislav is now researching how to use the Telepathy framework and preparing to start the actual port soon. If you are interested in further progress, follow his blog and his git repo on bitbucket.

KTp Active

Artur Dębski (IRC: mentero), a student from Silesian University of Technology in Poland. His topic is "Touch interface for KDE Telepathy". Yes, hang on to your hat, we are going to have a totally awesome Plasma Active application for Instant Messaging. Artur has written an extensive blogpost about his work together with some mockups. You can checkout the existing code from here, there's already a demo app to play with!

What is your excuse for still using Kopete instead of KDE Telepathy? Oh, you can't live without your old conversation logs? Not a problem anymore!

KDE Telepathy is now able to import your AIM, MSN, ICQ, Yahoo, Jabber or GaduGadu logs from Kopete into Telepathy logger.

When you add a new account in the Accounts KCM, we will convert the new account ID into Kopete account ID and check, whether there are any logs in Kopete folder for this account. And if there are, we ask you whether you want to import them or not.

That's nice, right? But what about our current users, who just silently weep, longing for their old Kopete logs? Well, we thought about them, too! After starting the KDE IM Log Viewer, you will be prompted with initial logs import dialog. The dialog will appear only once. Whether you click "Import Logs" or "Cancel", we won't bother you with this never again. Currently I'm considering adding a main menu to the log viewer, which would contain an action to invoke this dialog again, in case you accidentally click "Cancel" for instance.

When you are removing an existing account from KDE Telepathy, you are prompted the "Are you sure you want to remove the account?" dialog. As a bonus, I have enriched it by a "Remove conversations logs" checkbox. Guess what will happen if you check it ;)

All these features will be available in KDE Telepathy 0.6.

And as usually, we are still looking for new contributors! There are some junior jobs in the bugzilla, which are a perfect start for newcomers. If you would need any help with fixing these bugs or wishes, just come talk to us on #kde-telepathy IRC channel or mailing lists.

Earn your eternal glory by fixing KTp bugs!

As some of you might have noticed, display management in KDE is not really something we could be proud of. It does not work as expected, it lacks some features and it's not really maintained. Time to change it, don't you think? :-)

The effort was initiated by Alex Fiestas (who is too busy to making KDE rock, so the blog post is up to me :-)). Alex has written the libkscreen library that provides information about available/connected/enabled outputs and notifications about their changes. He also intends to write a KDED daemon that would listen for these events and depending on connected monitors (every monitor can be uniquely identified by it's EDID) it would load specific configuration. For example, docking your notebook into a docking station at work would automatically turn on a second monitor and place it left of the notebook screen (or whatever you configure the first time you do it). Undocking the notebook and connecting a data projector in a meeting room would automatically set clone mode etc. etc.

This also requires a new UI in System Settings which is the part I'm working on.

It's written in QML and allows you to configure your displays by dragging them around rather then configuring them through combo boxes. Picture is worth a thousand words, and when it's a moving picture, well.....

Download OGV (1.8 MB) (in real time the animations are faster and smoother of course)

The best part of all this is that users won't be exposed to the KCM very often, because connecting an already-known monitor will configure it and place it automatically depending on the last configuration. Connecting a previously unknown output should pop up a simple window/dialog where user can quickly select whether the display should be left/right/clone of the active screen or open the KCM and perform more advanced configuration.

(Note: this is just a preview, we will have the icons made by someone sane)

Right now I'm abusing the krandrtray icon for the applet. It does not provide any rich features like krandrtray though, it only has a context menu with a single action to start the KCM. This should be enough because unlike current krandr-based display configuration there most things will work automagically.

And of course we will take care of displaying these dialogs and windows on the correct screen (that is the one that is connected and enabled) :-)

Finally, we want to use KWin scripting engine to display a black overlay over the entire desktop when changing display configuration in order to hide Plasma flickering and resizing from users and make it look like a smooth transition.

Hopefully I didn't miss anything :)

On Akademy I made a few patches for KDE Telepathy text-ui and logviewer. I continued even after Akademy, and David though it would be a good idea to make a maintainer of the KDE Telepathy LogViewer (thank you David! :) ). As a new maintainer I decided to kill all bugs, implement all feature requests and add a few of my own improvements to make the LogViewer rock.

So let's see how the LogViewer will look like in KTp 0.5 :-)

Nicknames and Accounts

The logviewer tries to retrieve real names (or nicknames) of the contacts, so that you can easily identify the person (and you don't have to remember who john123456789@gmail.com is). Unfortunately the names can be obtained only when you are online. When you account is disconnected, you will just see the ugly usernames. Also the list was converted into a tree, where contacts are grouped by your accounts.  You can filter the contacts either by their username of display name, too.

Plan is to have the same (similar) view as in Contact List (with fancy look and avatars).

 Navigating between Conversations

Usually you only remember the contact in whose logs to read, but you don't remember whether you should be looking to logs from yesterday, the day before or last week. Searching for valid dates in the date picker is not always comfortable. So logviewer now automatically inserts a links to previous and next  conversations to the beginning and end of each log to make jumping between them easier.

Global Search

If your memory is as bad as mine, you usually just remember a single word or term, but you have no idea who and when sent you it. Then use global search! The contacts view is filtered to contain only contacts that have at least one conversation with matching terms. Only matching conversations are displayed in the date picker and the searched term is highlighted in the message view so that you can spot it more easily.

Future?

I have some cool plans for future, some of them will make it to 0.5, some will have to wait. Here's what you can be looking forward to:

- file transfer logging - Alin suggested that file transfers are part of conversation history and thus information about it should be stored in the logs as well., including link to the downloaded file. I agree and if I find out how to do it, I'll add it to the logviewer :-)

-  better date picker - searching for conversation dates in the date picker can be quite painful if you don't remember the exact date or when you chat with some person only rarely, so I'd like to introduce some better UI for listing past conversations (maybe just a list of dates...)

- that's all I can remember right now, but there will be more. I  have some ideas for the text-ui as well, so stay tuned ;-)

Do you have any ideas, suggestions, bug reports? Express your wishes in Bugzilla!

This semester I attended Advanced Topics of Linux Administration course on my university. To successfully complete the course, one must pass an exam, have a presentation and write an article on a related topic. I had a presentation about libvirt and decided to write an introduction into using libvirt's API (the article has been published (in English) on Czech Linux portal ABCLinuxu.cz).

As an example, I have written a Plasma Applet in QML (yay, my first QML thingie!) and a Plasma DataEngine that serves data about QEMU/KVM virtual machines running under local libvirtd.

On the applet you can watch state of all virtual machines, you can boot/pause/resume/shutdown and reboot them and configure soft and hard memory limits and amount of virtual CPUs allocated to each machine.

Pictures!

I must admit that I was always a bit skeptical about QML, but my two previous encounters with QML made me really curious about it and writing this applet was really painfun and it taught me a lot about QML.

The big advantage of the DataEngine is that it's not constantly polling libvirt for changes, but it rather utilizes it's events API.

Wanna try? :-) There's a tarball here and git repo here: git://anongit.kde.org/scratch/dvratil/plasma-virt-monitor

It was fun to hack and I plan to give it some more love, possibly after Akademy.

PS: Akademy - anyone flying on Friday at 08:10 from Vienna :-) ?

This is just a short note mostly for packagers and other developers using LibKGoogle (if there are any). Due to possible violation of Google trademark, the LibKGoogle library has been renamed to LibKGAPI. Thanks to Clifford Hansen for inventing such a nice name :)

Also the license has been changed and the project is now under GPLv2+ instead of GPLv3+.

The entire API is now encapsulated in KGAPI namespace instead of KGoogle and headers were moved to %prefix%/include/libkgapi.

All these changes are now reflected in LibKGAPI 0.4.0 release, which does not contain any other improvements or fixes. I decided to go directly to 0.4 instead of continuing the 0.3 series, as I consider this a big and important change.

The Akonadi resources for Google services in kdepim-runtime will depend on LibKGAPI 0.4.0, the patch has been already submitted for review.

The git repository is still called libkgoogle, it will be renamed when it's moved to KDE extragear (or somewhere else). Stable branch is LibKGAPI/0.4.

Tarball release: libkgapi-0.4.0.tar.bz2 (will be available on ftp.kde.org soon)

Thanks and sorry for any inconvenience.

Cheers

Hi! Nearly four weeks after the 0.3 release of Akonadi resources for Google there's a new version with just a few, but important bug fixes and improvements.

UPDATE: In order to use the Google resources, you either need KDE 4.9 (which the resources are part of), or you need to install LibKGAPI 0.4.1 (or newer) and Akonadi resources from git://anongit.kde.org/scratch/dvratil/akonadi-google-resources. See this discussion for details.

Fixed bugs and crashes:

• Bug #296541 - Uncought exception in signal handler in Contacts resource
• Bug #297824 - Uncought exception in signal handler in Calendar resource
• Bug #297548 - Crash at akonadi start after having added a new contact
•  resource
• Bug #298054 - Can't build libkgoogle with KCal
• Bug #298518 - Unable to edit newly created events
• Bug #298519 - Deleting events incorrectly reports an error

The first two bugs were especially tricky as I couldn't reproduce them, but many  users were affected by ugly and repeating crashes. But now the "Google experience" is much much better :).

Big thanks go to Alex Fiestas who has contributed various improvements to libkgoogle to better work with 3rd party apps (so now we can be looking forward to his web-accounts wizard :) ).

Sources: akonadi-google-0.3.1.tar.gz (MD5:  fed8d9082547835ab916edd219831cf6)

Bye!

PS: I found this on Akademy wiki, so:

After many months of "I will release it next week" I finally released libkgoogle 0.3 and new version of Akonadi resources for Google this week.

So, what's new? I managed to implement everything I described in this post back in November. That's support for multiple Google accounts, and merging the tasks resource into the calendar resource (so now it's called "Calendar and Tasks resource"). The calendar now properly supports events recurrence and partially exceptions in recurrent events (there's still some work to be done). The contacts resource now splits your contacts to "My Contacts" and "Others" groups. I hoped to fully support contact groups, the code was even in place, but I've run to some problems how to store it in Akonadi and unfortunately KAddressBook is not "compatible" with the Google's concept of contact groups, so I decided to stick with the two elementary groups and hopefully I'll get to this later (maybe some PIM dev could help me on Akademy? ;) )

If you run to any problems or bugs, please report them to the libkgoogle product in bugzilla.

Finally, I'd like to thank to Jan Grulich and Vojtěch Zeisek for putting their contacts and events at risk to test the pre-release versions and provided valuable feedback.

Sources

(Updated tarball!) akonadi-google-0.3.tar.gz (md5: 8c5c1e015068bea90bf25dd7858dc913)

If you want to follow the most recent development, you can use sources from the master branch.

Have a nice day!

Yesterday I have switched from Kopete to KDE Telepathy. At first I only wanted to see what's new, but I was quite impressed and I didn't see any problem that would keep me from using KDE Telepathy instead of Kopete. Except for one -  a contact runner. I'm an incredibly lazy creature and instead of having to remember various shortcuts or even touching mouse, I rather use KRunner for nearly everything, including starting chat with my IM contacts.

In the true spirit of open source, instead of whining about a missing feature I decided to take an action and write the plugin myself :)

Same as with Kopete Contacts runner, just by typing name of your contact will display matching contacts in KRunner. If you have one contact in multiple accounts, it will display the contact multiple times, with name of the account as well.

The results are sorted by presence, e.g. if a person is online on Jabber, but offline on GTalk, the Jabber contact will be listed first.

If the contact has capabilities for audio or video call, file transfer or desktop sharing, you will see multiple buttons. By default, just by hitting Enter on the selected contact will start text chat, but by clicking on one of the buttons you can start the respective action. If the other side does not have some capability, it's button will not be displayed.

If you want to explicitly start for example an audio call, typing "audiocall John" will list all contacts named John capable of audio call and clicking on it or hitting Enter will start an audio call immediately. Similarly there are commands "videcall", "sendfile" and "sharedesktop" for respective actions.

This last feature is untested though, because none of my contacts seem to use KDE Telepathy or have any capability other then text chat :D

Here is some artificially made screen shot :)

 (Ignore the KSnapshot icon, I had already removed all the code to generate this preview when I noticed it :D )

You can get sources from my scratch repo on KDE git:

git://anongit.kde.org/scratch/dvratil/ktp-contact-runner.git
git://anongit.kde.org/ktp-contact-runner.git

And finally, big thanks to all our telepathic guys for their great work on the framework :) Keep it up!

Bye

I've made a big progress with the upcoming libkgoogle 0.3 last weekend on the Fedora KDE SIG meetings which took place in Brno. I then decided to take some rest from all this Google things and wanted to relax by working on something else. But then I remembered that some time ago I experimentally implemented the Google Reader API and...well, see for yourself.

Originally I wanted to implement my own caching mechanism for the feeds, but I soon realized that I would be just wasting my time when there already is something as cool as  Akonadi.

I have written a simple Akonadi serializer for the data (took me about 20 minutes) and an Akonadi resource (that took me about 40 minutes to write). Finally I begun to write the client.

The client itself is very simple, it essentially only fetches list of streams (for those unfamiliar with Google's terminology, stream == RSS feed) and their content from Google Reader and is able to update 'read' flag of one or more items. You can't add or remove streams (maybe later).

Note: Do not try to "mark all as read" if you have too many unread items. The resource is sending a HTTP request for every single item (will be fix later, maybe...).

But hey, what's the difference between reading your feeds in a browser window or in a silly desktop client. To increase the level of (my) awesomeness I've made a Kontact plugin as well:

Btw, does anyone know how to change order of the items in the left pane? I'd like to have the reader where Akregator usually is :)

In the first sync, the resource fetches up to 200 latest items form each feed (I think that's a reasonable amount), then the updates are incremental. There is no progress indication, so just be patient.

In a way it is a "replacement" for Akregator  (but it lacks almost all of it's features :-), so actually it's not...). I suppose you don't need to have local feeds in an RSS client when you can interact with feeds on Google Reader directly. On the other hand, it's not a serious project, more like a preview or demonstration of power and awesomeness of the KDE technologies  (it's so simple to use Akonadi!) and all the people behind it. When libkgoogle 0.3 is out and stable, I'd like to dedicate some time to help with the Akregator port (if it's not finished until then), so this project will just rot in git, forgotten.

As I said, this is more of a tech preview, definitely not something for daily use. I won't be spending much time working on it, but of course, feel free to clone the repo (see below) and contribute.

How do I get this?

1) You have to use libkgoogle from the experimental "reader" branch. This branch is rebased against the development branch of what-will-become-0.3, so it's completely incompatible with the current resources from master branch.

$ cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DBUILD_calendar=FALSE -DBUILD_contacts=FALSE

I recommend to install libkgoogle to some other prefix then /usr so that it does not conflict with the stable libkgoogle library, but if you feel brave enough, you can try to compile the branch with calendar and contacts resource as well, since they are mostly finished and working (and I would appreciate some feedback before releasing it).

2) Compile the Reader. The repository contains all the stuff - Akonadi serializer and resource, Kontact plugin, KGoogleReader KPart and KDEGoogleReader application (sorry for the KDEGoogleReader vs. KGoogleReader inconsistency, I couldn't decide how to name it so I was mixing both names :) )

$ git clone git://gitorious.org/kgooglereader/kgooglereader.git
$ cd kgooglereader
$ mkdir build && cd build
$ cmake ../ -DCMAKE_INSTALL_PREFIX=/usr -DLIBKGOOGLE_LIBRARY=/usr/local/lib/libkgoogle.so -DLIBKGOOGLE_INCLUDE_DIR=/usr/local/include/
$ make
$ make install #as root

Remember to replace the path to libkgoogle by wherever you have installed it. Now you should have kdegooglereader executable installed and when you restart Kontact you should see "Google Reader" in the left pane as well.

Well, I hope you like it :)