Planet KDE

Syndicate content
Planet KDE - http://planetKDE.org/
Updated: 1 day 1 hour ago

Barcelona, such a beautiful horizon

Mon, 2014-07-21 15:22
KDE Project:

When life gives you a sunny beach to live on, make a mojito and go for a swim. Since KDE has an office that all KDE developer are welcome to use in Barcelona I decided to move to Barcelona until I get bored. So far there's an interesting language or two, hot weather to help my fragile head and water polo in the sky. Do drop by next time you're in town.


Plasma 5 Release Party Drinks

Also new poll for Plasma 5. What's your favourite feature?
Categories: FLOSS Project Planets

What is preloading?

Mon, 2014-07-21 06:38

by Jakub Hrozek and Andreas Schneider

The LD_PRELOAD trick!

Preloading is a feature of the dynamic linker (ld). It is a available on most Unix system and allows to load a user specified, shared library before all other shared libraries which are linked to an executable.

Library pre-loading is most commonly used when you need a custom version of a library function to be called. You might want to implement your own malloc(3) and free(3) functions that would perform a rudimentary leak checking or memory access control for example, or you might want to extend the I/O calls to dump data when reverse engineering a binary blob. In this case, the library to be preloaded would implement the functions you want to override with prelinking. Only functions of dynamically loaded libraries can be overridden. You’re not able to override a function the application implements by itself or links statically with.

The library to preload is defined by the environment variable LD_PRELOAD, such as LD_PRELOAD=libwurst.so. The symbols of the preloaded library are bound first, before other linked shared libraries.
Lets look into symbol binding in more details. If your application calls a function, then the linker looks if it is available in the application itself first. If the symbol is not found, the linker checks all preloaded libraries and only then all the libraries which have been linked to your application. The shared libraries are searched in the order which has been given during compilation and linking. You can find out the linking order by calling 'ldd /path/to/my/applicaton'. If you’re interested how the linker is searching for the symbols it needs or if you want do debug if the symbol of your preloaded library is used correctly, you can do that by enabling tracing in the linker.

A simple example would be 'LD_DEBUG=symbols ls'. You can find more details about debugging with the linker in the manpage: 'man ld.so'.

Example:

Your application uses the function open(2).

  • Your application doesn’t implement it.
  • LD_PRELOAD=libcwrap.so provides open(2).
  • The linked libc.so provides open(2).

=> The open(2) symbol from libcwrap.so gets bound!

The wrappers used for creating complex testing environments of the cwrap project use preloading to supply their own variants of several system or library calls suitable for unit testing of networked software or privilege separation. For example, one wrapper includes its version of most of the standard API used to communicate over sockets that routes the communication over local sockets.

Categories: FLOSS Project Planets

Updated xorg, linux kernel, systemd and graphics driver groups of packages move into the stable repositories

Sun, 2014-07-20 17:28

This move includes updates or rebuilds of the packages that are related to xorg, the linux kernel and graphics drivers, as well as various other packages that were updated in the meantime and are made available now. In total, more than 400 packages are moving to stable.

Notable updates:

  • xorg-server 1.15.2
  • linux 3.15.5
  • systemd 214
  • mesa 10.2.4
  • calligra 2.8.5
  • qt 5.3.1
  • nvidia 337.25
  • catalyst 14.4
  • xf86-video-ati 7.4.0
  • digikam 4.1
  • libmtp now includes Jolla phone/Sailfish OS support.

    Please note that the mesa package was splitted in the following packages: mesa-libgl, opencl-mesa, ati-dri, intel-dri, nouveau-dri, svga-dri. libgl is now provided by the corresponding mesa-libgl, nvidia-libgl or catalyst-libgl package. Pacman should be able to resolve dependencies correctly once you perform the update, so that the appropriate libgl package is installed. The nvidia-bumblebee package has been replaced completely by nvidia. The bumblebee package now provides the corresponding nvidia-libgl. So nvidia users with optimus technology should install mesa-libgl, nvidia and bumblebee to use their hybrid card.

    It should be safe to answer yes to any replacement question by Pacman. If in doubt or if you face another issue - please ask or report it to the related forum thread.

    As always, make sure your mirror is fully synced 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

    My way to develop with git in KDE repos

    Sun, 2014-07-20 15:07

    From time to time there is the discussion of which workflow is better to develop with git, etc.

    I'm not going to try to convince anyone on which workflow to use, i'm just going to explain what i do and explain why i think it's useful (and even more in the multi-developer KDE environment).

    Let's picture the scenario we had a few days ago where there were lots of projects with three "live" branches, i.e. KDE/4.13, KDE/4.14 and master.

    What is my way to develop?
    * Bugfixes go to oldest "live" stable branch
    * Features go to oldest "live" non frozen branch
    * Branches are merged up

    So let's say that I develop a new feature to support a whole new document format to Okular. Since that is a new feature it would go to the "oldest live non frozen branch", that in this case was master since KDE/4.13 and KDE/4.14 where already feature frozen. So I commit it to master and then "Branches are merged up" which in this case means nothing since there's no branch "up" from master.

    Now let's say there's a crash bug when opening a file with three monitors. Since that is a bugfix, it'd go to the "oldest live stable branch", that in this case would be KDE/4.13. And then "Branches are merged up", so i would mean 4.13 into 4.14 and after that 4.14 into master. Ensuring that 4.14 and master also have the bugfix.

    I think that this is a very useful way of developing using git branches for a lot of reasons, but the biggest of them is that for a random person it is easy to know if a "branch high in the hiearchy" has all the bugfixes or not, he just have to go to KDE/4.14 and to "git merge origin/KDE/4.13", if no change is brought over, it means that for sure all the bugfixes and code that was in the 4.13 release will be in the 4.14 release, otherwise it is hard to know.

    So now that 4.13 is not going to be released anymore and 4.14 is a very young fork of master, i suggest that for every push you do to KDE/4.14 you go to the master branch and merge origin/KDE/4.14. This way you will have a master that is always fully merged with 4.14 and a third party person looking at your code (like the release manager) won't have to worry if it contains all the code or not.

    Happy hacking!

    And of course if you disagree with me, that's fine, not that i'm happy if my reasons did not convince you :)

    Categories: FLOSS Project Planets

    QML binary modules

    Sun, 2014-07-20 09:32

    Developing a new project is usually done in two phases: first, the most important features are added, and the feature list of the project quickly grows. Then, the features need to be polished, bugs fixed, and the overall usability of the project improves slowly. This second phase is often considered less interesting than the first one, but personally, I like to fix small annoyances. Fixing them makes the difference between an experimental project and one that can be reliably used by real users.

    During this GSoC, I try to work in small steps, implementing a big feature and then improving it, then implementing the next feature, and so on and so forth. This works quite well and allows me to keep a high motivation in what I’m doing: implementing a big feature is exciting but also exhausting, and improving existing features mainly consists of many small and easy commits that each have a noticeable effect. This week, I’ll talk about one major feature and several small corrections that I’ve implemented for the KDevelop QML/JS language plugin.

    The fixes

    Javascript has no syntax to express that “this function is a member of this class”. It is not directly possible to use something like function Class.method() as in C++. Developers are therefore obliged to declare class methods using function expressions:

    1Class.prototype.method = function (a, b) { return a + b; };

    The fact that method is assigned a function has an annoying implication for the QML/JS plugin: when method is declared, it is a simple variable, a member of Class that can contain anything (a function, an integer, etc). This means that method is declared as a Declaration, not a ClassFunctionDeclaration. This is not really a problem, but this prevents KDevelop from displaying the right icon alongside the methods:

    The solution is quite simple: when a Declaration has a function type (when it is actually a function), then the QML/JS plugin ensures that a function icon is displayed. An icon may seem unimportant, but such a bug is very easy to fix (one or two lines), and not fixing it would have immensely annoyed all the users of the plugin.

    The other small feature that I’ve added is support for the __proto__ member of Javascript object instances. This member is used by several Javascript libraries and may also be used in a couple of QML files, so it is not going to be useless:

    Other small bugs have been fixed. For instance, in a QML file, typing ANamespace. lists the components declared in the namespace, and nothing else (previously, there was some garbage, for instance the namespaces imported by ANamespace, or the built-in Javascript classes). Code-completion for import statements is now way more useful, but more on that later.

    Binary QML module imports

    Back to the QML world. The goal of my GSoC is to have the best possible QML support in KDevelop, because KDevelop is already the best-in-class IDE for C++ Qt development, and only lacks a good QML support. Javascript, on the other hand, already has many great IDEs and competing with them may be a bit out of the scope of a GSoC project.

    My strategy to have great QML support in KDevelop is to concentrate most of my efforts on this language, while still having a robust enough Javascript support so that Javascript snippets in QML files work as expected. For instance, Javascript built-in classes were added because many of them are used in QML files.

    So, this week was dedicated to importing QML binary modules and QML installed modules. First, some definitions:

    • QML installed module: QML module that is installed on the user’s system, for instance by a KDE package. Unfortunately, QML does not have system-wide include paths as Python and Ruby do, each QML application provides its own search path. Luckily, most QML applications either use only Qt-provided modules (and they have been supported for a long time now), or use KDE-provided ones. KDE installs all its modules in /usr/lib(64)/kde4/imports, so they are quite easy to locate. An installed module consists of a directory that contains .qml files and possibly .so files. The library files (that can be mixed with plain .qml files) contain additional native components, implemented in C++.
    • QML binary module: Library that contains QML components. The .so files I was talking about hereabove are QML binary modules.

    Supporting QML installed modules was quite easy: KDE’s KStandardDirs allows me to easily locate them, and the infrastructure for importing whole directories was already in place.

    Binary QML modules were a bit more difficult because they need to be dumped before the QML/JS plugin can use them. Dumping a binary module file is the action of running qmlplugindump on them, a tool provided by Qt that takes a .so file and writes a QML module file for it. The QML module file is a valid QML file and can be parsed by the plugin.

    With directory imports working, binary QML modules dumped and the dumps correctly parsed, the all the pieces fit together:

    Uh oh! A .so file!

    Enter qmlplugindump (the file is cached for later reuse)

    Components exported by Plasma Core

    Members of a binary QML component

    Finally, as an added bonus, I’ve improved the code-completion for import statements. They now list only the imports that start with what the user has already typed, and they handle installed modules:

    Testing the QML/JS plugin on real QML files has shown that QML is very nicely handled, even if there are still some small glitches (for instance, several built-in QtQuick 1.0 types and properties are still missing). Sven Brauch will also send me a list of places where the code-completion could be more useful. In fact, don’t hesitate to tell me which features you would like to see implemented, I’ve still four weeks ahead of me!

    Categories: FLOSS Project Planets

    What’s new in KF5 porting script: convert-kdialog.pl

    Sun, 2014-07-20 07:16

    When we want to remove kdelibs4support there is a class which is used by all kde application: KDialog.

    Each time that we wanted to create a dialog we used it.

    So it’s necessary to have a script to help us to port to QDialog now that KDialog is deprecated.

    When we port to QDialog, we need to add a QDialogButtonBox and mainwidget (if necessary)

    As in kdepim there is a lot of KDialog I created a script for it.

    It was not very easy to create it, but this script help me to port some kdialog.

    But unlike others scripts that we can launch them on source file and just compile and adapt if necessary, which this script we need to look at diff to be sure that all is ok.

    But I hope that it will help us during kf5 porting.

    I continue to fix this script and add new porting code when I found it in kdepim.

    But you can send me mail when you see a bug.

    Categories: FLOSS Project Planets

    bringing green processes to Qt

    Sun, 2014-07-20 02:01

    I've begun prototyping a system for green processes in Qt applications. I'm not yet at the code-writing stage, but the API is definitely taking shape and a design is starting to emerge. It's a spare-time project for me, so is progressing at a reasonable but not extremely fast pace.

    I've gotten to the point where early-stage feedback from people who are interested in such a framework would be very valuable in polishing the design a bit more before laying down code. As such, I'm looking for 4-6 people to collaborate with at this early stage.

    If you are interested in using green processes in your Qt application, or are simply interested in new application development patterns for Qt, and you have 20-30 minutes per week to look at API drafts and provide feedback and and/or add to the ideas that are coming together, please email me (aseigo at kde.org).

    Categories: FLOSS Project Planets

    Plasma Active on QT5/KF5

    Sat, 2014-07-19 11:52

    Hello, this is my fourth report for my GSoC. This week I have ported the Panel for Plasma Active. The UI of the Active Panel has not changed much. As you can notice some of the Plasmoids are missing because they have not been ported yet (like the Homescreen Plasmoid), but there is no missing functionality from the Panel. Also the notification icons are  invisible while they are inactive, as this is the expected behavior.

     

     

    You can find us on #plasma or irc.freenode.net


    Categories: FLOSS Project Planets

    SFLPhone-KDE 1.4.0 released!

    Fri, 2014-07-18 18:24

    Savoir-faire Linux is proud to announce the immediate availability of SFLPhone 1.4.0. This release finally enables video by default. We have refactored the video implementation to be much more robust against a variety of conditions and made the configuration more flexible. It is also now possible to stream a variety of file types and even share your screen. Other interesting features include support for the JACK audio system used by audio industry professionals and hobbyists. Thanks to improvements in audio buffering, latency and resampling, audio quality is noticeably better. The KDE client now has much better Akonadi support. It can now act as a KAddressBook replacement for most phone related scenarios. There will probably be one final KDE4 release before officially making the switch to KF5. The SFLPhone-KDE logic backend, libqtsflphone, has been compatible with Qt5 for over a year, some of the UI dialogs have yet to be ported. As for SFLPhone in general, we plan to merge work that has been done in parallel for a while now to make the daemon more modular, easier to build, more secure and more portable to other operating systems.

    Please update or comment on this ticket to add user noticeable changes and new features

    Common features
    • Jack support
    • Video support by default
    • Ability to share screen
    • Ability to stream videos, images and text files
    • Support GnuTLS as an alternative to OpenSSL
    • Persistent camera configuration (per device)
    • Switch video sources during a call
    • Enable or disable video per account
    • Packet loss concealment
    • RTCP support
    • Builds with clang
    libqtsflphone
    • Pluggable history storage
    • Improved pluggable storage backends
    • Datasource extensions support
    KDE client
    • Now a fully featured contact manager
      • Add, edit and manage contact sources
      • Delete contacts from the interface
      • Attach contact sources to auto completion or presence tracker
    • Basic video effects like rotate or enforce aspect ratio
    • Video full screen mode

    Stats

    KDE client:   203 files changed, 10979 insertions, 3933 deletions, 102 commits, 36 issues closed, 19 bugs closed
    Daemon: 256 files changed, 14448 insertions, 9781 deletions, 628 commits, 543 issues closed, 214 bugs closed

     

    Get SFLPhone-KDE

    Kubuntu packages are available at: https://launchpad.net/~savoirfairelinux/+archive/ubuntu/ppa

    The source get be obtained from  git://anongit.kde.org/sflphone-kde or from http://sflphone.org .


    Categories: FLOSS Project Planets

    After the Kickstarter...

    Fri, 2014-07-18 09:04

    Running a kickstarter is very much like, well, running! Running for thirty solid days. So the weekend after the Kickstarter ended, all of us slacked off a bit, and instead of coding we did some coding! Within a week or so, the Kickstarter should be finalized, the money in our bank account and we can start opening up the surveys for the backers! We didn't reach the stretch goal that would let Sven work full-time on Krita, so the feature survey will be "Choose and Rank 12 out of 24". Dmitry is already looking into 3D transformation stuff, so let's hope that feature won't get voted out! You could also still donate to Krita, either directly, or through the rewards-enabled paypal button:

    Reward Selection Donate €5,00 EUR Postcard €15,00 EUR Postcard and stickers €25,00 EUR Digital Download of the Muses DVD €50,00 EUR USB Stick with Krita €100,00 EUR Comics with Krita DVD plus signed comic €150,00 EUR Dedicated Tutorial by Wolthera €250,00 EUR Pick your own priority €750,00 EUR A month of dedicated development €2.500,00 EUR

    Yiynova Europe noticed the kickstarter and contacted us -- they loaned us two Yiynova tablet monitors, the 19" MSP19u and the the 21,5" MVP22u to test Krita with. We already had a bug report about multi-monitor setup with other tablets than a Cintiq, so this was very welcome! And today there's a new experimental build that works just fine!

    This build also contains Dmitry's new memory pool code. Krita should now be a bit faster and use less memory while painting, and especially, be better behaved with longer painting sessions. Please do test! As developers, long painting sessions isn't something we can regularly indulge in!

    As for OSX, I cleaned up a lot of warnings and (probably...) fixed the available memory detection, so Krita can use more than 1GB before it starts to swap. Also, all brush engines are now available! I'm still in two minds about the OSX port, though. I will need at least a month to make a nice beta, at least two months more to get it ready for end-users... This is all coding, and maybe build two, three more dependencies.

    In other news, Scott Petrovic has been really busy working on a new look for krita.org. This week, together with KDE's wonderful sysadmin team, a development version of the site went life. Read all about it on the Krita forum! There's even a link there to the development version of the new website!

    Categories: FLOSS Project Planets

    After the Kickstarter...

    Fri, 2014-07-18 09:04

    Running a kickstarter is very much like, well, running! Running for thirty solid days. So the weekend after the Kickstarter ended, all of us slacked off a bit, and instead of coding we did some coding! Within a week or so, the Kickstarter should be finalized, the money in our bank account and we can start opening up the surveys for the backers! We didn't reach the stretch goal that would let Sven work full-time on Krita, so the feature survey will be "Choose and Rank 12 out of 24". Dmitry is already looking into 3D transformation stuff, so let's hope that feature won't get voted out! You could also still donate to Krita, either directly, or through the rewards-enabled paypal button:

    Reward Selection Donate €5,00 EUR Postcard €15,00 EUR Postcard and stickers €25,00 EUR Digital Download of the Muses DVD €50,00 EUR USB Stick with Krita €100,00 EUR Comics with Krita DVD plus signed comic €150,00 EUR Dedicated Tutorial by Wolthera €250,00 EUR Pick your own priority €750,00 EUR A month of dedicated development €2.500,00 EUR

    Yiynova Europe noticed the kickstarter and contacted us -- they loaned us two Yiynova tablet monitors, the 19" MSP19u and the the 21,5" MVP22u to test Krita with. We already had a bug report about multi-monitor setup with other tablets than a Cintiq, so this was very welcome! And today there's a new experimental build that works just fine!

    This build also contains Dmitry's new memory pool code. Krita should now be a bit faster and use less memory while painting, and especially, be better behaved with longer painting sessions. Please do test! As developers, long painting sessions isn't something we can regularly indulge in!

    As for OSX, I cleaned up a lot of warnings and (probably...) fixed the available memory detection, so Krita can use more than 1GB before it starts to swap. Also, all brush engines are now available! I'm still in two minds about the OSX port, though. I will need at least a month to make a nice beta, at least two months more to get it ready for end-users... This is all coding, and maybe build two, three more dependencies.

    In other news, Scott Petrovic has been really busy working on a new look for krita.org. This week, together with KDE's wonderful sysadmin team, a development version of the site went life. Read all about it on the Krita forum! There's even a link there to the development version of the new website!

    Categories: FLOSS Project Planets

    Geogebra Tool Support in Kig

    Fri, 2014-07-18 09:00

    Hello !!  In this post I will be describing my latest progress in the Geogebra Filter that we are creating for Kig. After a lot of hiccups, it finally seems that we have found a proper implementation which smartly handles both Geogebra worksheets and Geogebra tools. Although the planning had been done a long time […]

    Categories: FLOSS Project Planets

    New scripts to help to port to KF5

    Fri, 2014-07-18 03:44

    As I continue to work to kdepim* KF5, I need more scripts.

    As kdepim has a lot of code to port, I don’t want to make all by hands.

    So what’s new ?

    • convert-ktextbrowser.pl, it allows to convert KTextBrowser to QTextBrowser (which warning about not supported feature “The only difference is QTextBrowser does not support “whatsthis:” urls.”))
    • convert-kvbox.pl, this scripts helps you to convert K/VBox to QWidget + QH/VBoxLayout
    • convert-kshortcut.pl, now we use QKeySequence

    I fixed some scripts too as adapt_cmakelists_file.pl (add more convert cmake variable name), convert-kstandarddirs.pl (Add more convert code) etc.

    A script that I didn’t write “resolve_kuit.py” is very useful to fix i18n. Just launch it as “resolve_kuit.py -x .” in directory

    I started to look at script to port KDialog to QDialog but not really easy, not sure that all code will port directly.

    I am happy because I saw that several projects used my scripts (As Konversation, kstars and I think others )

    I will continue to create script when I need to convert class.

    If you have code to port you can send me a testcase and I will try to create script.

    I think it’s very important for kde to have more script to help to port to kf5

    Categories: FLOSS Project Planets

    KDecoration2 – The road ahead

    Fri, 2014-07-18 03:17

    Yesterday I blogged about why Breeze is not the default window decoration in KWin 5.0. The blog post touched a little bit the problems with our decoration API. In short: it’s QWidget based and that doesn’t fit our needs any more. It uses a QWidget as an X11 window. At the same time KWin intercepts the rendering and also input handling, redirects it and forwards it. So why use a QWidget at all? Also using a QWidget is quite a memory waste in the Qt5 world. The QWindow behind the QWidget uses a QXcbShmImage with the same size as the window. As explained in yesterdays blog post the window has the size of the managed window plus the decoration. So for a maximized window we hold an image of the size of the complete window while we just need the titlebar strip. We can do better

    Our decoration API is also showing it’s age. It’s cumbersome to use, too difficult to use. In fact there is a KDecoration and a KCommonDecoration – the latter trying to make KDecoration easier to use by for example providing buttons. The API got extended several times to support more features which are all optional. The API is difficult to use from KWin side as it’s not stateful and quite often needs to call into the decoration API calling virtual methods the decoration API provider needs to implement. Last but not least it’s difficult to test new decorations as we don’t have a dedicated viewer application to test the interaction and painting. You have to kind of use KWin as the development host. Not the best solution.

    The idea for a new API had been in the room for a long time. I opened a bug report for it more than two years ago. Last week I finally started with the implementation and tackled three things at the same time:

    • New decoration API
    • Viewer application
    • Breeze decoration

    In the current state it looks like this:

    The outer decoration is the existing Aurorae theme. It looks already quite good, but there is of course still lots of work to do. The API is not yet feature complete, it needs implementation in KWin and Breeze needs a pixel perfectionist to get it right (which I am not). And that’s where you can help! Thanks to our sysadmins we have a new todo board and I requested a project for KDecoration2 and prefilled it with very easy tasks. This is a wonderful opportunity to work on easy and new code and helping both KWin and the Visual Design Group achieving an important new step. Without your help we won’t have this in 5.1 and it would be so important for both KWin and the overall design of the Plasma desktop. So please grab the code and start hacking. Grabbing the code, where? The new decoration API can be found in the git repository kde:kdecoration, the viewer application in git repository kde:kdecoration-viewer and the new Breeze window decoration in git repository kde:breeze in branch “graesslin/kdecoration2″.

    So what makes KDecoration2 better? Obviously it’s no longer QWidget or QWindow based. Instead it’s a pure QObject based API. It provides a paint method a plugin needs to implement which gets a QPainter passed into. This allows KWin to control the rendering and to render to the best suited backend for the current compositor (e.g. just a QImage or a Shm shared pixmap). Also the input handling will be controlled from the backend side by sending appropriate events to the decoration. The API takes care of all of the handling – activating the buttons forwarding title bar presses, etc. This alone makes the API hopefully much easier to use from plugin side. It also provides the base implementation for all the required buttons, so that the decoration only needs to provide the painting of the buttons. Simplified the API looks like the following:

    There’s an additional singleton DecorationSettings which provides common settings for the decoration. Also there’s an additional second private API which must be implemented by a backend. This will allow us to use KDecoration2 in multiple places. I want to see it uses in KWin, but in future I’d also like to provide our decorations for QtWayland. For this I hope that KDecoration plugins can also be a solution.

    Categories: FLOSS Project Planets

    Changing Font and Icon Size from settings

    Thu, 2014-07-17 23:32

    Now you can change font and icon size, from digiKam configuration, and changes will be shown immediatly.

    Take a look to the screenshot:


    Categories: FLOSS Project Planets

    Barcelona Plasma and KDE Frameworks 5.0 Release party

    Thu, 2014-07-17 14:29
    KDE Project:

    Barcelona Free Software Users & Hackers are having a Barcelona Free Software Users & Hackers mañana, see you there!

    Categories: FLOSS Project Planets

    Konversation goes Frameworks 5

    Thu, 2014-07-17 10:37
    KDE Project:

    The Konversation team has started porting the application to Frameworks 5 earlier this month, getting things to build and run on top of KDE's next-generation libraries.

    Here's all the info you should need to help out.

    At this stage of porting there are still hundreds of low-hanging fruit (porting away from deprecated APIs, porting to slightly changed APIs, etc.) that don't require extensive knowledge of either the codebase or even the problem space to tackle, so if you were looking to get your feet wet on Frameworks 5 or KDE development in general, consider chipping in!

    In fact, one of the major risks associated with any porting is lowering the quality of the application by reducing functionality or just plain breaking things, and of course we'd like to avoid both. So you can even help out by just running the port and logging the things that don't work on KDE's bug tracker (handy link is on the wiki) as tasks for others to jump on.

    Categories: FLOSS Project Planets

    Plasma 5.1 Kickoff

    Thu, 2014-07-17 10:08
    KDE Project:

    We had a fun two hour meeting in #plasma yesterday to decide on the tasks for the next release. It's due out in October and there's plenty of missing features that need to be added before Plasma 5 is ready for the non-geek.

    Previously Plasma has used wiki lists to manage the Todo list but this is very old-school and clunky to manage. Luckily Ben the KDE Sysadmin has just finished saving some children from a burning building before he swooped in and set up
    todo.kde.org just in time for us to add some 30 Todo items.

    There will also be a meeting next week to discuss Wayland action items, come along if you want to help Martin shape the future.


    Plasma 5.1 Todo list

    Meanwhile former tabloid rag turned bastian of quality journalism OMGUbuntu said
    KDE Plasma 5 Arrives with Fresh New Look, True Convergence
    . More nice comments: "I tested the neon iso yesterday and it looks absolutely stunning!".

    I'd like to thank Scarlett for putting in loads of hours perfecting the KF5 and Plasma 5 packages and now Rohan is tidying KF5 up and uploading to the Ubuntu archive.

    Categories: FLOSS Project Planets

    Why Breeze is not the default window decoration

    Thu, 2014-07-17 09:35

    This week we finally released Plasma 5.0 including KWin 5.0 and also a new design called “Breeze”. While Breeze provides a window decoration, KWin still defaults to Oxygen and that’s for a good reason. As I had been asked quite often why that’s the case and on the other side got lots of feedback from disappointed users using the Breeze decoration I think it’s needed to explain in a blog post the technical background.

    I start with explaining how our window decorations work in KWin 4. KWin is a so-called re-parenting window manager. This means the managed X11 window is put into another X11 window providing the windwow frame. In KWin we use a QWidget for the window frame. Thus we are also restricted to what QWidget provides us. Our window decoration API predates the Compositing support and this adds quite some restrictions to it. Our solution is to intercept all paint events on the decoration’s QWidget and suppress it, trigger a repaint of the compositor and in the rendering pass ensure the decoration widget repaints to a temp image which then gets copied into a texture to be rendered by the Compositor.

    The Breeze window decoration theme is based on the Aurorae theme engine. As I’m the main author of Aurorae I can bash it in this blog post without feeling sorry about it Aurorae was designed to make it very easy to style a decoration and to make use of the new added translucency features. Being a solution which could be used as a default decoration was never the aim. The idea was to allow users who want the customizability this feature while the majority of the users could use the faster native themes. Aurorae was never fast and will never be fast. Over the time the performance improved, especially thanks to using QML. But also in that case it was only usable with the raster graphics system in KWin 4 times.

    Now in KWin 5 the usage of QML is the main problem which makes it difficult to use Aurorae at all. QtQuick uses the SceneGraph and uses QWindow instead of QWidget. That’s quite a bummer for our QWidget based API. We adjusted the internal usage to support QWindow based decorations but that was quite a tough road as there are differences in the behavior of the windows. As it’s no longer QWidget based our interception of paint events is broken and we needed a new solution for it. And this solution is even more ugly than the old one because QtQuick is nowadays rendering through OpenGL. Due to limitations in Qt’s OpenGL implementation (might be addressed in Qt 5.4) we cannot share with the OpenGL context used by QtQuick. But we need to get the content from the Aurorae window into our OpenGL texture. The solution is to render to a QOpenGLFrameBufferObject and read it back into a QImage just to upload back to a texture. Not only is this a huge overhead to copy the content from GPU to RAM and back to GPU it’s also wasting lots of memory. The frame buffer object has the same size as the window and that’s way larger than the actual window decoration. In case of a maximized window it’s not just the title bar area but the complete window. And that overhead exists for each window.

    That alone might render Aurorae completely unusable. I’m currently using the Breeze theme and KWin needs more than 200 MB of RAM – not really acceptable. But the situation is even worse. With QWindow we don’t get to know which areas got updated. So whenever e.g. a button gets updated we have to repaint the complete window including the complete copy of the decoration content. Which especially in animation situations is quite a problem.

    The last problem to mention is OpenGL. QtQuick is supposed to use a dedicated rendering thread, but Qt disables that for all Mesa drivers and instead uses the main thread. But that’s also the thread KWin’s compositing OpenGL context lives in. That’s quite a performance problem and also introduces lots of instability problems (might also be addressed in Qt 5.4).

    Overall the situation is so bad that colleagues recommended to disable Aurorae overall in the 5.0 release. As we released with it you can see that I disagree in that point. There is hardware where it’s working quite fine – on my system it doesn’t matter that it uses lots of RAM and if your driver supports Qt’s threaded rendering the performance problems are mostly gone and also all stability problems are gone. So the situation hasn’t changed: for users who want to customize there is a solution but it might introduce a loss of performance. But as a default theme like Breeze it’s clearly not an option.

    So what’s the road forward? I started implementing a new decoration API removing the restriction of the decoration being QWidget based and at the same time I started implementing the Breeze decoration with this new API. I hope that we can introduce this in KWin 5.1. I’ll write another blog post about it soon and also prepare lots of small and easy tasks for new developers to join in this effort and help making a kick-ass decoration solution for 5.1

    Categories: FLOSS Project Planets

    The Great Merging day

    Thu, 2014-07-17 09:27

    I’ve just merged the dev branch to the master, and soon you will see the new features inside digiKam 4.2.0

    We are waiting for your opinion, and you are welcome to suggest any changes :)


    Categories: FLOSS Project Planets