Posted on

House Cleaning in KWin 5

We are currently approaching the release of the first alpha version of KWin 5. This is of course a significant milestone and we have put lots of work into the transition to ensure that it’s already working quite fine. With such a big migration it is also important to not only work on new cool stuff, but also to do lots of house cleaning.

For example last week the build option for disabling scripting support got removed as we consider scripting as an important and integrated part of KWin. Thus during the house cleaning the build option got removed.

And of course there are areas where we wanted to remove some legacy code for quite some time but never really dared to do. Two years ago I already discussed the costs of supporting the legacy OpenGL 1 compositing backend. Now it was time to re-evaluate the situation.

KWin 5 is a strong user of QtQuick 2. In fact almost all user interface code is written with this new framework – be it the close button in Present Windows, the window switcher or (since today) the outline shown when using quick tiling/maximization. QtQuick 2 uses an OpenGL (ES) 2 powered scene graph thus KWin already has a runtime dependency on OpenGL 2. And in opposite to our Compositor this is a required dependency. While it has always been possible to disable the Compositor (and that won’t change for X11), it is not (yet) possible to disable the OpenGL usage of QtQuick.

Thus we have to ask whether it’s still worth keeping a code path for legacy hardware, if we require newer hardware. Combined with all the problems mentioned in the above linked blog post from two years ago it becomes really questionable to keep the code.

After some preparation to ensure that we have a clean cut I pushed today the changes to remove the legacy OpenGL 1 compositor in order to have this change in Alpha 1. We encourage all users who used to run the OpenGL 1 compositor to try with the OpenGL 2 compositor and also with the still supported XRender based compositor. If you run into any severe issues please report a bug (or check whether one has already been reported) and provide the support information. This will help us to iron out any issues, like ensuring that no effects get loaded which are not suited for your hardware. After all the base OpenGL 2 compositor should not be an issue for most hardware. But some effects are more demanding than the compositor itself and those can be disabled automatically. Also we try to keep the impact low. If our logic recommended OpenGL 1 compositing for a specific set of hardware, it doesn’t enforce OpenGL 2 now, but uses the better suited XRender compositor.

Posted on

“KDE5” and Wayland

Recently I have seen many comments by users in the style of “I’m looking forward to the first release of KDE5 because of Wayland”. With every time there is such a comment the chances are that it spreads that the first release of “KDE5” will support Wayland and will result in disappointment when the first release of something ends up on the users’ systems. Thus I decided to write a blog post with clarifications.

As my readers probably know there won’t be a combined release as the software compilation used to be. There are independent ongoing projects around the libraries (frameworks or KF5) the workspaces (Plasma Next) and the applications. These projects have independent release cycles and are not one product. I know, I know, many people will disagree and say that it’s still one. But if we go for this strong simplification both “will support Wayland” and “will not support Wayland” are true.

And thus we enter the area where it is important to make the distinction between the various products and use the correct name. Otherwise people don’t know what you are talking about and it results in confusion.

So let’s look into the different areas. As I have already explained our libraries are getting prepared for Wayland and the first release of KF5 will have Wayland support not on par with X11 support but certainly on par with Microsoft Windows or OS X support.

This means for applications using our frameworks that they will support Wayland as long as they don’t speak X11 directly.

For the workspaces it’s more complex. Our aim for the first release of Plasma Next has never been to fully support Wayland or do the migration to Wayland. We obviously don’t want to create too many construction sides and decided to concentrate on getting everything ported to Qt 5 first before going to Wayland. As we are entering the alpha release state shortly we can be quite certain that the Plasma desktop shell will not support Wayland. Other parts of Plasma Next have a little bit more integration, some systemsettings modules get hidden when running on Wayland, some modules got fixed to not crash, KInfoCenter got some improvements to support the OpenGL module on Wayland and got a new Wayland module. KWin is still in the experimental support stage not yet being a Wayland compositor. Here we might still have some improvements till the final release as Wayland specific code is excluded from the feature freeze. But overall we can quite certainly say that the first release of Plasma Next will not support Wayland.

Posted on

System Tray in Plasma Next

In the past the system tray was implemented using the xembed specification. An application which wants to use the system tray creates a small window which gets embedded into the system tray. This means that the control over this area belongs to the application and not to the desktop shell hosting the system tray.

The result is that each item in the system tray may behave differently. Some set a different cursor, thus the cursor is flickering if you move from one icon to another. Some open/close the application when clicking the icon, some might provide a context menu on right mouse click or interact with further input events. But what is present in all cases is that there is no consistent behavior. From a user experience point of view this is very bad as the users learn that the system is inconsistent and works in an unexpected way.

Some years ago the Plasma hackers started to address these issues by implementing a new specification called Status Notifier. This specification got also adopted in Unity/Ubuntu as the Application Indicator. The new specification addresses the issues outlined above as the control is moved to the hosting desktop shell. This allowed us in Plasma to provide a consistent look and feel by using the monochrome icons and controlling which items to show when.

But still we supported the xembed system tray specification for legacy applications which were not adopted to the new specification. This means that all the issues are still present. It’s still possible that an item behaves completely different because it’s using the legacy protocol.

When we drafted the plans for the new implementation of the system tray in Plasma Next we of course also discussed the future of the xembed based implementation. It was a challenging topic as we want to go to Wayland and obviously an xembed based system tray icon won’t work on a Wayland powered system tray (yes in theory it could work through XWayland). Also getting the xembeded window integrated into our QtQuick based system tray is not the most trivial task.

Also some of the design aspects just don’t work with the legacy system tray. We want to support reasonable dpi and xembed items are hard coded to 22×22 pixels, that’s probably a lot of fun on a high dpi screen. We also want to categorie the system tray items, so that they are logically grouped. For that the status notifiers allow to tell us that it’s an application item and whether it’s currently passive, active or demands attention. This gives the host the required power to properly place the item. But with the legacy system tray we are just lacking this information and don’t really know what to do with an item.

QSystemTrayIcon as xembed in Plasma Current and status notifier in Plasma Next
QSystemTrayIcon as xembed in Plasma Current and status notifier in Plasma Next

When we discussed all these issues it became apparent that we do not want to invest the time in implementing the legacy system for Plasma Next. Nevertheless we do not want to break the functionality of existing applications. So we investigated ways of how we can ease the transition. KDE applications use the status notifier already and most GTK+ applications also use the appindicator library for unity integration, so they just work the way we want it. But for example the QSystemTrayIcon still uses the legacy system on X11. As it’s Qt there is also the QPA-API which allows us to provide Plasma-specific implementations through our platform theme. That’s the approach we decided to go: force any QSystemTrayIcon to use the status notifier API through our platform theme. Unfortunately the QPA-API was not sufficient for our needs and thus we had to extend it, which will be available in Qt 5.3. If Qt base is compiled with X11 support the QPA system is not used at all and the change to fix this slightly missed the 5.3 merge window. The last missing bit to get this work is in our frameworkintegration repository to implement the required API. This is currently under review which means that it will be available once we release our first release of Plasma Next. Though it will take until Qt 5.4 till the feature will be working properly. As a nice side-effect this also adds an implementation for QSystemTrayIcon on Wayland/Plasma.

Although we invested lots of time into making it work as smooth as possible there will be applications for which the system tray icon will not be working. Nevertheless, we decided to not implement support for it as we want to focus on the core and it was not justified to invest lots of time on an implementation only needed for a short period of time. Applications still using Qt 4 will hopefully soon get ported to Qt 5 and then the issue fixes itself. Overall from an end-user perspective this means that nothing really changes. The system tray is still going to work, in fact it will be better as all items can be scaled, themed, behavior adapted to input methods, logically grouped and much more. Nevertheless it’s possible that there are applications which still use the legacy protocol and that will break. In case it’s an open source application it will be easy to fix and we as the Plasma team are happy to help as much as we can. And in any case Plasma is a very flexible framework allowing you to implement an alternative system tray which supports the xembed system tray. It doesn’t have to be the core team which keeps the compatibility with the legacy system.

Posted on

Running frameworks powered applications on Wayland

After I got KWindowSystem to no longer require X11 on Linux I dared to start some of our applications which got ported to frameworks 5 with the magic “-platform wayland” command line switch. And look there: they started and were useable. But there were some obvious problems: e.g. our platform integration plugin was not loaded. But with a small change to Qt 5.3 this problem is solved. Now if you run a Wayland compositor in a KDE session you will get the KDE integration as one would expect. But this just openend a new set of problems: our default QStyle (Oxygen) was crashing any application on startup as it was still assuming that it’s on X11 if compiled with X11 support. Easy enough to fix and now Oxygen works as one would expect.

This experience highlighted an obvious problem: our applications will crash if they are compiled with X11 support and do not perform a runtime check. So I started to hunt down possible crashers in our libraries. In the perfect world there should not be any X11 specific code in the libraries (except KWindowSystems). And luckily our libraries supported non-X11 platforms for quite some time, so all the X specific code should be in HAVE_X11 blocks. So a small reminder for everybody who thinks that we should never have supported Windows in the first place: thanks to Windows support most of our applications just work on Wayland. Have a look at this nice collection of applications which are running just fine on Wayland:

Aus Weston

Right now we have reached a state where I am no longer able to crash applications at random and most applications which I give a try just work. We had a few problems in kde4support which prevented any applications which still used K(Unique)Application to start at all on Wayland and that framework had stronger usage of HAVE_X11 than I expected. Although the framework is deprecated I fixed all the issues I could find in it, to get applications to support Wayland faster. Basically if your application compiles on frameworks it will run on Wayland out of the box. Also thanks to that work our applications will just work on any proprietary windowing system (so no need to be upset that we put more work on e.g. Windows support than on your small pet project). My personal aim is to have Wayland support at least on par with Windows support in our first release of frameworks. Later on we will improve it to get it on the same level as X11 support.

Of course it’s possible that I haven’t spotten all crashes in the libraries yet. And I encourage our application developers to test their applications on Wayland. That’s quite simple in fact: just start Weston (can be nested in the X session) and prepare the setup:

source kf5_env.sh # your kf5 environment variables setup script
unset DISPLAY # to make sure that any XOpenDisplay call will fail
export WAYLAND_DISPLAY=wayland-0 # adjust to whatever you used in Weston

Now all you need is to pass “-platform wayland” to the command line args to start your application on Weston. In case you are using a KApplication and KCmdLineArgs you need to use “--platform wayland” instead. Update: as an alternative one can also export the environment variable “QT_QPA_PLATFORM” and set it to “wayland”. If you run into any problems with it, feel free to ping me on IRC. In case you get your application to crash in one of the frameworks and it’s a crash due to using X11, please report a bug and set me on CC. In case you hit a crash in your application there is a very easy pattern to solve the problem:

#if HAVE_X11
if (QX11Info::isPlatformX11()) {
    // do your X specific calls here
}
#endif

If you are not using QX11Info you can also do:

#if HAVE_X11
if (QGuiApplication::platformName() == QStringLiteral("xcb")) {
    // do your X specific calls here
}
#endif

As you can see it’s performing a string comparison so you don’t want to have that in a code path which gets called often. Recommendation: move it into a member variable which gets initialized only once in app life cycle and also ifdef the variable – no need to do these checks on e.g. Windows. If you have any questions with it, feel free to ask me.

In the workspace module I hit a few crashers in modules which make absolutely no sense on non-X11. The code is too X specific and most likely needs a complete rewrite if we want to have it on non-X11. Of course we don’t want to have modules which just crash in systemsettings. So I introduced a new method to KService to check whether the plugin makes sense on the current Qt platform. This is honored by ::noDisplay() so systemsettings (and also kcmshell5) won’t pick them. To specify one can use e.g.

X-KDE-OnlyShowOnQtPlatforms=xcb

in the plugin’s desktop file. There’s also a “X-KDE-NotShowOnQtPlatforms”.

Posted on

KWindowSystem in Frameworks 5

KWindowSystem is a tier 1 framework which allows to interact with the windowing system. Historically it provided an implementation of NETWM on X11. It provides a NETRootInfo for accessing the global state (all that’s set on the root window) and NETWinInfo for all information about a specific window. The classes have a window manager and client perspective. This is the foundation which powers our window manager and various parts of the desktop shell such as the taskmanager.

On top of those X11-specific classes we have a convenient API KWindowInfo and KWindowSystem which provides a windowing system independent API for our applications. Thus we have different implementations depending of the platform it’s compiled on. On X11 the implementation depends on named NET* classes, on Windows and Mac what makes sense is implemented using the platform specific API.

In the good old days of Qt 4 this was a sufficient solution. If it’s build on unix-like systems we have X11 and we know it’s X11, on Windows it’s Windows and so on. With Qt 5 this no longer works. Just because we built with X11 support doesn’t mean the software will run on X11. Due to the introduction of the QPA it’s possible that another platform is used – most obvious Wayland. But there are more platforms for Linux like Android. With the solution from Qt 4 our applications would just crash as soon as they access KWindowSystem as that tries to interact with XLib/xcb unconditionally.

Over the last weeks I spent quite some time on making sure that KWindowSystem works as expected (that is doing nothing at the moment) when run on Wayland. Just adding a new implementation as in the Qt 4 days is no solution as we want our framework to support both X11 and Wayland at the same time. Otherwise our distributions would have a hard time packaging our software. The approach was to introduce an internal abstraction in KWindowInfo and KWindowSystem and have a platform implementation. This is now done for X11 together with a dummy implementation which is used as a fallback if we do not have an implementation for the currently used windowing system (e.g. Wayland). Unfortunately this has a side-effect: it broke the backend for Windows and MacOS. I don’t feel very happy about it as I don’t like to break the work of others, but I cannot fix it. Windows and MacOS are proprietary systems for which either a license or even specific hardware is required. I do hope that the specific teams will re-add the support till the release of frameworks 5. Please note: at the time of writing this blog post not all patches are merged yet.

A nice side-effect for this work was that I started to write unit tests for KWindowInfo on X11. This is far from trivial as it interacts with X11 and the running window manager. And the test kind of depends on the used window manager. Obviously given that it’s KDE it would make sense to write the test against KWin, but that’s not sufficient for our CI system as kwindowsystem is a dependency of KWin and thus kwindowsystem cannot depend on KWin (not even on runtime). Thus the tests are now performed against openbox on the CI system, but also succeed when running against KWin. They are quite a stress test for a window manager and found one very unlikely crash condition in KWin (of course already fixed).

The framework provides more functionality which is kind of X11 specific. For example there is the KSelectionOwner and KSelectionWatcher which implements a manager selection as described in ICCCM, section 2.8. Again a very important building block for our window manager. While it’s clearly X11 specific code which only gets built if X11 is available, there is no reason to crash if it’s not run on X11. So I went through all of our sources and tried to make sure that it correctly checks whether the runtime platform is xcb. Thus we don’t have to change all applications using it, but can rely on the library not to crash. Still if your application is using these X11 specific functionality I highly recommend to check for the platform as you might run into runtime errors. E.g. claiming a manager selection will fail, don’t rely on it.

As all of this is kind of a requirement to running frameworks based applications on Wayland, I have to do the obligatory screenshot of Kate on Weston:

Aus Weston
Posted on

Plasma sprint in Barcelona

The last week I spent in the BlueSystems office in Barcelona for this years Plasma sprint. It was a wonderful timeing given that we are just approaching the last stages of preparing our first release based on Qt 5 and KDE Frameworks 5. We had some very good discussions and summaries of those can be read in sebas’s blog as well as on the Plasma mailing list.

My main focus for the sprint was obviously KWin and the Wayland port of the workspace. In that area I mostly worked together with Alex. For example we looked at all of the kde-workspace module to figure out what currently expects X11 in an unconditional way. Such code needs either to be ported or at least to be made runtime platform detectable.

Overall I tried to update the team on the current state of KWin/5 and KWin/Wayland and to highlight the next steps. I have some ideas on how to further change KWin/5 and the sprint was obviously a good opportunity to discuss the ideas in person and to get feedback. Of course I will also announce the changes on my bloge once they are implemented.

Some of the overall changes we discussed will also affect KWin. We are considering to split our monolithic kde-workspace module and that would most likely result in an own repository for KWin. This could allow us in future to experiment with more things. One of the ideas I got during the sprint was to do rapid release cycles for KWin once we did the first release on Qt 5 in order to bring the new Wayland code faster to the users.

Our most important discussions in the Plasma teams might have been a look at our tooling and processes. We identified quite some shortcomings and have good ideas on how to address those. And we did not even keep it by just talking we started to implement the changes right at the sprint. An outcome is that we sent summary mails about the discussions to the mailing list. These summaries are intended as blue prints and not as decisons. So anybody can provide feedback and it’s not required to have been at the sprint. We hope that this makes our community way more inclusive.

From the tooling perspective we also had a look at a FLOSS replacement for Trello boards and are quite interested in one of them. If we implement it, this could become a wonderful tool to get the work better distributed and more inviting for the community. It should make it much easier for developers to just go to the board and pick a task. Personally I’m quite satisfied with the experience I made with the Trello board for KWin so far and am glad that KWin could act as an experimental area for this workflow change. I use this opportunity to point out that the Trello board still has a large number of easy tasks and I’m still adding new tasks whenever I find a new one.

Posted on

Retrospection

It’s now almost one year since I started my job at BlueSystem to work full time on KDE software. It’s a perfect time to look back and do some retrospection as well as trying to look into the future.

Of course my focus of work was on KWin, but especially over the last months I worked all over the KDE workspaces. Overall we have achieved a great result. KWin is running in near production-ready quality after the port to Qt 5 and the Plasma workspaces are also in a very good shape already. I tend to mentially compare the experience with the state of Plasma 1 six years ago which was just a few weeks before the first release. We are in a better state and there is still lots of time till we will do our Plasma 2 release.

Without the possibility to work full time on KWin we would not yet have a ready port and I fear the quality would have to suffer. There were many issues which just needed lots of time to break through. Sometimes I had the feeling that I run all day long with the head against a wall just to end up in front of the next wall once I broke through. Luckily such problems are behind us and I’m also kind of proud to have solved those problems.

But not everything this year had been fun. There was one event which seriously affected my work in a negative way. It demotivated me, I needed to spend time on it, it made me spent time on useless issues instead of the important porting. I was attacked and insulted for my opinion – an experience I had never made before and I don’t want to make. Of course it affected me personally and I can see the impact of it. In retrospection it is clear that I nearly got burnt by it and that it affected the way how I worked in the free software ecosystem. I notice that I don’t have any interest in collaboration with other projects any more, that I feel attacked whenever someone disagrees with me on a technical level, I am answering questions in a short and blunt way with tendency to arrogance. I try to avoid discussions, stopped caring for bug reports and are lacking on code reviews. To a certain degree I tried to be on my small island where I can just hack and ignore everything else.

I am wondering how I would have taken the whole situation if I were just a spare time developer. Maybe it would not have affected me at all because the pure thought that I am supposed to add support in my spare time would have been even more ridiculous as it is. Maybe I would not have had the time to do an analysis for the Kubuntu team as I did which then would not have resulted in me getting attacked for it. On the other hand if the attacks and insults would have also happened if I were a spare time developer I don’t think I would still be a KDE developer. For a hobby I would not have endured that.

One of the conclusions is that if it would ever happen that someone submits a patch for Mir support in KWin, I would immediately step down as maintainer. After what happened I am no longer in a position to judge that imperial and objective. I would either accept the patch out of appeasement or reject it due to what has happened. In any way I would not be in a position where I can be sure to do the right decision for the KDE community. Even on a technical level I would not be sure whether I would be able to review it. Being nitpicky about small issues can be done subconsciously and also moving around code just to prove the point is easily done.

Please do not read this as a threat to block any patches as there’s more into it. I do not expect that the area of conflict will go away. I expect that the issue will come up again and again and I expect that those lobbying us will continue to do so. The next time will probably be the preparation for 14.10 where I’m quite sure that we (and probably also GNOME) will be attacked again for our decision. As I explained above this is affecting me and it’s something I do not want. The logical consequence is that I will have to reduce my involvement in KWin and the kde-workspaces and focus on other areas. After having worked for six years on KWin it might anyway be a good point to look for new challenges, especially given that I decided years ago to re focus once the Wayland port is done.

Of course Wayland will be the big item for 2014. It’s one of our internal aims for the next few months and given that I had focused mostly on porting of all kind of workspace applications I’m looking forward to work on it again. Given that the number of applications ported to Qt 5 is increasing each day it will also be a nice thing to work on with hopefully soon switching to a dog-foodable environment having real-world Wayland enabled applications and not just the Wayland demo apps.

Posted on

Laptop and BII window decorations want to be ported to KWin/5

At the moment the window decorations Laptop and BII are disabled from build in kde-workspace master branch. From the KWin development team side these two decorations had been unmaintained for a long time and this means I will not do the port and I don’t expect anyone else from the core team will port them.

This means it depends on YOU dear reader to make sure that those two decorations are also available in the next release. So if you are using one of the decorations and are able to program in C++ please step up and port them (also maintaining would be awesome).

If nothing happens till let’s say end of January I will git rm those two decorations.

Posted on

Quick Window Switchers in KWin 5

One of the oldest usages of QtQuick in KWin are the Window Switchers. During the design it was aimed for having them Plasma-styled just like the previous implementation. This was not as easy as one could hope, because back then we couldn’t use the Dialog component provided by PlasmaCore. So all the various Switcher styles implemented the Plasma styling themselves and the C++ side did some additional adjustments like guessing the blur region. As the Plasma theme recognized that the blur effect is active the FrameSvg used as a background was rendered in the blur-available translucency state. To have it readable it needs to be blurred.

For this we would the correct blur mask of the FrameSvg but that’s not available from the Qml bindings. The hack we went for was to just assume in the C++ side that the switcher is Plasma styled, created another FrameSvg of same size and extracted the blur mask from that. Sounds fragile, doesn’t it?

And of course there came the day when that broke. About a year ago we noticed that the shadow doesn’t work any more and we needed to bring in some more fixes to make that work. If we would have used a PlasmaCore Dialog this would not have been an issue at all.

Now after the Qt 5 port the blur and shadow was once again broken and once again I was about to start fixing it. But nowadays we use the Plasma Dialog in e.g. declarative KWin scripts (the desktop change OSD being a prominent example). So I took a step back and thought about instead of fixing the fragile code to re-think it and make it possible to use the Plasma Dialog or in general QtQuick Windows from inside the Qml code.

Given that this required to adjust all switchers anyway I decided to go a step further and also improve the API a little bit. So far all the important data was exposed as context properties. I’m not a huge fan of context properties as it’s kind of magic. Instead there is now a dedicated switcher item available, which is just a QObject exposing a few properties:

import org.kde.kwin 2.0 as KWin

KWin.Switcher {
    property QAbstractItemModel *model // The model with either the windows or the virtual desktops
    property QRect screenGeometry // The geometry of the active screen (as KWin thinks of active)
    property bool visible // Whether the switcher is currently visible or not, a Window should follow this
    property bool allDesktops // Whether the switcher includes windows from all desktops or only the current one
    property int currentIndex // The index of the selected window - this is controlled from KWin side
}

The model provides the following roles for Window Switchers:

  • caption – The caption of the window
  • desktopName – The name of the virtual desktop the window is on
  • minimized – Boolean whether the window is minimized or not
  • windowId – Window system specific identifier
  • closeable – Boolean whether the window can be closed
  • icon – QIcon containing the window’s icon

With that we can design a very simple thumbnails switcher:

import QtQuick 2.1
import org.kde.kwin 2.0 as KWin
import QtQuick.Window 2.1
 
KWin.Switcher {
    id: switcher
    currentIndex: listView.currentIndex
 
    Window {
        id: window
        flags: Qt.X11BypassWindowManagerHint // important, without it won't work
        visible: switcher.visible
        color: "white"
        x: switcher.screenGeometry.x + switcher.screenGeometry.width / 2 - window.width / 2
        y: switcher.screenGeometry.y + switcher.screenGeometry.height / 2 - window.height / 2
        width: switcher.screenGeometry.width - 100 // keep 50 px space to each side
        height: 200 * (switcher.screenGeometry.width/switcher.screenGeometry.height) + 20
 
        ListView {
            id: listView
            orientation: ListView.Horizontal
            model: switcher.model
            spacing: 10
            anchors.fill: parent
            anchors.leftMargin: 10
            anchors.rightMargin: 10
            delegate: KWin.ThumbnailItem {
                width: 200
                height: width * (switcher.screenGeometry.width/switcher.screenGeometry.height)
                wId: windowId
                brightness: ListView.isCurrentItem ? 1.0 : 0.5
                saturation: brightness
                MouseArea {
                    anchors.fill: parent
                    onClicked: {
                        listView.currentIndex = index;
                    }
                }
            }
            Connections {
                target: switcher
                onCurrentIndexChanged: {
                    // currentIndex is updated from KWin side - need to keep in sync
                    listView.currentIndex = switcher.currentIndex;
                }
            }
        }
    }
}

I wrote this code directly in the blog post without any testing at all (hey it found one bug in KWin and two in the systemsetting previewer. I should do such stuff more often 😉 ). So let’s see how it looks like:

Aus TabBox

Not a bad result for 50 lines of code. As one can also see from the code it does not do any Plasma styling at all any more. Which is a nice side-effect for the usage of KWin outside the Plasma workspaces. The changes to get Plasma styling is not difficult either. Just use PlasmaCore.Dialog instead of the Window and that’s it.

Posted on

Firefox KDE integration in Debian Testing

One of the features I dislike about Firefox is the lack of any integration with the environment it is running in. It doesn’t recognize the correct applications to open files and presents the IMHO unusable GTK file dialog. The file dialog is a real problem to me. I often have to download patches from reviewboard and my KDE file dialog has all the shortcuts to get into the source directories.

Thanks to the openSUSE people there are patches to get a working KDE integration. But those are not upstream and not all distributions includes them. So if you are not using openSUSE chances are that you don’t get those goodies. Thanks to Blue Systems there is a PPA for Kubuntu: firefox-kde.

Even better: this PPA is also working on Debian Testing. But one needs to use the “raring” repository and not “saucy” (unmet dependencies). The normal warnings about adding additional repositories to your system apply. Don’t blame me if it breaks your system. Just add the following to your sources.list:

deb http://ppa.launchpad.net/blue-shell/firefox-kde/ubuntu raring main 
deb-src http://ppa.launchpad.net/blue-shell/firefox-kde/ubuntu raring main

I highly recommend to apt-pin the “raring” release, so that it doesn’t update your packages from this repository:

Package: *
Pin: release a=raring      
Pin-Priority: -2

Now update the sources and install firefox and firefox-kde-support. On Debian the package is called iceweasel and firefox can be installed next to it: the files do not conflict. Close any running iceweasel instance and start Firefox (no longer iceweasel).

Aus 2013-12-01

Additional gimmicks: newer version as it’s based on Ubuntu’s Firefox and appmenu integration.