Posted on by Martin Flöser

Help porting KWin to Frameworks 5

With Akademy behind me and the situation about “what is master” in kde-workspace resolved I decided to switch my work away from Wayland towards getting KWin on top of Qt 5 and KDE Frameworks 5. After a few days of hacking the compilation of KWin is re-enabled in the frameworks-scratch branch of the kde-workspace git repository.

This means that KWin compiles, links and installs when compiling against KF5. A quite important step and only very few code areas got ifdefed. The preparation work of the last months showed it values as for example the compile errors due to QPixmap were extremely easy to resolve (just delete the code) without loss in functionality.

But of course at the moment KWin does not work yet when compiled against KF5 as the event filter is not yet ported to xcb. This is what I will focus on next so that we can soon start testing a KWin on 5 and start to adjust the areas which need to be tested against a running KWin, where “ship it, it compiles” is not enough.

Of course getting KWin to KF5 is still a long road and we need help for this. There are many, many tasks which are rather easy and do not need a working KWin. It’s just a matter of changing for example KPushButton into QPushButton and verify that it still compiles. This means that right now is a perfect time to get started with KWin hacking.

And obviously I started to prepare for that and created a wiki page for KWin on Frameworks. I plan to update this page whenever new information becomes available like how to run KWin on 5. Most important I created a Trello board listing the tasks which can be done to help the porting. I will add tasks as I notice them. So if you want to get involved, just ping me, tell me your trello username and I’ll add you to the board and start hacking. If you look at the list you will notice that some tasks are really simple. Let’s rock to get KWin working on Qt 5 as fast as possible to get an awesome next release.

21 Replies to “Help porting KWin to Frameworks 5”

  1. Hello, i will like to help with a little task, maybe with the for(:)
    my trello user name is @christopheraldamaperez
    thanks for your great work!

    1. Thanks, added you. And thanks for using the same avatar, that made selecting from the list much easier 🙂

  4. would like to help port dirs from KDir to QDir if i can get some starting help i should be good to go from there my user name is sithlord48 for trello

    1. I’m out of labels – seems they are rather limited. Overall I’d say the labels “Cleanup” and “KDE4Support” should be the easiest ones.

  7. Is the XCB work going to waste when porting to wayland ?

    What a waste of effort…

    Since Kwin kind of replaces weston, why not “hack” instead the wayland protocol to work with XCB… is not possible ? …why not KDE have “its own” Display System based on what is there, but “elevated” to a trully interoperable “Standard” ?

    The future is “kronos” not Wayland, and kronos most speciialy for the utraportable(which coukld spill to all form factors to workstations). I liked the news from the recent Akademy… OSS phylosophy is great… but KDE “business” so to speack is “desktop”. KDE for Mac for Windows and for Android is esential i think. Xorg is ahead in that department, it has Xquartz and Xwin for Mac and Windows, with wayland everything is start a fresh with its own very “proprietary” vison ( yes is GPL OSS but the vision is not *standard* in anyway, is quite “proprietary”).

    Also Wayland has no “network” estabileshed ( i think)… and once KDE was about the NX approach which in a rougue mode is a x server with a proxy x server… why not a a kind of wayland server, understanding XCB with a X proxy server ?

    But even so for real “portability” KDE needs kronos standards since about *all* industry, including MSFT, are adopting it one way or another. Whatever wayland server form takes, i think for KDE it needs OpenKODE, EGL and follow OpenWF (the windowing composition standard brewing).. it needs to support Dbus which is going to the Linux kernel and elsewhere(x does wayland don’t), it needs remote display which is taylored as example for a tablet/ultra-thinbook to display on a big monitor and the new WIMAX wireless *standard* is just for that ( x could do it, wayland ?)… all this for going from x86 to ARM to MIPS and for being a “shell” alternative for the popular iOs, winRT and Android.

    The introductions are self explanatory
    https://www.khronos.org/egl
    https://www.khronos.org/openkode/
    https://www.khronos.org/openwf/

    x has several servers and has initial support for multiple GPU engines, the “katamari” couldn’t be more modular than now (take what you need)… and OpenWF Display… could just be X… or OpenWF X Display (remote monitors assured).

    Wayland could be usefull to “glue” all thogether since an “interoperability with “input”, that is “Streaminput” and “Camera” was not yet devised…

    Why can’t KDE have its own very “standard” display and windowing system (2 systems) ? … *fear of hurt feelings”? boredoom ? … kde should be IMHO more than about Linux, specially if it wants a chance att he ultraportable… and the rendering part trough kwin is already settled i think, was not that hard and was a very good choice !

  9. Hi Martin,

    I’d like to help too, I know cmake and c++ so I can help around with that. My trello username is mariuscirsta

  10. Thanks.

    Only one thing though. The whole contribution method is not very clear to me. Is it written somewhere ?
    I know what I have to do but I’m not sure where to clone from, where to put the changes I’ve made. It’s the first time I’m contributing code to KDE.

    1. thanks for the pointer. I just checked our documentation and yes there are things missing. For getting the source just follow the steps in http://community.kde.org/KWin/Frameworks and the linked document for building frameworks.

      Changes should go to git.reviewboard.kde.org. This seems to be missing from the HACKING document. I will extend this.

Comments are closed.