Planet KDE

Syndicate content
Planet KDE -
Updated: 6 hours 59 min ago

KDE Software Compilation 4.13.3 available in the stable repositories

Mon, 2014-07-28 17:46

KDE's third update of its 4.13 series of Applications and Development Platform is now available in Chakra's stable repositories. With this release kde-workspace has also been updated to version 4.11.11.

This release was targeted at updating translations and bug fixing, with over 50 bugs being resolved. According to the official release announcement, these "include improvements to Personal Information Management suite Kontact, Umbrello UML Modeller, the Desktop search functionality, web browser Konqueror and the file manager Dolphin". The language front Farsi (Persian) reached the essential criteria and is now available. There were also important fixes for Kopete: fixed formatting both plain and html messages when OTR plugin is enabled, loaded but not used for encrypting messages in chat window and fixed generating of html messages in jabber protocol.

In addition, this move includes:

  • phonon 4.7.2
  • octopi 0.4.2. Please note that octopi is now split into two packages, octopi and octopi-notifier, so users that want to to use this notifier must install it separately.

    It should be safe to answer yes to any replacement question by Octopi or Pacman. If in doubt or if you face another issue, please ask on our forums or report it on our bugtracker.

    As always, make sure your mirror is fully synchronized before performing this update. To check, run mirror-check in Konsole, or use the mirror-check application found under the "Internet" category in the application launcher.
  • Categories: FLOSS Project Planets

    Layout Guidelines: A quick example

    Mon, 2014-07-28 17:35

    For planet readers: This post is written by Andrew Lake

    We recently released new layout guidelines to aid with designing applications and plasmoids. So I wanted to provide a quick example of how to use the guidelines to design the layout for an imaginary calendar application.

    A quick design for an imaginary calendar app
    To choose an application layout, the new guidelines encourage awareness of the functions and commands provided by your application as well as the structure of the content provided by your application.

    So let's start with commands. Suppose we want the primary function of our calendar application to be providing a daily, weekly or monthly schedule of the user's upcoming work or personal events. The user, Sue, would also like to be able to add events to her schedule. There are many other functions for a calendar application that I'm sure we're all aware of. We're not designing in a vacuum - there are many calendar applications from within KDE and elsewhere from which to draw inspiration. For the sake of this example though, lets start with the described functions and commands.

    The guidelines suggest layout patterns for simple, complex and very complex command structures. So where does our calendar app fit? Well, I wasn't quite sure either. And that's ok! Some things are tough to know until you start delving into the design work. The guidelines suggest starting with a pattern for a simple command structure when you're not sure. So that's what I did. As I started putting together a design and thinking about how Sue would use it for the purposes described, it became clear that not only were there several other desirable functions (like switching calendars, setting up calendar accounts, setting calendar colors, and more) but there are also certain commands Sue might use quite often (like switching between a day, week and month view of her schedule, adding an event and quickly getting back to today after browsing forward or back in time). So I settled on the suggested Toolbar + Menu Button command pattern for a complex command structure.

    The mockup toolkit provides an example:

    The content structure for a calendar is pretty much flat: Just a collection of days (with or without events). I wanted to show a single day view, a week view(7 days) or month view (28 - 31 days) as well as properties related to the current view or selection like the date, the agenda for the current day or view and the active calendars. So I settled on a Selection-Properties navigation pattern from the recommended patterns for a flat content structure

    The mockup toolkit provides an example of a Selection-Properties navigation pattern combined with a Toolbar+Menu Button.

    Now I have a basic layout I can use for the rest of the design work. I put what I think will be the most frequently used commands on the toolbar - Today, Day, Week and Month views as well as a command to add an event. 

    Many of the other commands like setting up calendar accounts and the like are exposed through the menu button. I design a week view using the recommended design color set and occasionally checking the typography guidelines. For the properties panel. I draw some inspiration of Sebastian Kügler's great design work on the new clock plasmoid panel popup for the current date to achieve some additional visual consistency with the desktop. I also decided to add a mini month view for convenience and a legend for the active calendars (possibly directly editable?).
    Put it all together and we have a quick design for an imaginary calendar application. 

    It's not a complete design in any sense of the word - icons, day and month views aren't shown, nor are calendar settings and the like. But it's probably enough to, for example, start a review on the VDG forums to get feedback from our fellow intrepid designers, the usability team and/or potential developers.
    Just to be clear, you still have to design. Design is a creative activity. While guidelines can provide a sandbox, it still requires creativity within that sandbox. Often that means that the best way is to just start and figure it out as you go. For me, that's usually a bumpy trial and error process which I simply accept rather than agonize about. And no, you're not allowed to declare that you're not creative! :-) 
    Always feel free to ask for help or feedback on the VDG forums - it's a great place for us to learn together. This design was done using the mockup toolkit, but just use whatever tool you're comfortable with, including just sketching on paper and taking a picture of it. Don't wait. Don't hesitate. Just do. The long term hope is that these new layout guidelines will provide enough flexibility to create layouts suitable across the full spectrum of KDE applications while also helping to achieve layout consistency where it makes actually sense. Like all guidelines, it is a living document which we'll update collaboratively over time. We'll also do more examples like this in the future.
    Hope this helps!

    Categories: FLOSS Project Planets

    Monday Report: Creating Documentation

    Mon, 2014-07-28 13:09

    Yesterday we reached a small but important goal, we completed the first of our self-set tasks for this cycle, namely finishing our application layout guideline. The guideline has been presented to the community to gather feedback and was moved to the HIG wiki yesterday.
    If you think something blatantly obvious has been overlooked, don’t be afraid to speak up. The guidelines can always be improved. Keep in mind though that we intend to make more visual examples available in the guidelines. As of now we were mainly concerned with the textual content of the guidelines.
    The guidelines are intended to standardise which layout elements KDE applications use and to help pointing out which layout is best suited for a specific type of application.
    Additionally to the release of the application layout guidelines Andrew Lake has updated the mockup toolkit with some examples of how one can use the layout guidelines in combination with the toolkit to prototype application designs.

    Another project that starts to take shape is the next network system settings module. This module is intended to be one of the first with an updated design for the new system settings.
    This work is in its early planning phase so if you have something important to say, chime in!

    On the window decoration front Martin Gräßlin has blogged about the advances he’s made. If you haven't seen the blog post yet give it a read, it provides very interesting insights in the internals of KWin’s new decoration API. Now it’s time for us to work on the details like padding, etc. We're very pleased with the amount of progress being made, which shows again how absolutely awesome the KDE developers are.

    CommunityWe are very happy to see the increased community activity in the forums. Last week a whole bunch of new users arrived in the forums and started to give all kinds of useful feedback and ideas.
    It’s very impressive what a difference a few motivated individuals can make. We hope to integrate all of you into our workflow as good as possible and try not miss any of your ideas. If this should happen anyway don’t be afraid to voice your ideas again.

    Categories: FLOSS Project Planets

    meta-kf5 usable

    Mon, 2014-07-28 11:21

    Finally I’ve had the time to work over the final issues in meta-kf5. Right now, I build most tier 1 and tier 2 components. I’ve packaged most functional modules and integration modules from these tiers.

    When it comes to integration modules, there might be missing dependencies that need to be added – but that should not be too hard to add.

    To be able to create useable cmake files, I had to employ a small hack modifying the cmake-files from KF5 before installing and packaging them. This seems to work (i.e. tier 2 builds), but there might be other sed-expressions that are needed.

    Also, the autotests are not built as long at Qt5Test is left out form the build. If you would add Qt5Test, I believe that the unit tests will be included in the same package as the libs. I’ll address this as I integrate the autotests into ptest.

    Summing up all of this, I’d say that the meta-kf5 layer now is usable!

    That is all for now. As always, contributions are welcome! If you find a use for this, I’d be happy to add your project as a reference to the layer!

    Categories: FLOSS Project Planets

    New Kubuntu Plasma 5 Flavour in Testing

    Mon, 2014-07-28 06:33

    Kubuntu Plasma 5 ISOs have started being built. These are early development builds of what should be a Tech Preview with our 14.10 release in October. Plasma 5 should be the default desktop in a future release.

    Bugs in the packaging should be reported to kubuntu-ppa on Launchpad. Bugs in the software to KDE.

    Categories: FLOSS Project Planets

    Kubuntu Plasma 5 ISOs Rolling

    Mon, 2014-07-28 06:20
    KDE Project:

    Your friendly Kubuntu team is hard at work packaging up Plasma 5 and making sure it's ready to take over your desktop sometime in the future. Scarlett has spent many hours packaging it and now Rohan has spent more hours putting it onto some ISO images which you can download to try as a live session or install.

    This is the first build of a flavour we hope to call a technical preview at 14.10. Plasma 4 will remain the default in 14.10 proper. As I said earlier it will eat your babies. It has obvious bugs like kdelibs4 theme not working and mouse themes only sometimes working. But also be excited and if you want to make it beautiful we're sitting in #kubuntu-devel having a party for you to join.

    I recommend downloading by Torrent or failing that zsync, the server it's on has small pipes.

    Default login is blank password, just press return to login.

    Categories: FLOSS Project Planets

    Plasma5 : Now more awesome as a Kubuntu ISO

    Mon, 2014-07-28 05:39

    The Kubuntu team is proud to announce the immediate availability of the Plasma 5 flavor of the Kubuntu ISO which can be found here (here’s a mirror to the torrent file in case the server is slow). Unlike it’s Neon 5 counterpart , this ISO contains packages made from the stock Plasma 5.0 release . The ISO is meant to be a technical preview of what is to come when Kubuntu switches to Plasma 5 by default in a future release of Kubuntu.

    A special note of thanks to the Plasma team for making a rocking release. If you enjoy using KDE as much as we do, please consider donating to Kubuntu and KDE :)

    NB: When booting the live ISO up, at the login screen, just hit the login button and you’ll be logged into a Plasma 5 session.

    Categories: FLOSS Project Planets

    WebODF easily used, part 1: ViewerJS

    Sun, 2014-07-27 23:03

    You possibly have heard of WebODF already, the Open Source JavaScript library for displaying and editing files in the OpenDocument format (ODF) inside HTML pages. For ideas what is possible with WebODF and currently going on, see e.g. Aditya’s great blog posts about the usage of WebODF in OwnCloud Documents and Highlights in the WebODF 0.5 release.

    The WebODF library webodf.js comes with a rich API and lots of abstraction layers to allow adaption to different backends and enviroments. There is an increasing number of software using WebODF, some of that listed here.

    Those which are interested in the capabilities of WebODF, without needing a custom and highly integrated solution, can additionally go for ready-made simple-to-use components based on WebODF. This blog post is the first of a series to introduce you to those. It starts with the component that gives you embedded display of OpenDocument format files, that is text documents (ODT), presentation slides (ODP) and spreadsheets (ODS), in webpages by just a single (sic!*) line of HTML code:
    * no-one would add a line-break there ;)


    ViewerJS is an Open Source document viewer that enables embedded display of ODF or PDF files directly in webpages, without any external server dependencies, just done with HTML, CSS and Javascript. It uses WebODF to display files in the OpenDocument format and PDF.js for files in the PDF format.

    Deploying and using ViewerJS with your webpages can be done in a few minutes. Follow this guide and see yourself!

    Quickly Added

    Start with looking at the current time and noting it.

    As example file take an ODP of your choice, otherwise let’s use the slides from a talk at KDE’s Akademy in 2013, akademy2013-ODF-in-KDE-Calligra-WebODF.odp.

    If you do not have a webserver handy, create a mini one locally on your system:

    # Create a folder structure to serve statically
    mkdir htroot

    # Put the sample ODP file into htroot, renamed as "example.odp"
    cp akademy2013-ODF-in-KDE-Calligra-WebODF.odp htroot/example.odp

    # Add a simple html file:
    touch htroot/example.html

    Open example.html in an editor and have this as content:

    <!DOCTYPE HTML> <html> <head> <title>example.odp</title> </head> <body> <div>We got an ODP file.</div> <div>Would be nice to show it here.</div> </body> </html>

    Start a simple webserver program serving that directory, e.g. the one built into Python. For that open a separate console and do:

    cd htroot
    python -m SimpleHTTPServer

    Now browse to and make sure you see that HTML file.

    The ODP file example.odp is not displayed yet, right. Not so nice.

    Let’s change that and deploy ViewerJS for it.

    In the first console now do:

    # Download
    # (check if there is a newer version perhaps, then change
    # all "0.5.2" below to the new version string)

    # Unzip the file

    # Move the folder "ViewerJS" to the toplevel dir of
    # the folder structure statically served by the webserver
    # (could also be a non-toplevel dir)
    mv viewerjs-0.5.2/ViewerJS htroot

    Now replace the “Would be nice to show it here.” in the example.html with this code (remove the REMOVEME, workaround to strange WordPress behaviour):
    <REMOVEMEiframe id="viewer" src="/ViewerJS/#../example.odp" width='400' height='300' allowfullscreen webkitallowfullscreen></iframe>

    (in the sources one line, as promised. But add line-breaks as you like ;) )

    Now reload in your browser. And if everything worked out, you see the ODP file now embedded in the webpage, ready to be read or e.g. presented fullscreen.

    Look again at the current time. How minutes did you need? :)

    ODF or PDF

    For publishing done documents that should be only read and not further processed, PDF is the better choice IMHO, because the format specifies the exact positioning of everything.
    ODF (same with similar formats like OOXML) leaves the actual fine-layout to the program displaying/printing the document, which can differ between computer systems and setups, usually due to the used font engine. This makes sense, as it allows to create ODF files from code that has no clue about layout calculations, e.g. some Perl script generating a report. But it can result in frustrations if some document with manually optimized layout gets differently layout-ed elsewhere.

    Thanks to PDF.js ViewerJS can also nicely display PDFs, so use whatever format suits the needs, be it preview of some document to further process or display of the final result.

    Take a PDF file and change the above example to show that instead of the ODP file. Then try also with an ODT or ODS file.

    Getting better week by week

    The developers of WebODF are constantly enhancing its coverage of the ODF spec. See how the slides template for this year’s GUADEC (of course done in ODP :) ) are almost looking the same in LibreOffice and ViewerJS (v0.5.2):

    Currently the Wiki hosting the GUADEC slide templates still has to say:

    Current configuration does not allow embedding of the file lightning_talks.odp because of its mimetype application/vnd.oasis.opendocument.presentation

    ViewerJS and WebODF hopefully can be a reason to change that soon :)

    When giving talks about WebODF of course ODPs and ViewerJS are used. Knowing the pitfalls the slides can be done avoiding those. Still many real-life samples not designed for current WebODF capabilities are increasingly well displayed, also e.g.


    In general are ODF documents with only formatted text and images in SVG, PNG, JPEG or similar no problem for WebODF and thus ViewerJS. But as can be seen next, e.g. native ODF graphic elements are still a TODO (and the result not related to any censoring code ;) ). But, the display is already good enough for a “preview” :) :

    BTW, if you are browsing a website that does not yet use ViewerJS to display ODF files embedded but only provides them as links, there is another WebODF-based option for Firefox users: the ODF viewer Firefox Add-on, that allows viewing ODF documents directly in Firefox on any device, without the need of a (big) office suite.

    More on

    Learn more about ViewerJS on the website, e.g. how to support non-embedded custom fonts. Discover the ViewerJS plugin for WordPress. Think about how you and your websites could make use of ViewerJS and how you could help to improve ViewerJS and WebODF, and then contact the ViewerJS and WebODF developers about that! They are looking forward to working together with you as well.

    Categories: FLOSS Project Planets

    Some news about KF5

    Sun, 2014-07-27 18:54

    Things moved recently about kf5 in mageia. We had, since a long time, the framework part.

    Now that the first stable release is out we packaged the desktop/workspace  release based on KF5.

    Unfortunalty this can’t be co-installed in parallel of KDE4. For the moment ( not yet clean packages ) you have to follow those steps:

    1- Remove  kdebase4-workspace ( this will remove a bunch of packages workspace dependant ( plasma applets, etc).
    2- install plasma-desktop and plasma-workspace

    3 restart your session and in your favorite DM go in KF5.

    Keep in mind that those are experimental packages.

    To report « packaging » bugs, please go to the Mageia Bugzilla

    To report funcionnal bugs, please go to KDE Bugzilla

    Categories: FLOSS Project Planets

    Per-activity favourites in Kickoff

    Sun, 2014-07-27 17:37

    I’ve become overly lazy when writing blog posts is concerned. Maybe it is because I’m again working on the user-visible features, and it is much easier to just post a screen-shot or a screen-cast, than to actually write anything meaningful.

    It also gives the audience a chance to ask ‘does this mean that plasma will have …’ which sometimes brings wonderful ideas to life.

    Categories: FLOSS Project Planets

    Off the bike again

    Sun, 2014-07-27 05:39

    Welp, summer vacation is over again, cycled from Nijmegen south. At the outset I said “we’ll go south till we have to speak French, and then turn around”, which meant “until Luik / Liége”. Didn’t make it that far, for the simple reason that campgrounds that are compatible with a family of cyclists with a tent are rare in that area. Instead, we cycled through Belgian Limburg, across Dutch Limburg from Maastricht to Vaals, and then back up north to Venlo. I would show a map (as I did last year with Marble), but I did my GPS logging with My Tracks on Android this time, and I’d have to spend too much time mucking about to get the data off the device for processing. Last year we rode 440km of completely flat Friesland and Groningen. This year there were hills (the Dutch Mountains!), and we weren’t sure how the kids would fare in more challenging terrain. We needn’t have worried. Mira’s “hey dad, let’s bike up the tallest mountain in the Netherlands” (322m above sea level, rising from Vaals at 160m, so this is not Tour de France material yet) was later followed by Amiel’s “hey dad, I want to ride 100km on the last day”. He’s nine years old and it took us from 10:30am to 9:00pm, but we got to the train station at Venray with 99.98km on the meter (and another 3km to go after we got off the train in Nijmegen). Still got a few days off from work-work, so I’ve decided to pick up some KDE-FreeBSD stuff again, and Tupi in particular.

    Categories: FLOSS Project Planets

    What’s new in kf5 porting script ( and co :) )

    Sun, 2014-07-27 01:55

    I continue to write some scripts:

    • It will allow to port from KTempDir to QTemporaryDir
    • It will allow to port from KTemporaryFile to QTemporaryFile
    • Q_WS_* was replaced by Q_OS_*
    • Now we use QCryptographicHash(QCryptographicHash::Md5)
    • It converts from KDoubleNumInput to QSpinBox

    And there was some fix in other scripts.

    I will continue to create new script.

    Categories: FLOSS Project Planets

    A KDecoration2 update

    Fri, 2014-07-25 12:49

    Before heading into the weekend I thought about writing a small update about the KDecoration2 status. Since my last blog post I started integrating KDecoration2 into KWin. This was partially easier and partially more difficult than anticipated. Especially ripping out the old decoration code is rather complex. There are quite some design differences which make the transition complex and especially values inside KWin core are using enums defined in the decoration API – e.g. the maximized state is kept as a KDecorationDefines::MaximizedMode. This will need further work to move the enums and so at the moment the old decoration library is still compiled although the library is no longer in use.

    Ah that means there is code? Yes, today I pushed the branch as “graesslin/kdecoration2″ into kde:kwin git repository. To give it a proper try you also need the kde:kdecoration (master branch) and kde:breeze also on “graesslin/kdecoration2″ branch. The new decoration API is working quite well and I’m rather satisfied. The memory usage of KWin dropped significantly. In a previous report I mentioned that KWin needs around 200 MB, right now my KWin only needs around 40 MB, the number of open windows is a little bit smaller, but still it shows in the right direction. And that’s without any optimisations. There is still some optimization potential in Breeze (check out our todos, all purple tasks are in Breeze) and in KWin (red tasks). Also a nice improvement is that the window decoration no longer flickers when resizing the window. This is a rather big annoyance of KWin 5.0. I expected that the new API would fix this issue, but seeing it confirmed is really nice

    Last but not least the restart of KWin got faster which is a nice improvement for KWin developers, for users it’s not that important. The reason for this is that when we enabled/disabled compositing we recreated the window decorations. So when restarting KWin we first created all windows with their decoration before enabling compositing to just destroy them and create them again (yes it would have been possible to improve it, but it doesn’t hit users). Now with the new API there is no need to recreate the decoration. Only a Renderer is exchanged, but the rendering is delayed till it’s needed.

    This screen shot does not only show the new Breeze decoration, but also some new features: when quick tiling a window the borders cornering the screen edges are removed. Also in the preview application one can see that the decoration scales which is nice for high-dpi screens. The decoration API follows the approach Plasma is using.

    I have been running a KWin with the new decoration API since Monday, which means we are close to start the review process. But there’s of course still work to be done and I’d appreciate any help. The window tab API is not yet implemented, the configuration module needs adjustments to load and render the new deco and most important we have to port the existing decorations like Oxygen, Aurorae, deKorator and QtCurve. For the last three I want to improve the theme experience by allowing the plugin to say that it supports themes directly in the JSON meta data and point to where to find them. So the configuration module can just show all of them. The trick will be to pass the to be used theme to the factory method (we have a nice QVariantList there which can be used). Also the meta data will make it possible to point to GHNS configuration files so that we can not only download Aurorae themes from the configuration module, but also other themes.

    Categories: FLOSS Project Planets

    Another report

    Fri, 2014-07-25 10:02
    As I make progress on my project, I learn just as all gain is not monetary not all progress is code.

    From the time of my last report (Sorry Myriam since it was more than a week ago), I have not written any "pushable" code i.e. only some code has been changed that serve as markers (like a TODO) for future work or some really minor bugs fixed that I stumbled upon as I use my flavor of Amarok.

    Anyway, I was going through the collectionscanner code, trying to understand how it works: it as another process that the main Amarok process communicates with. It is designed to go through files and directories and mark files that are useful to Amarok. Like .mp3 , .ogg , etc. I am thinking to add .lrc to this list. For this I will have to create a class whose instance would represent an lrc file.

    After this I will need to add these lyrics to the Amarok database. I still haven't been able to decide should I make this change in the generic core/collections/Collection.cpp class or the core-impl/collections/SqlCollection.cpp class. When this is over, I will just have to save the lyrics as lyrics tag and the LyricsApplet will pick it up.
    Categories: FLOSS Project Planets

    Kubuntu 14.04 LTSUpdate Out

    Fri, 2014-07-25 06:35

    The first update to our LTS release 14.04 is out now. This contains all the bugfixes added to 14.04 since its first release in April. Users of 14.04 can run the normal update procedure to get these bufixes.

    See the 14.04.1 release announcement.

    Download 14.04.1 images.

    Categories: FLOSS Project Planets

    Plasma’s Road to Wayland

    Thu, 2014-07-24 22:28

    With the Plasma 5.0 release out the door, we can lift our heads a bit and look forward, instead of just looking at what’s directly ahead of us, and make that work by fixing bug after bug. One of the important topics which we have (kind of) excluded from Plasma’s recent 5.0 release is support for Wayland. The reason is that much of the work that has gone into renovating our graphics stack was also needed in preparation for Wayland support in Plasma. In order to support Wayland systems properly, we needed to lift the software stack to Qt5, make X11 dependencies in our underlying libraries, Frameworks 5 optional. This part is pretty much done. We now need to ready support for non-X11 systems in our workspace components, the window manager and compositor, and the workspace shell.

    Let’s dig a bit deeper and look at at aspects underlying to and resulting from this transition.

    Why Wayland?

    The short answer to this question, from a Plasma perspective, is:

    • Xorg lacks modern interfaces and protocols, instead it carries a lot of ballast from the past. This makes it complex and hard to work with.
    • Wayland offers much better graphics support than Xorg, especially in terms of rendering correctness. X11′s asynchronous rendering makes it impossible to be sure about correctness and timeliness of graphics that ends up on screen. Instead, Wayland provides the guarantee that every frame is perfect
    • Security considerations. It is almost impossible to shield applications properly from each other. X11 allows applications to wiretap each other’s input and output. This makes it a security nightmare.

    I could go deeply into the history of Xorg, and add lots of technicalities to that story, but instead of giving you a huge swath of text, hop over to Youtube and watch Daniel Stone’s presentation “The Real Story Behind Wayland and X” from last year’s, which gives you all the information you need, in a much more entertaining way than I could present it. H-Online also has an interesting background story “Wayland — Beyond X”.

    While Xorg is a huge beast that does everything, like input, printing, graphics (in many different flavours), Wayland is limited by design to the use-cases we currently need X for, without the ballast.
    With all that in mind, we need to respect our elders and acknowledge Xorg for its important role in the history of graphical Linux, but we also need to look beyond it.

    What is Wayland support?

    KDE Frameworks 5 apps under Weston

    Without communicating our goal, we might think of entirely different things when talking about Wayland support. Will Wayland retire X? I don’t think it will in the near future, the point where we can stop caring for X11-based setups is likely still a number of years away, and I would not be surprised if X11 was still a pretty common thing to find in enterprise setups ten years down the road from now. Can we stop caring about X11? Surely not, but what does this mean for Wayland? The answer to this question is that support for Wayland will be added, and that X11 will not be required anymore to run a Plasma desktop, but that it is possible to run Plasma (and apps) under both, X11 and Wayland systems. This, I believe, is the migration process that serves our users best, as the question “When can I run Plasma on Wayland?” can then be answered on an individual basis, and nobody is going to be thrown into the deep (at least not by us, your distro might still decide to not offer support for X11 anymore — that is not in our hands). To me, while a quick migration to Wayland (once ready) is something desirable, realistically, people will be running Plasma on X11 for years to come. Wayland can be offered as an alternative at first, and then promote to primary platform once the whole stack matures further.

    Where at we now?

    With the release of KDE Frameworks 5, most of the issues in our underlying libraries have been ironed out, that means X11-dependent codepaths have become optional. Today, it’s possible to run most applications built on top of Frameworks 5 under a Wayland compositor, independent from X11. This means that applications can run under both, X11 and Wayland with the same binary. This is already really cool, as without applications, having a workspace (which in a way is the glue between applications would be a pointless endeavour). This chicken-egg situation plays both ways, though: Without a workspace environment, just having apps run under Wayland is not all that useful. This video shows some of our apps under the Weston compositor. (This is not a pure Wayland session “on bare metal”, but one running in an X11 window in my Plasma 5 session for the purpose of the screen-recoding.)

    For a full-blown workspace, the porting situation is a bit different, as the workspace interacts much more intimately with the underlying display server than applications do at this point. These interactions are well-hidden behind the Qt platform abstraction. The workspace provides the host for rendering graphics onto the screen (the compositor) and the machinery to start and switch between applications.

    We are currently missing a number of important pieces of the full puzzle: Interfaces between the workspace shell, the compositor (KWin) and the display server are not yet well-defined or implemented, some pioneering work is ahead of us. There is also a number of workspace components that need bigger adjustments, global shortcut handling being a good example. Most importantly, KWin needs to take over the role of Wayland compositor. While some support for Wayland has already been added to KWin, the work is not yet complete. Besides KWin, we also need to add support for Wayland to various bits of our workspace. Information about attached screens and their layout has to be made accessible. Global keyboard shortcuts only support X11 right now. The screen locking mechanism needs to be implemented. Information about Windows for the task-manager has to be shared. Dialog positioning and rendering needs to be ported. There are also a few assumptions in startkde and klauncher that currently prevent them from being able to start a session under Wayland, and more bits and pieces which need additional work to offer a full workspace experience under Wayland.

    Porting Strategy

    The idea is to be able to run the same binaries under both, X11 and Wayland. This means that we (need to decide at runtime how to interact with the windowing system. The following strategy is useful (in descending order of preference):

    • Use abstract Qt and Frameworks (KF5) APIs
    • Use XCB when there are no suitable Qt and KF5 APIs
    • Decide at runtime whether to call X11-specific functions

    In case we have to resort to functions specific to a display server, X11 should be optional both at build-time and at run-time:

    • The build of X11-dependent code optional. This can be done through plugins, which are optionally included by the build-system or (less desirably) by #ifdef’ing blocks of code.
    • Even with X11 support built into the binary, calls into X11-specific libraries should be guarded at runtime (QX11Info::isPlatformX11() can be used to check at runtime).
    Get your Hands Dirty!

    Computer graphics are an exciting thing, and many of us are longing for the day they can remove X11 from their systems. This day will eventually come, but it won’t come by itself. It’s a very exciting time to get involved, and make the migration happen. As you can see, we have a multitude of tasks that need work. An excellent first step is to build the thing on your system and try running, fix issues, and send us patches. Get in touch with us on Freenode’s #plasma IRC channel, or via our mailing list plasma-devel(at)

    Categories: FLOSS Project Planets

    Cutelyst 0.3.0 is now C10K ready!

    Thu, 2014-07-24 19:18

    Release early, release often has never been my strength especially since I don’t do a fair scheduling of all the projects I’m involved…

    So since I was in need to better polish Cutelyst I took more time on it, and the result is great, around 100% speed up and a few new features added.

    Cutelyst uWSGI plugin now has support for –thread, which will create a QThread to process a request, however I strongly discourage its usage in Cutelyst, the performance is ~7% inferior and a crash in your code will break other requests, and as of now ASYNC mode is not supported in threaded mode due to a limitation in uWSGI request queue.

    Thanks to valgrind I managed to make a hello world application from 5K request per second on 0.2.0 to 10K req/s on 0.3.0 on an Intel Core2Duo 2.4Ghz (or 44K req/s on an AMD Phenom II 965 x4 3.4Ghz), however if you enable Grantlee templating you get around 600 req/s so if I happen to have time I will be looking into improving its performance.

    Response::body() is now a QIODevice so you can set a QFile* of something else and have Cutelyst to send it back.

    Now points to a gitorious Wiki which is slowly getting populated, and API is available as

    The 0.3.0 tarball can be downloaded here

    Have fun :)

    Categories: FLOSS Project Planets

    Node.js support in KDevelop

    Thu, 2014-07-24 18:00

    This is a quick blog post to say that I’m working on support for the Node.js framework by the KDevelop QML/JS language plugin. The first part of my work is already finished: “require” is properly recognized and Node.js modules are properly looked-up and included. The “exports” and “module.exports” identifiers are also recognized and allow Javascript files to export symbols and to be used as modules. This means that you can now edit Javascript files using Node.js and have most of the modules recognized, included and parsed.

    The second part is writing huge Javascript files for the built-in Node.js modules. “http”, “buffer”, “fs”, “url” and many other modules exist only as part of Node.js. There are Javascript files for them in the Node.js Git repository, but these files don’t allow the QML/JS plugin to infer the types of the methods. They are also fairly big and would need a big cleanup in order to be fast enough to parse.

    As with ECMAScript, I solve the problem by shipping with QML/JS stripped down versions of those files. These files describe the classes, methods and attributes of each module, and follow a very simple format. This code is not designed to be run, only to be parsed by the QML/JS plugin, that will discover the types of the function parameters and their return type.

    1 2exports.spawn = function (command, args, options) { return new exports.ChildProcess(); }; exports.spawn("", [], new Object());

    Writing all these files is tiring and will take some time (in fact, I’m writing them for a bit more than one day, now). So, there may be fewer commit than usual in the QML/JS repository, but I hope that this feature will serve many users. Here is a teaser of what is coming (note that functions are now listed in a way more human-friendly form):

    Once this feature is finished, I will concentrate my efforts on the QML code-completion. I’ll also experiment with the KDE Frameworks 5 (and the KF5 version of KDevelop), because I’d like to offer a KF5 version of the QML/JS plugin. The reason is twofold: Qt5 offers the wonderful QtQuick.Controls module (it will allow me to implement many navigation widget, that will assist the users in choosing a font family, configuring and previewing animations, etc), and early KF5/Plasma5 adopters may be well pleased to be able to use the latest and greatest KDevelop on their latest and greatest environment, while still being able to work on QML and Javascript files.

    UPDATE: Here is an additional screenshot that shows that child_process.ChildProcess is correctly recognized, and that it correctly inherits from event.EventEmitter (you see that addListener is in the list), which in turn inherits from Object (there is an “assign” method at the very bottom of the list). Having all of this working was a bit more difficult than expected, but now function prototypes and class inheritance seem to work.

    Categories: FLOSS Project Planets

    A wild "monday" report appears …

    Thu, 2014-07-24 15:32
    Arguably our insanely-coolest member, Philipp Stefan contributed this "monday" report.Yes, it has been some time since the last entry, but with the Plasma 5 release and Jens’ busy work schedule there hasn’t been much time for him to write one, unfortunately. I hope I can keep you up to date more regularly from now on. So let’s dive right in:

    What’s being worked onThe work on revisiting and expanding the Human Interface Guideline on tooltips has begun. If there’s something that has always bothered you about how tooltips in KDE Applications and Plasma look and feel consider to join in. The work is still in its early stages, so now would be the best time to voice your concerns. []

    Martin Gräßlin has started to work on a new window decoration API for KWin and is also working to port the Breeze window decoration to C++. This should bring the necessary performance boost to make Breeze the default window theme in future releases. We can also expect one feature many love in Oxygen to be present in the new Breeze implementation: window tabs. The awesome community member EraX has stepped up and made some mockups of how window tabs could look like in Breeze.

    If you have other ideas and feedback, consider to chime in!Additionally Martin has created some tasks you can take up to help us out porting Breeze to C++. Take a look at Martin’s blog post for more information []

    Behind the scenes Jens Reuteberg and Heiko Tietze has started to collect information for animation guidelines. If you have an expertise in this area or are just generally interested and want to help us out try to contact them. []

    We migrated to KDE’s new todo-board infrastructure, It’s really nice having everything consolidated in one place and accessible with one’s KDE-Identity account. In future we also hope to migrate away from Google Docs and Hangouts. We have been looking into something like an OwnCloud installation to create, share and store documents. Nothing is written in stone though and frankly we’ve got more important things to do right now.  

    What has been overlookedWe have noticed that the participation rate in the VDG forums has plummeted and only a small core has remained, which are doing awesome work! It has to be expected that participation rates decline at the end of every release cycle, when all the work gets finalized there’s not much to be discussed after all. Nethertheless, we’d like to recreate the same experience we had with the KMyMoney, the window decoration, the widget and the cursor theme.We identified several causes that could have contributed to the decline in participation:
    • Back then the VDG forum was new – people simply got disinterested over time
    • The VDG hasn’t communicated as much as in the beginning – the process became less transparent
    • There has not been as much guidance in where to start helping out as in the beginning
    We try to address these issue better from now on. We have reorganized ourselves a bit, so you can expect more blog entries from more VDG members in future. We also intend to open new “challenges” (not in the sense of a contest) at the beginning of each release cycle where the community can participate in.Please tell us if you have ideas how we can foster a more vibrant design community in KDE, critique happily appreciated. We also have a thread in the forums about a related issue. If you feel the same way consider to leave a comment.
    Overall I can only encourage you to browse the VDG forum. There are many interesting threads that could need some community love.
    Categories: FLOSS Project Planets

    Kate “master” branch now KF5 based!

    Thu, 2014-07-24 14:18


    from today on, the master branch of kate.git is KF5 based.

    That means, for the next KDE applications release after 4.14, Kate will use the awesome KF5 stuff!

    The KTextEditor framework is already in a good shape and most active KatePart development is since months pure KF5 based.

    The same should now be true for Kate itself (and KWrite).

    Pâté will need a lot of love, as PyQt5 is there, but PyKDE5/PyKF5 still in the works.

    Happy hacking, help us to make KF5 based Kate awesome, too.

    For 4.14: keep fixing bugs, but all new shiny stuff that might regress things really should only go into our KF5 based master branch!

    Categories: FLOSS Project Planets