We have released a beta of KDE Telepathy 0.9, and libkpeople 0.3.0
Features include:
Tarballs are available here and here.
If you're interested in developing and contributing follow our quick start git installation guide
Please report back any bugs so we can make 0.9.0 a great release.
Since my last blog post on plasma addons there has been a lot of activity, existing contributors are active on their own plasmoids, and there are many new faces coming on to take up the challenge of maintaining their own small part of Plasma.
All Plasma 5 development has moved to the master branch, ready for the 5.1 release.
Aleix Pol finished porting the quickshare applet which allows uploading text and images to a pastebin server by clicking and dragging. Xuetian Weng completed the Input panel plasmoid, that allows for entering chinese characters and Kai Broulik finished the Fuzzy Clock plasmoid. I started the notes plasmoid, which is close to being ready for review.
The VDG have been active in designing the ported applets, with the help of kver the system load viewer applet changed significantly:
A small bit of polish makes a huge difference to the end result, and Martin Yrjölä has been leading the porting process of that.
We are constantly adding new things so it's important to clean out old code at the same rate. We need to remove applets that failed to be maintained, or are simply gathering dust and only invest porting effort in what is useful.
With this I am sad (well, not really) to announce:
I know several people liked this applet but when trying to develop a professional experience toys and gimicks aren't a good thing to be shipping by default. The user's desktop is not a showcase for us to experiment with.
That isn't to say we want to police what people make and use, developers are still able to distribute all content through kde-look or other services, we are just making the most of our main distribution channels.
There are still several plasmoids that we want to have available to Plasma 5 users, that are seeking maintainers. Unless people step up to both port and maintain them, it won't happen. So if there's anything you use regularly and miss, please look at the TODO and talk to us on #plasma.
In the first few days at Randa as a coding task between meetings I took on porting one of the larger core applications to Qt5 + KF5. Having applications on Qt5 is not only important for when we make the wayland move as they can run natively but it also ups the motivation to add new features into Frameworks and move technology forwards.
I decided to take on Gwenview because the maintainer, Aurélien, is on a break from KDE and requested somebody took over the task. When I started in KDE Aurélien was one of the coders I most looked up to, so I wanted to pay back and make sure his work lived on.
The screenshot below shows Gwenview ported to KDE Frameworks 5.
Everything is now pushed to the master branch. The core loads, but there's quite a lot of warnings where we haven't ported away from the KDE4 support libraries; it's a great opportunity to get involved on some simple code fixes. Message me if you want to help out.
If anyone is else looking at porting make sure to make full use of Montel Laurent's excellent scripts in kde-dev-scripts. They make a massively painful task only slightly inconvenient.
When we were building towards 5.0, we made the choice to focus all the effort on the core, and not release plasma-addons. It would have been simply too much work and quality of the core would have suffered.
The intention was to start bringing them back from 5.1, which will be in approximately 2 months from now.
The amount of stuff in plasma addons is huge. This screenshot shows only a small sample:
The Plasma Addons is a very mixed bunch of code, it contains some useful tools that really improve productivity such as quickshare, notes and icontasks. However, it also contains broken code, duplicates, tech demos and a range of toys and gimmicks of questionable value.
These things are fine to have these available as internet downloadable extras, but should they form part of an official addons?
It becomes a tricky question, we want to provide a quality professional experience to a user, but we also don't want to stifle developer creativity and we want to give our devs an even platform to distribute their work.
Due to the nature of the changes we made in Plasma4->Plasma5, in many cases the porting invovles a complete rewrite of the code base. It's therefore a good opportunity to give the repository a spring clean, so we only intent to port things that will be picked up by a dedicated maintainer and not port everything for the sake of porting.
As each plasmoid is very standalone, it's a good opportunity to get involved in development. If you have a personal attachment to a plasmoid that you use on a regular basis, we would love people to step up to port and maintain it.
We have a tracking board here:
If you want to take any tasks, ping me (d_ed) on #plasma on Freenode or email the plasma-devel mailing list.
As part of the core Plasma team I have spent a long time helping in the migration to make everything QtQuick2.0 based, making sure we get the most out of the OpenGL backing.
This weekend I wanted to make some sort of demo which shows the power of this in the form of an interactive wallpaper.
Clicking on the desktop simulates a firework at that location. Frantic clicking will simulate the entirety of November the 5th (or July the 4th for people across the pond). When not active the whole thing only uses as much resources as any regular static wallpaper.
Download the complete zipfile here.
Install with the command line
plasmapkg2 -t wallpaperplugin -i fireworks.zip
Then under "Desktop Settings" change the wallpaper type to "fireworks".
Realistically this isn't something that would ever go in the default desktop installation. However by getting good at silly initiatives, we build and optimise for useful things; smooth subtle animations and shadows where it's actually useful.
The actual source code is fairly straightforward.
The QML Particle system is very much like the particle system found in Blender (The main similarity being that I don't understand how to use the particle system in Blender) with emitters and affectors.
In this case a circular emitter forms the base of the firework emitting a burst of coloured particles in all directions; a trail emitter then follows each coloured particles emitting a spread of small white particles to create a sparkly trail effect.
With the power of particles, sprites and even embedding other OpenGL framebuffers, I encourage more people to write some interesting interactive wallpapers.
I previously blogged about the progress Martin Klapetek and I since that I started another round of changes making sure the new Breeze theme works nicely with QtQuickControls.
It poses an interesting question; which should you use when making a new project?
With all the hype and excitement about QtQuick it's hard to get a straight answer. The reality is there is no one single answer that fits everything.
Reports of its death have been greatly exaggerated.
There are (at time of writing) over 1000 commits in the qtbase/widgets directory just since Qt5.0. It quite clearly is still supported and still maintained.
There are not a lot of new features being added, because there is not a lot else to add. From a developer POV this is a good thing as less things are going to break.
Our Frameworks have several widget based libraries; providing pre-built complex widgets from highlighted text editors, to kparts to buttons with integrated KAuth knowledge.
Discarding these and re-inventing these is not only wasteful and time consuming, but also going to result in many inconsistencies.
The styling approaches are very different. In QWidget's QStyle, styles supplied generic margin sizes and would draw generic frames and buttons.
In QtQuickControls styles are very very tied to the control; the style themes a button, or a combo box or checkbox explicitly.
Yesterday I tried to re-create the KColourButton in our KQuickAddons repository; the plan being to subclass the QtQuickControls Button and add a rectangle in the middle... something that should be ridiculously simple turned into an impossible mission; there's just not information in the public API for the developer to get the margins from the theme. In order to fix this, I need to go and add extra API into Qt.
There are some misnomers about QtQuickControls, mostly obvious:
QtQuickControls is destined to be the future replacements of widgets for
_all_ platforms. In 5.4 there is a theme for Android that fits in with the device including opening pickers for comboboxes.
Their is one style/backend for QtQuickControls that uses QStyle to replicate the desktop style. It is a stop-gap measure and not the main objective.
If I was writing this article 6 months ago I would have written about how broken layouts were, I would have a whole paragraph about the difficulties in making the tab key work, I would have pages about blending in with existing widgets or the lack of dialogs. It is a very fast paced world, and each time I revisit the subject the list of places where QWidgets trumps QtQuick keeps falling.
I have multiple changes in QtQuickControls already with a ever growing TODO list. If we put in the work we can shape the future of the widget replacements.
With the android QtQuickControls landing soon, including native dialogs it's very relevant for cross device applications.
I have absolutely no doubt that QtQuickControls is the future way of making applications. However it's important to stress the word "future".
Realistically, even though it's possibly to get quick results in QML, it currently requires a lot more work to add in all the additional functionality that brings it on par with a QWidget application.
What I would like to see within the KDE community:
First we had QWidgets. They provided a set of easy to use components that you might put in an application; buttons, text inputs, combo boxes etc.
In order to make it look nice, as well as integrate on all platforms these widgets don't actually do any drawing themselves. Instead they call a lot of methods in the relevant QStyle and ask the style to draw a frames, render some text, tell it how big spacing should be between various parts. There is an excellent talk about QStyles here.
Widgets a good for making forms, but they aren't suited for drawing animations or custom shapes. So Qt has a framework QGraphicsView, which made it easy to render and manipulate pictures, text and shapes at a graphic level.
Dealing with all these objects in C++ still gets very complicated quickly, so Qt has a way on top of that to create and manipulate these objects using QML, to give us SceneGraph, which is a new underlying drawing technology which only allows use from QML.
QtQuick is a great platform, but we still need a way to draw traditional form components, we need a way to blend into the relevant platform and look like it belongs among the existing apps regardless of the technology used.
QtQuickControls provide a way to insert buttons, text, combo boxes etc. into your QtQuick application. Like in QWidgets, QtQuickControls do not do all the drawing themselves but instead have a QML powered style API for rendering/theming widgets.
This differs from the previous Qt Componenents approach in which platforms (such as PlasmaComponents) would redo all of the internal logic, input handling and drawing themselves.
In addition to providing a new style API, a "desktop" style is provided that talks between the QtQuickStyles API and the application QStyle. This means widgets in QtQuickControls will look the same as QWidgets. It works by providing a QML plugin that
can fetch style hints from QStyle, as well as render QStyle contents (such as frames and backgrounds) into textures that can be used from QtQuick.
In theory, if we use QtQuickControls in a QML application and render it in Oxygen, everything will look perfect and "just work".
In practice not so much. The code that makes QtQuickControls use QStyles is undertaking a very complex task and it's very hard to think about all the different ways a style can be (ab)used to render content.
I, with the help of Martin Klapetek and Martin Gräßlin have been working on fixing these issues.
A lot of the work has been going upstream into fixing the code in QtQuickControls in Qt itself, with a few patches into Oxygen to help Oxygen know what type of widget it is styling.
There are still a few pixels off, but the result is usable for writing widgets or entire applications in QML in a way that fits in with the rest of the KDE applications.
Progress can be seen on the tracking wiki page. Due to timescales these changes will not be in Qt5.2.0 but as they are bugfixes, should be in Qt5.2.1.
Contact me if you want to help out, in addition it would really help us if someone with a self compiled Qt5 on Windows/Mac can help test our Qt patches to ensure we do not break anything; it will really help up our remaining upstream review requests which have not yet been merged.
Apologies for the non KDE post on PlanetKDE. I've recently read so much stuff about Ubuntu's "spying", that I feel it's worth clearing the air.
This is Ubuntu's file search. It searches files.
No, not at all. It searches your files.
The fuss lies in something else, the Ubuntu Dash. There is a lot of confusion about this.
Ubuntu Lenses are a way of searching multiple sources. If we look at the list of available sources it includes web searches such as
Google Books, Reddit, Wikipedia, Youtube, Amazon as well as combining local sources such as applications, local files and menubars. The idea behind it seems to be to create a single unified search bar, abstracting sources from the user. You can search for a song, and not care if the results are local or remote. Pretty neat.
It's quite hard to combine results from the internet, without using the internet, so your search ends up online. Whilst this is encrypted, the results back are not. This is no worse than a search query with Google or Yahoo or any other search engine, and arguably considerably better as you are not later tracked round the web.
In all the search lenses, Amazon is added by default, this gives Canonical money which is fed back into Ubuntu. This is akin to how Mozilla Firefox set the default search provider to Google.
Mozilla earn over $96 million per year for this. KDE Has similar partnerships with enabling DuckDuckGo searches to be manually activated from krunner for a lot lot less.
It's not unheard of in open source communities to make money this way, and whilst I don't think as a user I would like these ads I can't really hold it against them.
Canonical does not have your file contents, they don't even have a list of your files, nor do they track all key presses.
At best, there is a record of a search term linked to an IP address, which may of may not be part of a file name. It's not a lot of private data, and it's not linked to you as a named individual.
The claim by the EFF, is not about the possibility of Canonical 'spying' on you. The claim is that a hacker sniffing your network traffic could infer from the from the images returned from Amazon what you are searching for.
Personally I consider this a very weak claim, if someone is sniffing your network traffic your are more likely to give away personal information in other ways, such as any browsing. It's the EFF's job to err on the side of extreme caution and to provide information. It's up to us as the wider community to balance this with pragmatism and to keep things within proportion.
Edit: And this potential issue has since been addressed for 13.10, all data back is also encrypted, addressing the main point from the EFF. Thanks to Michael Hall for the updated information.
There is a traditional gap between web and local applications, people ignorant of what the dash search does, mistakenly take this for a simple file search. For a file search to use the web would clearly be wrong. The majority of the complaints and criticisms I have read do not come from Ubuntu users who have seen the Ubuntu bar. To any user of the Ubuntu search bar, it should be obvious that it includes internet results due to the high visibility of the internet results within moments of usage.
If we always try to pander to the notion of treating web and local data as two completely separate distinct entities desktop Linux will always be held behind the web applications that are able to employ much richer content. I don't want to have to be at a point where Firefox has to provide a prompt to explicitly state that it will use a network connection.
Spies (with the exception of James Bond) are also secretive. The Ubuntu dash makes no effort to hide exactly what it is doing. Whilst it may not be the world's greatest or most useful feature, this isn't something that spies.
To call it spyware is a blatant lie, to call it a privacy invasion I think is a massive exaggeration of a rather minor concern that misunderstands the goals of the dash.
Image credits: http://webupd8.org and http://ichibikarin.blogspot.com.es
Today we are happy to announce a new version of KDE Telepathy, KDE's instant messaging client.
KDE Telepathy is a suite of applications and plasmoids to allow chatting, file transfer, video calls etc (where available). over popular instant messaging networks. Facebook, Google Talk, Jabber, SIP, and many many more putting all your instant messaging in one place - on your desktop.
If you have already seen the beta announcement you may as well skip to the end, all the following content is exactly the same. Since the beta we have not added any features but fixed any issues that arose.
It's been a long time since the beta because KTp has a "we do not release until all major bugs are fixed" policy. Hopefully it will be worth the wait.
Instant messaging is a constantly evolving platform. There was a time when everyone important was on AOL instant messaging, now that's unlikely. This evolving landscape is one of the main reasons for using Telepathy as our backend which is used my multiple clients.
We not only have our own backends, but can support everything provided by libpurple. We've looked at some of the up and coming libpurple backends and added the small amount of code to make everything available. In this release we now support setting up Steam and Groupwise accounts, if the relevant libpurple backends are available.
Due to the clever separated architecture of the Telepathy framework, unstable backends do not cause instability in the main application.
In addition we are working on developing our own backends, a GSOC student this summer has developed support for sending SMS messages via ModemManager.
We've ported some of our favourite plugins from Kopete, and now we are able to send LaTeX maths formula to each other, great for when you're stuck on the class assignment.
This new plugin automatically expands any shorterned URL to see where it redirects to. No more nasty surprises.
As a Google Summer of Code project, collaborative text editing was added to kde-telepathy. Most prominently, there's now a "Collaboratively edit a document" button in the chat window, which allows you to edit a document together with a contact without any setup being required (except for you and your contact installing the application, of course). Instead of introducing a new dedicated collaborative editor, this feature integrates with existing KDE applications, such as Kate or KDevelop.
This works by using a technology called Telepathy Tubes, which defines a way to use Jabber to open a TCP connection to a contact in the best most efficient way possible. In most cases, it should use a proxy server, but if a direct connection without a proxy is possible, it will prefer that. If even the proxy does not work, it can also fall back to transferring data directly over the Jabber server, which is a bit slower, but works for every environment.
![](http://2.bp.blogspot.com/-kav3ArFDGto/Uj9U-GhOQ1I/AAAAAAAAAgo/zJuCh5FdE8U/s400/shared.png")
Documentation on how to use and install this feature is available here. A more in-depth announcement of the current release is here.
The advantage of using a multi protocol instant messaging client is we are able to show all your accounts in once place. However, this can lead to multiple entries for the same contact across different services.
We are now able to join multiple contacts together, we've introduced a user-interface that allows you to choose to ignore the technical details and start chats quickly or provide fine-grained control as required.
We provide this by adding support for libkpeople - a new system-wide KDE metacontact library aggregating information from all contact sources not just instant messaging contacts but also your local address books, Facebook Feeders, Google contacts, LDAP servers and anything else that provides contacts.
Libkpeople works by syncing contact data from all sources into Nepomuk, this means that in addition to grouping instant messaging contacts together we can also interact with data from other sources. We can see email addresses, phone numbers addresses and start a range of actions.
As this includes both a Nepomuk dependency and a new library we've opted for having two modes, one with the additional features and the other without. If you don't run Nepomuk you will still have original contact list working as before.
In this release we are only adding small subset of new features KPeople is going to provide as it is still very much a work in progress. We wanted to ship this now, to give basic metacontact support setting the buildling blocks for the more advanced features.
Note as this is a new library, your distribution may or may not have this supported.
In addition to all the new features we have been working on fixing lots of additional papercuts throughout the rest of KDE Telepathy.
There have been over 1000 commits since 0.6 and over 300 bugs resolved.
KTp 0.7.0 is available at http://download.kde.org/unstable/kde-telepathy/0.7.0/; packages should be available in some of the major distributions shortly.
If you encounter any problems with the release, please file bugs on our bug tracker
As always we need new developers, we have a lot of exciting new features planned for 0.8.
You can find out more about getting involved here on our wiki.
Today we are happy to announce a new beta version of KDE Telepathy, KDE's instant messaging client.
KDE Telepathy is a suite of applications and plasmoids to allow chatting, file transfer, video calls etc (where available). over popular instant messaging networks. Facebook, Google Talk, Jabber, SIP, and many many more putting all your instant messaging in one place - on your desktop.
Instant messaging is a constantly evolving platform. There was a time when everyone important was on AOL instant messaging, now that's unlikely. This evolving landscape is one of the main reasons for using Telepathy as our backend which is used my multiple clients.
We not only have our own backends, but can support everything provided by libpurple. We've looked at some of the up and coming libpurple backends and added the small amount of code to make everything available. In this release we now support setting up Steam and Groupwise accounts, if the relevant libpurple backends are available.
Due to the clever separated architecture of the Telepathy framework, unstable backends do not cause instability in the main application.
In addition we are working on developing our own backends, a GSOC student this summer has developed support for sending SMS messages via ModemManager.
We've ported some of our favourite plugins from Kopete, and now we are able to send LaTeX maths formula to each other, great for when you're stuck on the class assignment.
This new plugin automatically expands any shorterned URL to see where it redirects to. No more nasty surprises.
As a Google Summer of Code project, collaborative text editing was added to kde-telepathy. Most prominently, there's now a "Collaboratively edit a document" button in the chat window, which allows you to edit a document together with a contact without any setup being required (except for you and your contact installing the application, of course). Instead of introducing a new dedicated collaborative editor, this feature integrates with existing KDE applications, such as Kate or KDevelop.
This works by using a technology called Telepathy Tubes, which defines a way to use Jabber to open a TCP connection to a contact in the best most efficient way possible. In most cases, it should use a proxy server, but if a direct connection without a proxy is possible, it will prefer that. If even the proxy does not work, it can also fall back to transferring data directly over the Jabber server, which is a bit slower, but works for every environment.
Documentation on how to use and install this feature is available here. A more in-depth announcement of the current release is here.
The advantage of using a multi protocol instant messaging client is we are able to show all your accounts in once place. However, this can lead to multiple entries for the same contact across different services.
We are now able to join multiple contacts together, we've introduced a user-interface that allows you to choose to ignore the technical details and start chats quickly or provide fine-grained control as required.
We provide this by adding support for libkpeople - a new system-wide KDE metacontact library aggregating information from all contact sources not just instant messaging contacts but also your local address books, Facebook Feeders, Google contacts, LDAP servers and anything else that provides contacts.
Libkpeople works by syncing contact data from all sources into Nepomuk, this means that in addition to grouping instant messaging contacts together we can also interact with data from other sources. We can see email addresses, phone numbers addresses and start a range of actions.
As this includes both a Nepomuk dependency and a new library we've opted for having two modes, one with the additional features and the other without. If you don't run Nepomuk you will still have original contact list working as before.
In this release we are only adding small subset of new features KPeople is going to provide as it is still very much a work in progress. We wanted to ship this now, to give basic metacontact support setting the buildling blocks for the more advanced features.
Note as this is a new library, your distribution may or may not have this supported.
In addition to all the new features we have been working on fixing lots of additional papercuts throughout the rest of KDE Telepathy.
There have been over 950 commits since 0.6 and over 300 bugs resolved.
KTp 0.6.80 is available at http://download.kde.org/unstable/kde-telepathy/0.6.80/; packages should be available in some of the major distributions shortly.
If you encounter any problems with the beta, please file bugs on our bug tracker
As always we need new developers, entering the beta cycle we need lots of people to help fix bugs that may be in 0.7 as well as helping with all the exciting new features we have planned for 0.8. We already have a huge list of things we want to do.
You can find out more about getting involved here on our wiki.
