The first release of Plasma 5 is after years of active development finally just around the corner. But where is KDE Telepathy for Plasma 5 standing you ask? Well, a bit behind.
We have started with porting and have the basic applets moreless ready to be used, but that's just a small part of the whole suite. The contact list, the chat application, the system integration module and all other parts needs to be ported to offer a good IM experience with Plasma 5. And we want to offer that.
In just 31 days there will be a Port-to-Frameworks sprint in the middle of the Swiss Alps where lots of code will be ported to Frameworks and Qt5 and we would like to add KDE Telepathy on the list of the apps being ported and really push the port forward during that week. Why there? The core of our KTp team will be there, people with great knowledge of KF5/Qt5 will be there, people from Plasma team will be there, in fact, I don't think we could have a better, more focused opportunity than this one. Plus, the meeting being in the mountains makes for high productivity workplace with little to no distractions.
Please help make this legend meeting happen this year by donating and in turn getting more awesomeness. So far we have almost enough to get everyone there, but we could use couple more €s to give the developers also some food during the week (and obviously pay all the other needed expenses;). Head over to http://www.kde.org/fundraisers/randameetings2014/ to read all the details and to become a never forgotten hero on the list of donors. Oh and please do it right now as the fundraising ends tomorrow.
Thank you for every € you send.
Part of the KDE PIM group is meeting over this weekend in Barcelona in the spacious BlueSystems offices, hacking on all sorts of things. Me and David Edmundson took the oportunity to do some super huge changes to our KPeople library that are needed and as the library is in its dawn, it's better to do it sooner than later. These are all internal and boring changes, but one of the changes we've been working on here is really cool and worth mentioning.
One of the most requested features in KDE Telepathy is a way to rename a contact, especially a metacontact. Since we're now using KPeople to power our contact list, implementing this has become a lot easier. So we devised a plan, spend some time implementing it and voila, we now have a way to rename contacts in KPeople (and thus in KTp) but also a way to store any arbitrary data for a contact.
The boring stuff. Back in the days we were always using directly the contacts coming from Telepathy, so any change in the contact's name would have to be sent back to the server and then synced back, which obviously presents a problem for read-only networks. With KPeople we've created new data layer where the Telepathy contacts is just one of the backends. Thanks to this architecture we can modify the data locally in the KPeople layer and then just provide a way to prefer the local changes over the backend data when displaying things to the user. This data is all stored in Akonadi in a special resource with a special collection. You don't have to do anything for this to work, it's all set up behind the scenes the first time it's used.
This work layed the foundation for full local contacts editing which will come later as it's a bit more complex to get done properly in two days. But basically any custom data can now be stored with your contacts, including a timezone or gpg keys and then reused by any application using KPeople.
As all these changes add new APIs, we're aiming for KPeople 0.3 and KTp 0.9.
Good times ahead.
Sooooo after a brief period of testing the public beta we bring you the final stable release of KDE Telepathy 0.8.
During the 0.8 development cycle we focused on bug fixing rather than implementing lots of new features. The biggest changes from 0.7 are all under the hood. We rewrote the metacontacts library, KPeople, almost completely from scratch and made it independent from Nepomuk, which should bring more performance, reliability and stability to the contact list and (meta)contacts management.
Other than that, we've added support for SIPE project, which improves compatibility with some Microsoft products implementing the extended version of SIP, more info about SIPE at project's sourceforge page.
Full bugs changelog is below. The actual commit numbers are much higher than 23 fixed bugs (as we don't have a bug for every commit) so we thought it might be interesting to look at those numbers too, here's the list:
|total including KPeople||473|
As you can see, KPeople itself got about 45% of all the work. On the other end of the list we have our poor Call UI, which only receives "Version changed from X to Y" commits recently. However that is because we need to first port it to newer technologies, which is blocked by non-existing QtGStreamer 1.0. This will soon become history as the awesome Diane Trout of Los Angeles has finished almost all of QtGStreamer 1.0 and her work is now waiting to be merged. You can try the new Call UI out by following her blog post. We hope to have this all merged in 0.9, then we can finally start really improving the Call UI application.
We've also had quite a few new contributors, with both smaller and bigger patches, both longer staying and one-time-submit contributors. Together we received 72 patches (27%!) from 17 non-regular contributors. Which is really really amazing! So below the bugs list, there is a Thank you list of all these people. And what's even more amazing is that some of those occasional contributors are still around, working tirelessly and submitting patches.
If you would like to join us too, we're always happy to welcome new people around, just head over to our wiki and get started :)
But back to the release - you can get the sources for KDE Telepathy 0.8 from the usual KDE's download servers (grab KPeople library here). Some distros should already have packages available for you, if not, please write a mail to your distro packagers.
After some late night hackings, we bring you an update to your favorite IM client on KDE Desktop. This time we've redone the metacontacts solution a bit. It is still powered by KPeople, KDE's contacts aggregation library, but that part itself is no longer powered by Nepomuk. Basically we rewrote it from scratch and made it faster, more reliable, more robust and generally just better.
Now we collect data on the fly from all your sources, be it your Telepathy IM accounts, Akonadi contacts or anything else that installs a plugin (we might have Skype contacts plugin very soon too ;) When you merge two contacts, KPeople stores it in simple sqlite database, which is light and fast and also transferrable (eg. you can take your metacontacts easily with you).
This will all come in the upcoming 0.8 version of KDE Telepathy, which is planned around the end of February/first week of March. For those enthusiastic and cannot-wait users, we bring the beta right here, right now. Source code available here for KTp and here for KPeople. Nag your distros for packages. Super-important: thanks to a last-second change in KPeople, you might hit an empty contact list problem if you install KPeople 0.2.0. The only workaround is installing KPeople 0.2.1, so please anyone, install 0.2.1. Also note that KPeople 0.2 is in no way compatible with 0.1 version, meaning it won't work with KDE Telepathy 0.7 series. Please stay with KPeople 0.1 if you're using 0.7.
It's a beta and so we would really really appreciate if you could go over this checklist here, test things a bit for us and report anything that's broken from the checklist (or otherwise of course) at the usual bugs.kde.org.
We've just released a bugfix version of stable KDE Telepathy - 0.7.1. It doesn't bring too many exciting features as the team works on those for 0.8 version - there we have completely revamped the metacontacts system, it's now 140% faster, more reliable and with less no-contacts-visible problems (actually we haven't seen that one at all). The 0.8 will be coming out soon~ish.
Anyways, 0.7.1 has new config option for completely disabling the Nepomuk metacontact interface, so if you're having troubles with it and would like to just go to the goo'ol' version, put this line into Konsole:
kwriteconfig --file ktelepathyrc --group feeder --key enabled false
That will permanently disable the 0.7 metacontact system and will get you back to your old models, but with no metacontacts.
One other important issue we got reported a lot was about focus problems in the chat window. They should all be fixed now.
Tarballs can be find at the usual place - download.kde.org - please use mirrors (the "Details" link) for downloading.
The rest of fixed bugs follows.
Last year in the summer I've started a project to truly integrate social networks into our Plasma Workspaces. Truly integrating means having all the data available in our system and allowing any application to take advantage of these data, either just for custom displaying or acting on them somehow.
This solution has several parts - auth mechanism, communication with the service, data storage and data presentation.
The current auth mechanism is custom written for each social network, but fully separated and replacable. They are very simple in terms of UI and provide just that - authentication with the web service to fetch data from it. This will be eventuelly replaced by afiestas' WebAccounts thinggy. So any development effort on the auth mechanism should go there.
Data storage. Since Plasma Workspaces already ships with Akonadi by default, there's no need to reinvent the wheel and create a separate infrastructure just for the social media stuff. Akonadi is generic enough and performs reasonably well for our use case.
With that in mind, we can focus on the social networks integration itself, which is done in form of Akonadi resources/agents, which are very easy to write.
Currently there are 4 major social networks out there - Facebook, Google+, Identi.ca and Twitter. The resource for Facebook which lived in kde:akonadi-facebook was splitted into the library part, now named LibKFbAPI (it goes in the path of similar Google library, which is called LibKGAPI) and residing in extragear/libs (kde:libkfbapi) and the resource part itself, which was merged into kdepim-runtime recently and so it's going to be installed by default with 4.11 onwards. Using this resource one can download the Facebook stream (currently loads either last 400 posts or posts up to 3 days back). This includes corresponding likes and comments of the posts. It also syncs your friends, their birthdays, home address and whatnot. There is also code for syncing events and notes, however this not really tested (and the events don't really work at the moment). Furthermore your notifications are synced as well, but nothing is being done with them at the moment. I want these to show up as a regular notifications in your systray, this should be quite easy to do. The resource can also posts new posts with your account, but cannot "like" or comment on posts yet. Akonadi does allow for that, we just need the code in the resource.
Then we have the microblog resource for Twitter & Identi.ca (they have the same API), which I've started from scratch. It's using the same architecture as the Facebook resource - a library communicating with the network and the Akonadi resource sitting on top of that. Its code is completely based on the microblog dataengine from Plasma and currently allows for receiving 20 last posts from the stream as well as posting. Any other functionality is currently missing. This is in git at kde:scratch/mklapetek/akonadi-microblog-ng.
And we are left with Google+. There's not much to say really as there's no public API for G+, which means no data access. Dan Vrátil, the author of libkgapi and Google resources for Akonadi, will add this support once the API is available.
A resource can of course be written for any network with available public API. If the proper serialization is used in the resource, it will automatically work with the social feed. Furthermore, one can also write resource for anything, like upcoming calendar events or new mails and whatnot. By default anything serialized as SocialFeedItem will be displayed in the feed.
We have the data storage, we have interfaces to the networks, so what's missing? Data presentation aka the user inteface. Plasma currently ships with a qml microblog plasmoid, which is quite nice. So I decided to use that as the user interface and started porting it to the new infrastructure. That consists of a qml plugin communicating with Akonadi and providing the content to the qml plasmoid itself. The development is going on in two places - the qml plugin is at kde:scratch/mklapetek/socialfeed and the plasmoid is in a branch "mklapetek/akonadi_port" of kde:declarative-plasmoids.
Alright so here's a summary of tasks left to do. I think they are quite easy, just needs a bit of research on how Akonadi works and getting familiar with the code, which is all just basic Qt4. So if you're thinking about helping up, don't be scared that you'll be dealing with super-complex Akonadi code, you won't ;)
SocialFeed (the qml plugin)
I'd like to see this all in 4.11, but I can't do it all alone. So please step up to any of these single tasks if you have some time to spare, finishing even one task will be awesome and I'll guide you through it. You can either drop an email to kde-pim at kde.org or to me directly to mklapetek at kde.org. Looking forward for your emails.
Let's bring social integration in Plasma Workspaces ahead of its competitors again!
Thanks to our Google Code-In student, Peter Amidon, our little presence plasmoid in the-just-released v0.5.2 can now haz proper monochrome icons. The plasmoid is looking for icons in "icons/presence-applet" and names matching the oxygen scheme with "-plasma" suffix, here's the list:
So, Plasma theme creators, get at it!
I am on a train right now that provides free wi-fi. But you know how these networks work - one second you're chatting with your friend, next second you lose connection. Getting mad enough about not knowing if I have internet or not, I wrote a super simple Plasma applet to monitor the network connection. This is a bit different from the network manager icon, which shows you that you are connected to the wi-fi, but that does not mean the wi-fi router has access to the internet. So this monitors the internet availability directly by sending ping packets to kde.org google.com, one every 5 seconds. If the ping gets back, it shows green icon (user-online icon), if not, it turns into gray (user-offline) icon. Simple as that.
The code is at kde:scratch/mklapetek/pingz, feel free to improve it if you feel like, it's good enough for me for now :)
Update: One thing I didn't realized when running in plasmoidviewer is, that QProcess::execute(..) waits for the ping process to finish. This has the effect of completely hanging plasma every 5 seconds when added to panel or desktop. Fix will follow shortly (if I'll have internet).
So I was installing the newest release of Kubuntu even before it was officially announced and hit a hard wall with it. Took me about four days to figure it out and fix it properly, so here I'm sharing it, hoping someone will find it useful when in similar troubles.
tl;dr version at the end. Somehow it turned into a full fledged story.. :D
A bit of background first. On my MacBook Pro 7,1 (mid-2011) I first installed Kubuntu 11.04. As was the custom/ritual for the past few years, with every new release of the distro I was using (starting with Fedora 5) I went to the shop, bought a CD and burned the iso. Same for Kubuntu 11.04, nothing special, everything worked. Then they decided to raise the size and not fit on the CDs anymore, so I went just with simple distro upgrade to 11.10, no clean install. Same thing with 12.04. However my root partition became a real mess with lots of devel stuff, lots of deprecated packages and libraries and whatnot. And I was constantly running out of space on that partition. So I decided to just format that partition and install the newest Kubuntu 12.10 as soon as it's out (silly me).
But since the iso no longer fits the CD, I went for installing from USB. After some initial troubles with the installer (which were partially due to bad partitioning, partially because of the installer not handling Mac's EFI properly), I managed to install it, screwing up Mac's bootloader in the process. But I didn't need it anyway, I was happy with grub and my new Linux install.
Kubuntu comes with this nice tool called "jockey", which allows you to install proprietary drivers just by clicking one button. So I went for proprietary Nvidia drivers as I play games from time to time and I use the notebook in uni quite a lot, so I need good battery life. Drivers activated, rebooting and black screen. So I did the usual - check if nouveau is blacklisted, if nvidia kmod is properly loaded, see the logs....and nothing. Everything was perfectly fine. Except the black screen. So I used jockey to switch the Nvidia driver off, rebooted and no X at all. Well since it was clean install and the install was quite fast, I just reinstalled the whole system. And same scenario happened - activated different Nvidia driver, rebooted, black. Reinstall. Tried driver from nvidia.com, no luck. Tried drivers from xorg-edgers ppa, no dice. Downgrading X server, pffft. All the same issue.
At this point I started to become desperate that I can't figure out what's wrong, Google was no help and I was without usable system for two days. Now if you're thinking - "why didn't you just stay with nouveau?" well I did. For one day, when I hit some (known, reported) bug while watching movie, sending my X to /dev/null and locking up kernel. I was starting to think that my graphics card is dieing...
Hours and hours of Googling later I found out that my system was booted using EFI mode. Investigating this deeper I discovered, that Nvidia with Linux in EFI mode are not the best friends. I learned that I needed to make Kubuntu boot in BIOS compatibility mode, basically by switching grub-efi for grub-pc. No easy task getting rid of the linux-efi bootloader though. After no luck with that, I decided to verify my theory and installed Kubuntu 11.04 from CD, which installs grub-pc and it turned out that this was indeed the issue.
So I fired up my OS X install, where the 12.10 iso was, navigated to the file, right clicked on it and it offered "Burn" menu entry. Cool, I thought and searched my entire DVD collection for an empty DVD. Found one, inserted it in, burnt, rebooted, nothing happened, DVD not detected. Desperation was doubled by now. Booted back OS X, opened the DVD and, well, when OS X says "Burn", it means "I will put this file on the disk for you", not "Burn the iso". Partially happy, partially angry, I searched for another DVD. Burnt the iso properly, rebooted, installed, activated Nvidia driver, rebooted, cried with happiness.
tl;dr - Binary Nvidia drivers are not working when you install Linux on Mac (possibly on all (U)EFI systems) from USB stick, which installs grub-efi bootloader. You need to go the old-school-last-century-way and install from CD/DVD, which installs grub-pc and boots Linux in BIOS compatibility mode. And install the bootloader to the root device, not the partition, otherwise it won't be seen by Mac's bootloader. I'm not sure if the grub-pc can be installed from the USB stick too, I really don't have any energy (and interest) left to find this out, so your safest bet is the CD/DVD, but if you have any additional info, please share in comments.