This week in KWin (2013, week 8)

Over the last week quite some bug fixes got merged into the 4.10 or master branch. We have some nice improvements for the desktop change OSD and even improvements for Multi-Head setups. The slideback effect operates on stacking order changes, now. This makes it working with Focus Follows Mouse.

In the Qt 5 porting preparation quite some code got prepared, but not merged yet. Our paint-redirector which is responsible to bridge between window decorations and compositor got adjusted to no longer make use of the QPixmap/XPixmap relationship for xrender on raster graphics system. As a nice side effect of this work we will get some improvements also for the OpenGL compositor.

Another area of work was the removal of QCursor usages in KWin. We used to use QCursor for setting a specific cursor when low level interacting with windows (e.g. setting the pointing hand cursor in Present Windows effect). With Qt 5 we do no longer get the underlying X cursor, so we needed to go for an own solution. We already used to have an own replacement for QCursor::pos(), which got now merged together with the other cursor handling code into an own class.

Summary

Crash Fixes

    Critical Bug Fixes

      Bug Fixes

      • 294490: ‘Slide back’ effect should react on stacking order changes
        This change will be available in version 4.11
        Git Commit
      • 314392: Position rule conflicts with maximization rule
        This change will be available in version 4.11
        Git Commit
      • 312728: “Show desktop layout indicators” option isn’t applied properly/immediately
        This change will be available in version 4.10.1
        Git Commit
      • 315114: KWin fails to initialize OpenGL ES on Mali-604T
        This change will be available in version 4.10.1
        Git Commit
      • 282677: Compositing not possible on each screen with multi head
        This change will be available in version 4.11
        Git Commit
      • 294865: Slide Back: Sometimes the Inactive window pops to the font for apprx. one frame when it is activated.
        This change will be available in version 4.11
        Git Commit

      New Features

      • 313379: Overlap factor of keepAbove windows in placeSmart should be infinite
        This change will be available in version 4.11
        Git Commit
      • 314402: String representation of KWin::Client should include caption, not name.
        This change will be available in version 4.11
        Git Commit

      Tasks

        This week in KWin (2013, week 7)

        This week we have seen much less new reported bugs than the week before. So the 4.10 release peak is over, but openSUSE and Kubuntu releases coming soon – history tells that will also results in lots of new bugs reported. This week a very interesting bug got fixed from the category “one wonders that has ever worked”. The symptoms were already really strange for the bug and if not a fellow developer would have reported it, I would not have believed it. And it took us quite some time to figure out how to reproduce the bug although I had the chance to work with the affected system at FOSDEM.

        The porting for Qt 5 did a huge step over the last week. KWin’s XRenderUtils library got ported from XLib to XCB and with that also “evil” usage of QPixmap got removed. Most of our XRender effects are now also ported to XCB. I hope to finish the QPixmap chapter this week.

        Summary

        Crash Fixes

          Critical Bug Fixes

            Bug Fixes

            • 314760: Keyboard input doesn’t work after assigning window shortcut
              This change will be available in version 4.10.1
              Git Commit
            • 313145: Edges and “hiden panels” stop working when System Activity is shown
              This change will be available in version 4.10.1
              Git Commit
            • 314756: (Desktop Effect) Mouse Click Animation does not recognize mouse buttons correctly
              This change will be available in version 4.10.1
              Git Commit
            • 314625: window border “stays on top” after using present windows
              This change will be available in version 4.10.1
              Git Commit
            • 314762: (Desktop Effect) Mouse Click Animation does not work when rising or focusing a window
              This change will be available in version 4.10.1
              Git Commit

            New Features

              Tasks

                Explore KWin’s Source Repository Change over Time

                Today I’m happy to present some statistics about KWin’s source repository. The shown graph is HTML5/JavaScript, so I’m not sure whether that works on the planet or in an RSS reader. In case it does nto work you can get to the diagram here – as it’s an iframe it seems to be even bad on my blog. Best just open directly :-)

                What does this graph show?

                For each (toplevel) directory in KWin’s source base the source line code is shown for each of our releases of the 4.x series.

                How to use the graph?

                The graph is interactive. With the checkboxes you can enable/disable the individual directories. With the drop down list you can select which information to show:

                • Total line count
                • Code and Comment
                • Code only
                • Blank only

                The graph also provides context information. If you hover over a data point a tooltip is shown with information about the directory at the release. This includes the different counts and a break down per used programming language. The tooltip is not yet perfect and it might be needed that you disable a dataset to better read it.

                What is 4.6*1 and 4.6*2?

                Shortly after 4.6 got branched we did a coding style change over most of KWin’s source base. Due to that change we lost a few thousand lines of code. As that has not been any change in functionality the graph between 4.6 and 4.7 is incorrect. Therefore 4.6*1 is included as the commit prior to the coding style change and 4.6*2 as the commit of the coding style change.

                Directories

                main

                With main the toplevel directory is meant. It contains the window manager and the compositor. Over time some features got split out into sub-directories. E.g. tabbox in 4.4, tiling in 4.8.

                libs

                In 4.7 the lib directory got split into two dedicated directories called libkdecoration and libkwineffects.

                clients

                For historical reasons the directory “clients” contains our window decorations such as Oxygen. Between 4.1 and 4.4 KWin contained the window decoration Oxygen twice. There was also a fork called Ozone with slightly different settings. Overall that meant that the code got duplicated. In 4.4 this situation was resolved by making another Oxygen fork called Nitrogen the new Oxygen. Also the theme engine Aurorae got introduced which explains the strong increase in size between 4.3 and 4.4. The strong drop in 4.6 is explained by moving some legacy decorations out of KWin.

                kcmkwin

                Kcmkwin contains all the config modules of KWin. Changes in source code are mostly related to new KCMs being introduced. 4.3 got a config module for screen edges, 4.4 a config module for Alt+Tab, etc. The only change in that pattern is that in 4.10 we introduced .ui files for our legacy KCMs which replaced C++ by more verbose XML code.

                effects

                Not much to say. I would recommend to have a look at this dataset without the other ones. One can clearly see how we got more effects till around 4.6 and then it started to stagnate. The strong drop between 4.8 and 4.9 is caused by moving some effects from C++ to JavaScript. The increase in 4.10 is caused by migrating settings to KConfigXT which introduced lots of XML.

                tabbox

                TabBox is the Alt+Tab implementation for switching between windows and desktops. It got split out with a new implementation in 4.4 and had been mostly untouched till 4.9 where large parts got rewritten in QML.

                Scripting and Scripts

                Scripting is KWin’s scripting engine for KWin Scripts and scripted KWin Effects. Scripts contains a few scripts we include to replace features from KWin core.

                Tiling and tilinglayouts

                The now removed tiling implementation.

                data

                Mostly KConfig update scripts

                killer

                The window killer (ctrl+esc)

                What’s missing?

                Unit tests

                Unit tests are not considered as they tend to be rather large in code without adding any functionality.

                Shaders

                The tool to process the source base (more in the next section) is not able to parse glsl files. But it’s not much wc -l tells me 87 lines for the main directory containing the basic compositor shaders.

                Plain Text Files

                All the desktop files are missing. We have quite a lot but they are not really interesting as they are mostly containing translations.

                Methodology

                The data is generated using the tool cloc in version 1.56 as provided by the Debian (Wheezy) package cloc in package version 1.56-1.

                For each of the versions (git tags) cloc was run in the git checkout (clean checkout just for getting the stats) once in each of the specified directories. The result was written into an xml file in a directory specifying the version.

                For reference the shell script used to automate the process:

                #!/bin/bash
                KWIN_SRC=$1
                VERSIONS=$2
                SUBDIRS="clients data effects kcmkwin killer lib libkdecorations libkwineffects opengltest scripting scripts tabbox tools tiling tilinglayouts"
                
                cd $KWIN_SRC
                for i in `ls $VERSIONS`; do
                  git checkout $i
                  cloc --force-lang=XML,ui --force-lang=XML,kcfg --exclude-dir=clients,data,effects,kcmkwin,killer,lib,libkdecorations,libkwineffects,opengltest,scripting,scripts,tabbox,test,tools,tiling,tilinglayouts --xml --report-file=$VERSIONS/$i/main.xml .
                  for j in $SUBDIRS; do
                    cloc --force-lang=XML,ui --force-lang=XML,kcfg --xml --exclude-dir=test --report-file=$VERSIONS/$i/$j.xml $j
                  done
                done
                

                This generated quite some xml files which were processed with a hand written tool. It reads in all the xml files, processes the information and prints out a javascript section to stdout which can be used as input for the jQuery flot graph library. Anything else in HTML and JavaScript can easily be seen by looking at the code :-) The order of the datasets got manually re-ordered to make more sense. E.g. having the three lib directories grouped together.

                If there are more questions to the methodology: please ask and I will provide the information and in case something is missing extend the section.

                This week in KWin (2013, week 06)

                This week we have seen the release of KDE Plasma Workspaces 4.10 and it looks like many people gave it a try over the weekend. My “bugs reported over last week” search gives me 41 reports – magnitudes more than what’s normal. My mailbox literally exploded this weekend. Not all of the bugs are new in 4.10, there are quite some which are actually older, so I don’t think we let some bugs through, but nevertheless: please test the betas. I prefer getting the bug reports before the final is released.

                In the feature development department the most interesting events are the merge of the new screen edges implementation. Highlights are “multi screen aware”, glow known from Plasma’s auto-hiding panel being available on all screen edges when approaching with the mouse and no longer stealing screen edges (except corners) from active fullscreen windows. More things are planed like making it possible for Plasma to use KWin’s implementation (less code duplication) and only start the highlight if an action will be possible.

                The second interesting new feature/bugfix is that KWin is able to detect whether the screen is locked and disables some privacy related effects. Currently all thumbnail effects get deactivated, screenshot and mouse mark.

                Summary

                Crash Fixes

                • 314593: kwin crashes when applying “Invert” effect immediately after session unlock
                  This change will be available in version 4.10.1
                  Git Commit
                • 314409: Moving to Other Workspace Crashed KWin
                  This change will be available in version 4.11
                  Git Commit
                • 309695: Crash in KWin::Screenedge::unreserve on deactivating Actos script
                  This change will be available in version 4.11
                  Git Commit
                • 313996: KScreen crashes KWin when switching between resolution options
                  Git Commit

                Critical Bug Fixes

                  Bug Fixes

                  • 299901: Cube animation on border approach should not be used unless the electric borders are actually in use and the config should be disabled, align or hint the electric border configuration
                    This change will be available in version 4.11
                    Git Commit
                  • 255712: “Thumbnail Aside” effect visible when screen is locked — privacy issue
                    This change will be available in version 4.11
                    Git Commit
                  • 278137: Trailing artifacts when quickily moving windows and windowgeometry affect is enabled
                    This change will be available in version 4.10.1
                    Git Commit
                  • 314590: “Show Desktop” no longer works as a toggle
                  • 313826: Outdated “Moving/resizing” option pending in kwinrules
                    This change will be available in version 4.10.1
                    Git Commit

                  New Features

                  • 290887: Hot Screen Corners do not work properly in multiscreen setup with different resolutions
                    This change will be available in version 4.11
                    Git Commit
                  • 271607: Window Specific Settings for Disabling Screen Edges
                    This change will be available in version 4.11
                    Git Commit

                  Tasks

                    More rational approach to window decorations

                    This is a follow-up post to my client-side-decorations (CSD) on Wayland post. Personally I was positively surprised by the feedback in comments and on various media sites. Hardly any “you are an idiot” – for a controversial subject this is very positive.

                    There was one comment which motivated me to write another post on the topic:

                    I see strong arguments/feelings for both CSD and server side – can there by a hybrid approach?

                    This is exactly the point. Neither client side (CSD) nor server side decorations (SSD) are the holy grail. Both have advantages, both have disadvantages. Nobody is right here, nobody is wrong. If someone says he prefers CSD, he is right, if I say I prefer SSD, I am right. That’s quite important to get. In the end one has to evaluate the advantages and disadvantages and then decide which is the less evil.

                    For me this is server side decorations because of the disadvantages I pointed out for our workspaces. Others might decide differently and that’s just fine. I do not want to enforce SSD on anyone who prefers client side decorations.

                    In fact I would be fine with CSD if there would be an approach to make them work right. There have been many comments that it really doesn’t matter as it belongs in the toolkit and they will look the same. Yes of course, I agree that decorations belong into the toolkit and that they should adapt to the needs of the workspace they are running in. But I don’t believe the toolkit (except Qt) can do that. As long as there are so huge integration issues like getting an unfitting file dialog in the KDE workspaces, I just don’t trust that toolkits can do it. In that aspect there have been quite some comments, that the integration is already really bad, so it doesn’t matter if that part breaks as well. Let’s just say that I disagree here :-) I want to have more integration not less.

                    So in the end it has to be a hybrid approach. There are valid usecases for client side decorations even on a system enforcing server-side decorations (best example: Yakuake), but if the system does not want decorations (e.g. Plasma Active) the client’s should not draw an own decoration. And of course there is the Chromium use-case where the user should be allowed to decide.

                    All it needs is a small protocol allowing the server to negotiate with the clients whether CSD should be used or not (that would be useful on X11, too). This actually does not mean an overhead, because also for CSD there should be some negotiation between server and client to figure out things like button position, which buttons, colors, style and so on – which goes in the direction of CSD done right. Just saying: “it’s the Client’s responsibility” is causing the issues I’m afraid of.

                    Client Side Window Decorations and Wayland

                    This weekend I was at FOSDEM and attended a talk about Wayland for application developers. One thing that came around multiple times was that “applications have to provide the decorations”. Every time I had to cringe, because it’s just not true and I find it sad that people who give presentations about Wayland repeat that.

                    Nothing in the Wayland protocol requires Client Side Decorations or forbids Server Side Decorations. And that’s not surprising as it just should not matter to a protocol. The same is true for the X11 protocol, there is nothing said about window decorations. Just on X11 people realized that server side decorations are the better choice, but still there are applications doing client side (maybe people think that the possibility of re-parenting says anything about window decorations, it doesn’t you don’t need re-parenting to provide server side decorations). What is true is that the reference implementation of a Wayland compositor, Weston, requires Client Side Decorations, but it’s just one implementation and doesn’t say anything about other implementations. And here it’s important to remember that Weston is not Wayland.

                    There are good arguments pro and contra client side decorations. The most commonly listed ones pro client side are:

                    1. Only one texture needs to be rendered
                    2. No aliasing when rotating/wobbling windows
                    3. Application developers are free to experiment

                    The first two are true. I have to agree there. I know KWin’s OpenGL decoration rendering code and the problems with it. I do not like it and I do see the disadvantages. Also I do know that wobbling windows is not looking nice.

                    The third argument is more complex. Here I do not agree, because I have not seen any valid use cases for these “experiments”. All we have so far is the Chromium use case and since then nobody else came up with any use case. So somehow that shows that we are not restricting the application developers as some pro-CSD people would claim. In fact allowing CSD limits the possibilities of the workspace.

                    Plasma provides three workspaces: desktop, netbook and tablet. From KWin perspective the main difference is how window decorations are handled. On Desktop we have full decorations, on netbook we disable decorations for maximized windows (control moved to the Shell’s panel) and on active we don’t have any decorations at all. With client side decorations such possibilities are gone. We are no longer able to take the desktop further by just changing this aspect for all applications. Many KDE applications are useable on Plasma Active (tablet) without any adjustments. If they would use CSD they were not usable.

                    My main fear with CSD is that it ends up in a mess as we can see on Microsoft Windows. There CSD are common but applications don’t use it to do useful stuff, but to enforce their corporate design. This is bad for usability. Each application looking different? Stupid idea. Not even Microsoft is having a consistent decoration for their various products. Some have titles on the left, some centered. A complete mess. And my fear is that Linux would head there, too.

                    Is this fear valid? Well during said presentation Weston was running with two windows. They had different decorations. One was the terminal with minimize, maximize and close button on the right. One was a pdf viewer with a standard GNOME Shell decoration: minimize button missing. And during FOSDEM I had also a look on the decorations for Qt Wayland: again different decorations.

                    Now let’s take that further: an application for Unity will have the buttons on the left, a decoration for KDE will have two on the left and three on the right. Everything will look different, just on one system. Total mess and nothing I want to use (yes that would be a reason to switch to Mac if that would happen).

                    I had a talk with Andy from Qt Wayland fame about the CSD implementation and he explained me that inside Qt the CSD code gives some overhead and that they have a flag to turn them off. Which is great. And we in KWin already have server side decorations and will need to keep them around for legacy X applications. What’s the point then to use CSD in Qt if we already have the decorations and can give the application a better performance? Well none and that’s why I plan to use server side decoration in KWin on Wayland.

                    So if you read again somewhere that Wayland requires Client Side Decorations:

                    • Nothing in Wayland requires them
                    • QtWayland allows Clients to turn them off
                    • KWin as a Wayland compositor will use server side decorations

                    I do not want to go into the details of the contra arguments of Client Side Decorations as I have done that in the past. It’s a difficult topic as both pro and contra arguments are true. I personally see the contra arguments – especially the inconsistency – as much worse than the possible benefit of any possible pro argument. And please don’t come to my comments section and tell me that one can standardize on how the decorations should look like. If that were possible and feasible and would be used by application developers, we would not have already at least three different decoration implementations. It will end in the fancy I’m important mess from other systems.

                    Porting KWin to XCB: making C usable through RAII

                    One of the most important work areas in KWin is currently the porting from XLib to XCB. The main reason for this is that Qt 5 threw out the existing XLib based code and replaced it by a new XCB-based implementation using QPA. This is overall a good thing. But it means that applications which used native features like the X11-event filter need to be adjusted. There are a few areas which need porting, which I summarized for KWin (hopefully completely) in this wiki page. If you use some native interaction it might make sense to check the list.

                    Technically we would not be required to port everything to XCB, but it gives us quite some advantages to do so. XCB is based directly on the X11 protocol which means we see better in the code what is going on. Also XCB is a complete asynchronous API which means we wait less for the X Server. This brings a noticeable improvement.

                    I want to present an example from KWin to show the difference between the synchronous XLib approach and the asynchronous XCB approch.

                    XWindowAttributes attr;
                    Window dummy;
                    Window* windows = NULL;
                    unsigned int count = 0;
                    QRect screen = QRect(0, 0, displayWidth(), displayHeight());
                    QVector<Window> proxies;
                    XQueryTree(display(), rootWindow(), &dummy, &dummy, &windows, &count);
                    for (unsigned int i = 0; i < count; ++i) {
                        if (m_screenEdgeWindows.contains(windows[i]))
                            continue;
                        if (XGetWindowAttributes(display(), windows[i], &attr)) {
                            if (attr.map_state == IsUnmapped)
                                continue;
                            const QRect geo(attr.x, attr.y, attr.width, attr.height);
                            if (geo.width() < 1 || geo.height() < 1)
                                continue;
                            // some other checks
                            proxies << windows[i];
                        }
                    }
                    

                    So what in this code is synchronous? In line 7 we ask the X Server for all windows – of course synchronous. Then we go through the list and get for each window we are interested in the window attributes (line 11). In the X protocol that are two requests to the server – one for the attributes and one for the geometry. Overall this means we have a synchronous call for each window we have to check. I recently looked at a delay when ending Present Windows or Desktop Grid and noticed that this for loop can take up to 500 msec.

                    Now let’s look at the same thing done with XCB (note: I did not compile it):

                    xcb_connection_t *c = connection();
                    xcb_query_tree_cookie_t cookie = xcb_query_tree_unchecked(c, rootWindow());
                    QVector<xcb_window_t> proxies;
                    QVector<xcb_get_window_attributes_cookie_t> attribsCookies;
                    QVector<xcb_get_window_geometry_cookie_t> geometryCookies;
                    QRect screen = QRect(0, 0, displayWidth(), displayHeight());
                    
                    xcb_query_tree_reply_t *tree = xcb_query_tree_reply(c, cookie, NULL);
                    xcb_window_t *windows = xcb_query_tree_children(tree);
                    for (unsigned int i=0; i<tree->children_len; i++) {
                        attribsCookies << xcb_get_window_attributes_unchecked(c, windows[i]);
                        geometryCookies << xcb_get_geometry_unchecked(c, windows[i]);
                    }
                    
                    for (unsigned int i=0; i<attribsCookies.size(); i++) {
                        if (m_screenEdgeWindows.contains(windows[i])) {
                            xcb_discard_reply(c, attribCookies.at(i));
                            xcb_discard_reply(c, geometryCookies.at(i));
                            continue;
                        }
                        xcb_get_window_attributes_reply_t *attrib = xcb_get_window_attributes_reply(c, attribsCookies.at(i), NULL);
                        if (attrib->map_state == XCB_MAP_STATE_UNMAPPED) {
                            xcb_discard_reply(c, geometryCookies.at(i));
                            free(attrib);
                            continue;
                        }
                        xcb_get_window_geometry_reply_t *geometry = xcb_get_window_geometry_reply(c, geometryCookies.at(i));
                        const QRect geo(geometry->x, geometry->y, geometry->width, geometry->height);
                        if (geo.width() < 1 || geo.height() < 1) {
                            free(attrib);
                            free(geometry);
                            continue;
                        }
                        // some other checks;
                        proxies << windows[i];
                        free(attrib);
                        free(geometry);
                    }
                    free(tree);
                    

                    This example shows nicely the advantage of having an asynchronous API. We first have one loop to send all requests to the X-Server and then fetch the reply in a second loop. But we also see quite some disadvantages. First of all the_naming_is_just_awfull() and becomes worse when working with extensions. It’s nothing special for XCB, it’s a common problem to all C APIs, I always have to cringe when seeing such code. Also the method arguments are rather unhandy. We need to pass an xcb_connection_t* parameter to each method call. Fair enough the same had been the case with XLib, but still we have just one connection to the X-Server.

                    If we do not want to check for errors, we have to use the _unchecked variant of the method. It’s again a general C API problem by not having the possibility to overload methods.

                    And a real problem which is nicely visible in the code fragment is that the reply calls return a pointer and pass the responsibility for the pointer to the client of the API. For someone being used to a memory managed programming language like C++ with Qt that’s really painful. I expect to get back const references and not pointers I have to free.

                    Also if we do not need the reply for a request, we need to discard it, otherwise we would leak a reply. This makes the whole code segment rather unhandy.

                    We did not really like it and worked on improving this in general over multiple iterations. The whole thing can easily become memory managed by using a QScopedPointer with a QScopedPointerPodDeleter. That way we don’t have to call free on the replies any more. When the QScopedPointer goes out of scope the memory will be freed implicitly.

                    But that’s not all we did to improve it and I show now the same code segment how it looks like after applying our Wrapper classes:

                    QVector<Xcb::WindowId> ownWindows = windows();
                    Xcb::Tree tree(rootWindow());
                    QVector<Xcb::WindowAttributes> attributes(tree->children_len);
                    QVector<Xcb::WindowGeometry> geometries(tree->children_len);
                    
                    Xcb::WindowId *windows = tree.children();
                    QRect screen = QRect(0, 0, displayWidth(), displayHeight());
                    QVector<Xcb::WindowId> proxies;
                    
                    int count = 0;
                    for (unsigned int i = 0; i < tree->children_len; ++i) {
                        if (ownWindows.contains(windows[i])) {
                            // one of our screen edges
                            continue;
                        }
                        attributes[count] = Xcb::WindowAttributes(windows[i]);
                        geometries[count] = Xcb::WindowGeometry(windows[i]);
                        count++;
                    }
                    
                    for (int i=0; i<count; ++i) {
                        Xcb::WindowAttributes attr(attributes.at(i));
                        if (attr.isNull() || attr->map_state == XCB_MAP_STATE_UNMAPPED) {
                            continue;
                        }
                        Xcb::WindowGeometry geometry(geometries.at(i));
                        if (geometry.isNull()) {
                            continue;
                        }
                        const QRect geo(geometry.rect());
                        if (geo.width() < 1 || geo.height() < 1) {
                            continue;
                        }
                        // further checks
                        proxies << attr.window();
                    }
                    

                    It’s a RAII approach ensuring like the QScopedPointer that the memory is freed once the object goes out of scope. In addition we got completely rid off the connection we have to pass to the method calls and we do no longer have to call discard: our Wrapper class is taking care of it. What you can also see is that the fact that the API is asynchronous is completely hidden. It still is async, the request is done in the constructor and the reply is fetched once you try to access the data for the first time.

                    Overall it makes the code much cleaner and easier to use and ensures that we do not leak memory even if we use loops with various code paths jumping out of them. Also we know that the code works (unit tested) and ensures that we do not repeat ourselves.

                    In the background we have a templated class which allows us to easily wrap any XCB request/reply group. So far we only support method calls operating on one xcb_window_t argument, but once we enabled C++11 in KWin we can easily wrap any command through variadic templates.

                    If you find this interesting: we have lots of work for XCB porting. Just come to #kwin on freenode and ping me (mgraesslin) or send a mail to kwin@kde.org.

                    This week in KWin (2013, week 5)

                    Major event last week has of course been the tagging of 4.10 and some last minute fixes for it. TabBox is now getting proper translucent backgrounds again, other parts of KWin still have unfortunately still problems with it. Most of the work has not yet made it into master and is still on review. There’s some new stuff for screen edges in the pipeline and some further areas got ported to XCB.

                    Summary

                    Crash Fixes

                    Critical Bug Fixes

                      Bug Fixes

                      • 313909: XReconfigureWMWindow fails to stack (lower) a window using an Above CWSibling combination
                        This change will be available in version 4.11
                        Git Commit
                      • 192807: Plastik window decoration doesn’t paint for very small windows
                      • 310945: New maximize effect leads to visual glitch
                        This change will be available in version 4.10
                        Git Commit

                      New Features

                        Tasks