I planned on writing about the Present extension this week, but I’ll postpone this since I’m currently strongly absorbed into finding the last rough edges of a first patch I can show off. I then hope to get some feedback on this from other developers in the xorg-devel mailing list.

Another reason is that I stalled my work on the Present extension for now and try to get first my Xwayland code working. My mentor Daniel recommended that to me since the approach I pursued in my work on Present might be more difficult than I first assessed. At least it is something similar to what other way more experienced developers than myself tried in the past and weren’t able to do according to Daniel. My idea was to make Present flip per CRTC only, but this would clash with Pixmaps being linked to the whole screen only. There are no Pixmaps only for CRTCs in X.

On the other hand when accepting the restriction of only being able to flip one window at a time my code already works quite good. The flipping is smooth and at least in a short test also improved the frame rate. But the main problem I had and still to some degree have, is that stopping the flipping can fail. The reason seems to be that the Present extension sets always the Screen Pixmap on flips. But when I test my work with KWin, it drives Xwayland in rootless mode, i.e. without a Screen Pixmap and only the Window Pixmaps. I’m currently looking into how to circumvent this in Xwayland. I think it’s possible, but I need to look very carefully on how to change the process in order to not forget necessary cleanups on the flipped Pixmaps. I hope though that I’m able to solve these issues already this weekend and then get some feedback on the xorg-devel mailing list.

As always you can find my latest work on my working branch on GitHub.

It's with all the joy in my heart that I share with you this amazing notice: AtCore was officially moved today to KDE Extragear by my favorite sysadmin Ben Cooksley after more than a month on KDE Review. This is the first huge milestone that we achieve on this 11 months of team work made [...]

This release includes all the feature-enhancements the Linux version has received (frameworks announcements for 5.36.0)

– Actually working spell-checking.
– Possibility to switch interface language.

EDIT: Adding an extra fall-back UI language does not wok properly yet.

Kate in Sweedish

Grab it now at download.kde.org:  Kate-setup-17.04.3-KF5.36-32bit or Kate-setup-17.04.3-KF5.36-64bit

When I released Brooklyn v0.1 complaints arose from the fact that it is written in Java.
A lot of criticisms come from users that probably wrote Java code when it was born.
The language is constantly changing and I decided to use Java 8 as the primary language for Brooklyn.
I'm writing this blog post because while I was learning new features I realized that there is an enormous difference between studying something and applying what you have studied in a practical scenario.
I'll keep writing posts like that, and I want to write much more if I receive a good feedback!

Avoid null pointer exceptions
Imagine that you've a Bot interface with a method sendMessage and three classes that implements that: IrcBot, TelegramBot and RocketChatBot.
sendMessage returns a string which contains the messageId returned from the bot; the main problem is that there are bots like IrcBot which can send messages to IRC, but the protocol doesn't support messages identification.

What should you do? The first thing you can come to your mind is to return a null:

public interface Bot {
 String sendMessage(...);
}

public final class TelegramBot implements Bot {
 @Override
 public String sendMessage(...) {
  // Message is sent here

  return msgId;
 }
}

public final class IrcBot implements Bot {
 @Override
 public String sendMessage(...) {
  // Message is sent here

  return null;
 }
}

public interface Bot {
 Optional<String> sendMessage(...);
}

public final class TelegramBot implements Bot {
 @Override
 public String sendMessage(...) {
  // Message is sent here

  return Optional.of(msgId);
 }
}

public final class IrcBot implements Bot {
 @Override
 public String sendMessage(...) {
  // Message is sent here

  return Optional.empty();
 }
}

if(result.isPresent()) {
 String msgId = result.get();
 System.out.println(msgId);
}

Optional<File> file;
File fileNull = x.getFile();
if(null == fileNull)
 file = Optional.empty();
else
 file = Optional.of(fileNull);

Time to fly off to the sun to meet KDE friends old and new and plan out the next year of freedom fighting. See you in Almería!

by

I completed the Oware two player mode as described in my previous blog post GSoC-First month analysis. This month was the time for the single player mode. So well it started well, I implemented the alpha beta pruning for the AI mode.

The levels are structured in the following way:

1. For the initial levels the AI is random which sows randomly from its houses. But if the computer gets in a bad position or is losing badly then it switches to AI mode. A maxDiff is maintained for each level, for example level 1 has maxDiff = 20, level 2 has maxDiff = 15 and so on. So as soon as the computer/AI is behind the player by maxDiff it switches to AI mode.
2. For the last levels there is no random selection so basically maxDiff = 0.

I also had been working on the animation of seeds which involves movement of the seeds from one house to another. It still has some issues left involving the animation being triggered at each step.

There are also some changes in my GSoC plan. I thought of working on computer activity after oware earlier when I made my proposal but with discussions with my mentors we came to a conclusion that musical activities are more important for a child. So I would be working on musical activities now which includes play piano and note names activity which were started in the branch Play piano and were earlier to be done in my last month. My aim would be to complete both these activities.

I planned to go to Akademy this week and meet everyone but well my visa got refused :( I will try to be a part next year and I hope I get the chance of meeting everyone (especially my mentors soon). I will cover more about the musical activities and my progress in my next blog post :)

I’m currently in my final preparations for this year’s Akademy.

For people unaware of this conference, it is the annual conference of KDE contributors.

We tend to have a few dozen of high quality talks on various topics ranging from art and community building, to hard-core Qt and C++ talks.

This year, I’m going to have two talks. One on (obviously :) ) functional programming in C++, and one on C++17 and 20. The later one will be a bit self-serving because I’d like us to raise the compiler requirements for our software so that we could enjoy working in KDE even more.

The only thing more important than talks is the period after where the different teams within KDE meet-up to discuss the future plans. While we do it all the time on IRC and on the mailing lists, having face-to-face meetings is irreplaceable.

If you are near Almeria, join us – the conference is free for attendance!

Hi everyone!
As the title of this blog post suggests, the first evaluation has been successfully passed, the project accomplishing all the proposed goals. Thus, let me present you the progress I’ve done for the first evaluation.

• The very first thing I’ve took care was allowing multiple-instrument visualization framework, by modifying the old core architecture of Minuet. Instead of the one and only keyboard instrument, Minuet is now providing an instrument tab bar, enabling the end user select the desired instrument. The tab bar is currently loading the instrument within the first tab as default. After I’ve discussed with my mentor, Sandro, I decided to keep the piano keyboard as the default instrument contained by the first tab. In order to keep all the functionalities available and a simple architecture at the same time, I’ve created an InstrumentView wrapper above all the instruments. Its methods are called by the core ExerciseView, calling in turn the methods that each instrument should implement.

• After changing the Minuet’s core in order to provide a multi-instrument framework, I started refactoring the piano keyboard view as a separate plug-in. Basically, for Minuet, a plug-in is nothing more than a bunch of QML files and a simple JSON file parsed in order to learn about the QML files’ location and load them dynamically in the instrument tab bar.

The next goal was to install each instrument separately as a plug-in, besides all other Minuet’s plug-ins. Like any other KDE application, Minuet, keeps its data files into /usr/share/ file-system directory. Thus, this was the place where our plug-ins had to be installed; actually, the exact path is /usr/share/minuet/plugins/. Installing a plug-in is simply done by using a CMakeLists.txt file telling the build system where the plug-in files should be installed.

Plug-ins are loaded as follows: firstly Minuet searches for plug-ins location and if the search succeeds, it will iterate through each instrument’s JSON file, building a QJsonArray containing the plugin name and path. This QJsonArray is passed to the InstrumentView, setting the contents of the Instrument Tab Bar. Having all the tabs ready, the TabBar will just wait for a tab to be selected and a QML file to be loaded.

• Having the multiple instruments framework and piano plug-in ready, the next step was to test and analyze the code for possible technical issues or bugs. Also, a general clean-up was required before submitting the code for the review and first Google Summer of Code evaluation.

These are the achievements I’ve met for the first evaluation. Let’s discuss now about the current progress for the next evaluation:

• I wrote a proper and comprehensive documentation for the piano plug-in, enabling anyone to create his/her own instruments plug-ins and loading them dynamically into Minuet.
• I started implementing a new instrument from scratch. As I am very passionate about guitar, I chose to integrate it into Minuet’s instruments suite. Thus, I have already designed the visuals for the Guitar plug-in and added it into Minuet’s instrument tab bar. Now, I need to link the GUI to the core, work on the guitar’s specifics and make the plug-in fully functional.

In conclusion, GSoC proves to be a great experience thus far, being a pleasure to work on a project focused mainly on a subject I’m in love with: music. For further cool news, stay tuned!

A lot of implementation changes were introduced

• Selection highlights depends upon the items selected in the model.
  • Previously, the selection higlights toggled when the SelectionButton for an image was clicked
  • Now the higlighted images are shown according to the items selected and stored in the selection model
    
    
• Completely removed baloo dependency
  
  
• For “By Folder” filter KIO based model is used for folder representation of images.
  • It shows the mixed images and folders in the AlbumView.
  • It shows the images in hierarchical structure, as they are represented in the memory. Just like a file manager would represent, but just the images and folders.
    
    
    
    
• Adds a new ImageListModel
  • This model would just store the image list irrespective of whether they are from ImageLocationModel or ImageTimeModel.
  • This made the representation of images in the GridView and the ImageViewer a lot more easier
    
    
• Better implementation of ImageViewer done by Marco Martin
  • Better animations for ImageViewer to appear and disappear.
  • Pinch zoom for the single Image appearing in the ImageViewer.
  • Zoom animations for the images in ImageViewer. Zoom on double clicking the image as well as on Ctrl + wheel action
    
    

    Normal Image
    
    Zoom on Double Click
    
    Ctrl + wheel Zoom
    
    

• Automatic updation of the currentIndex for the GridView if the index changes in the ImageViewer.
  
  
• Makes the thumbnailer code common to all the models.
  • Faster loading of thumbnails for the GridView.
    
    
• Totally removed the old code base qml implementation.
  
  
• Adds KDirNotify and KDirWatch to support live updates of the data in the time and location collections as well.
  • We don’t need to add KDirNotify and KDirWatch to the ImageFolderModel since it subclasses KDirModel which already takes care of the changes.
  • KDirWatch uses the concept of singleton object ie we can use just a single instance of the KDirWatch class for the entire application.
    
    
• Makes the enums common for all the models.
  
  
• i18n’z all the text elements.
  
  
• Creates a different SortModel for the ImageViewer to apply sort as well as the filter to show just the images.
  
  
• Adds contextualActions to the AlbumView.
  • For now three actions are added Select all, Deselect all and Delete selections.
  • These actions can just be applied on the images and not on the collections or folders.
    
    
• Selectively loads desktop and mobile user interface depending upon whether the environment variable QT_QUICK_CONTROLS_MOBILE is set or not.
  
  
  • There is just single difference between mobile UI and desktop UI, that is of the contextualActions. For desktop version these appear on the toolbar and for mobile version these appear in the contextDrawer.
  • Rest of the changes are handled brilliantly by the Kirigami.
    
    

    Desktop UI
    
    Mobile UI

• Adds a selection mode for mobiles that is activated on pressAndHold.
  
  

  On PressAndHold

• Opens a specific image via the commandline.
  • That allows us to open the image from the file manager also.
  • It takes you directly to the single image in the ImageViewer
  • It also pushes the intermediate folders into the pageStack(that contains AlbumView) starting from the standard Pictures location to the folder containing the image, for the “By Folder” filter.
  • If the image is not in the Pictures location then it just pushes the folder into the pageStack(that contains AlbumView).
  • Though this is not perfect yet. The problem is that the SortModel(QSortFilterProxyModel) in the ImageViewer is populating in pieces that is first when the sourceModel for the model in ImageViewer is set to specific ImageFolderModel with empty data (I think) and then again the rowsInserted signal is emitted and the model is populated again and thus making the rowCount to double of the actual number of images, which then makes the currentIndex in the ImageViewer invalid(-1) at the beginning and hence the navigation starts from the first image in the list instead of the selected image. Searching for the alternatives :)
    
    
• PS: The background shown in the application is theme dependent. This is Breeze-dark theme

In my last post, I talked about adding a grid layout to the activity. The inspiration of this layout was to remove the trial and error method of selecting (x,y) positions of a node and to implement a more efficient method of positioning the nodes. Along with that, the distance between two generations and nodes could also be maintained in a homogeneous manner, keeping the layout similar throughout the activity.

As it also turned out, the grid layout along with knowing the width and height of the node also helped in accurately positioning the edges, the effect of which will be shown in a few before-after screenshots later in this post

Implementation

Vertically, the screen is divided into three equal parts (representing three generations), represented as:

readonly property real gen_1: 0.10
readonly property real gen_2: 0.40
readonly property real gen_3: 0.70

Here, gen_1, gen_2 and gen_3 represent 1st, 2nd and 3rd generation.

Horizontally, the area was originally divided into three parts:

readonly property real left: 0.2
readonly property real center: 0.4
readonly property real right: 0.6

Aside from this, we also divided the horizontal area into four other slots, which will be necessary as it turned out later:

readonly property real left_1: 0.1
readonly property real left_2: 0.3
readonly property real right_1: 0.5
readonly property real right_2: 0.7

The nodes

The arrangement of the nodes are very simple, in which we are avoiding the problem of arranging the nodes via trial and error of the (x,y) position. The x-coordinate can be determined by selecting the best among left, right and center or among left_x or right_x (where x = 1, 2) as mentioned above and the y-coordinate can be determined via selecting the best among gen_1, gen_2 or gen_3, depending on the generation of the node.

As an example, for level 11, we define the nodePositions as follow:

nodePositions: [
        [center, gen_1],
        [left, gen_2],
        [right, gen_2],
        [left, gen_3]
]

As we can see from the level, it can be seen that it is very intuitive to determine the node positions for a given level, once we know the type of the node.

The edges

The start-end position of the edges can also be determined via the properties mentioned above along with the nodeWidth and nodeHeight properties mentioned in the previous blog post. For level 11, we calculate the edge positions as:

edgeList: [
        [center + nodeWidth / 2, gen_1 + nodeHeight, center + nodeWidth / 2, gen_2 + nodeHeight / 2],
        [rightXEdge(left), nodeMidPointY(gen_2), right, nodeMidPointY(gen_2)],
        [left + nodeWidth / 2, gen_2 + nodeHeight, left + nodeWidth / 2, gen_3]
]

As a result of these, level 11 turned out to be like this:

How it all turned up

The layout has come a long way since it was started from the beginning of the second phase of GSoC, and here are the before and after screenshots of the family activity

Initial layout of level 18

Current layout of level 18

Initial layout of level 6

Current layout of level 6

What’s Next

I have started working on the extension of the Family activity, the goal of which is: given a relation, the user will have to find the pair that demonstrate the given relation. I will be documenting the progress of the activity once that is near completion, hopefully by the end of this week.

Relevant links

• GSoC Proposal
• Phabricator task
• Development branch
• KDE Status Report

Highlighting

Renaming

Very basic code completion

This is the third post in my GSoC series. You can read the second one here.

Hey there, a few weeks has passed since my last blog post. I promised to make a new post as soon as I had something cool to show off. Well, after working hard for a lot of time, I can finally show you how the project is taking shape.

First of all let me say that everything I am going to show you is still in heavy development and, as of right now, it does look a bit ugly. But don’t worry, it will start looking better in the next weeks.

The code for the frontend is available here.

Browsing courses

The first thing I am going to present you are the basic browsing functionalities. The user is able to browse departments (the top level categories of the website), courses and read pages.

The home page. Ugly but functional

A course index. The Lorem Ipsum is just there as a placeholder

The pages are fetching the data from a backend server that I am also developing during this GSoC. This server acts a compatibility layer between the current backend and this new frontend. I will write a blog post in the future about this service because it is based on an interesting architectural pattern: backend-for-frontend.

Ui Library

Together with the browsing functionalities I started developing a simple UI library to use with the new WebApp.

The UI Elements are customizable and will be used in the rest of the project.

For example take a look at this confirm dialog

or at this Edit Page button

Building an UI Library is a very long process, that’s why another WikiToLearn developer (Demetrio Carrara) is helping me in the development of this UI Library, he designed and built input boxes and added a few styles to the buttons.

This way I can concetrate in the development of the main functionalities.

Async operations

Another interesting feature I worked on, is the support for polling operations. Right now on the website when downloading a PDF for a course you have to stare at a loading bar for a few seconds (sometimes even a minute or two), this is not ideal. That’s why with this new Web App we are going to execute these long operations in the background, without having the user look at a loading bar.

Take a look at this video. I am clicking a button to start a long operations (which as of right now does nothing) and while the operation is in progress (you can see it in the lower right part of the screen) I am still able to browse the website.

There is still some work to do, for example adding some kind of notification once the operation is complete, or letting the user close the browser without losing the operations, but the basics are already implemented.

Other details

As you can see on the video above there are transitions and loading bars when switching between pages, this is very helpful for the user, the browsing experience is much smoother.

The Web App is also quite lightweight, the external libraries and the code are less than 70KB to download, and once they are cached (this means from the second refresh of the page) they load in no time.

The Web App also supports full HTTP codes when responding to the browser: not many Web Apps do this, but after a few days experimenting and developing various solutions I found the best one and decided to use it.

What’s next?

Right now I am experimenting with user authentication. The available solutions (actually the only solution) for authenticating users that is compatible with Vue does not support Server Side Rendering, which is a must for my web application. This probably means I will have to fork the library and implement support for our use case. This could slow down the development of the web app but at the same time it will be great to contribute to an external project.

I am also working on deploying the Web App on a real and public server, making it available for everyone. It is far from usable by common users but it is a nice way to keep track of progress.

As always thanks for reading and don’t be afraid to leave comments!

This is a short public service announcement: KWin master as of today requires a compiler which supports C++14. This means at least gcc 5 or clang 3.4. All major distributions support at least one of the two.

Me, Shaza, and Ahmed

It was nice meeting Ahmed and Shaza @ faculty of Engineering, Ain Shams University in Cairo. I am proud to mentor them in Google Summer of Code.

Ahmed is working on implementing a DLNA server in digiKam core to export photo and video hosted in physical and virtual collections. The server is ready and he working on the configuration panel UI. See more here.

Shaza is working on a tool for image editor to be used for healing image stains with the use of another part of the image by coloring by the use of one part over the other, mainly testing on dust spots, but can be used for other particles hiding as well. See more here.

 KSysGuard — the system monitor — on FreeBSD seems oddly precise. This machine with FreeBSD 10.3 and KDE Applications 17.04.2 installed, tells me that I have 3,274,960.000000 KiB memory in use. That is, three million, two hundred seventy four thousand, nine hundred and sixty kibibytes. I’m willing to believe that, since notionally the machine has 4GB installed and FreeBSD uses up memory until it’s full and so memory use rarely reports much unused. What I’m less inclined to believe is the .000000 part of the measure: and zero millionths of a kibibyte. So that’s a .. um .. more than a millibyte, and a smidgen less than one one-hundred-twenty-secondth of a bit.

So, dragging in some information theory and plugging in some values,  using the binary entropy function, Wolfram Alpha tells me that

p ≈ 0.999314653604933

so we can be ninety-nine point nine percent sure that that is my actual memory use.

Sometimes it’s good to be precise.

As you might know Qt 5.8 created challenging problems for our Wayland session and threw our efforts back quite a bit. In this post I want to discuss the actual problems it created, how we are addressing them and looking into the future.

How our integration used to work

Our integration uses additional Wayland protocols. We have a protocol for server side window decorations which we use in our Plasma integration plugin to inform KWin whether the window should have a decoration or not. We have a protocol for client provided shadows which is e.g. used by our widget style Breeze to add shadows to the context menus. We have a protocol for the desktop shell, so that it can mark windows as desktop, panel, auto hiding panel, position the window, etc. Also we have a few protocols for interacting with our effect system, e.g. sliding popups, blur behind.

To use these protocols we need to interact with Qt in a low level way. We use the native interface in the Qt Platform Abstraction to get a wl_surface pointer for the QWindow. In order to not have to keep this simple for our applications our KWayland::Client API provides an API point for it: Surface::fromWindow(QWindow*) -> Surface*.

But when exactly to inject our own integration? We found a very handy way which worked much better than what we had used in the past for X11 (and based on that also transitioned X11 code to use it). Qt emits an event once it has created the native platform surface (in case of Wayland the wl_surface*) for a QWindow. Verbatim quote of the documentation:

The QPlatformSurfaceEvent class is used to notify about native platform surface events.

Platform window events are synchronously sent to windows and offscreen surfaces when their underlying native surfaces are created or are about to be destroyed.

Applications can respond to these events to know when the underlying platform surface exists.

Awesome! We get an event when the surface is created and when it gets destroyed. This made it very simple to create the integration and what is really important for us is that we get this event before the window is shown. So we can prepare everything so that KWin gets a good state.

And the KWin side was to a large part implemented on assumptions on how the sequence will work. We first get the surface, then the (xdg) shell surface, then the integration bits. Sure it would be nice if KWin handled also other sequences, but as the only implementation of this is Qt it doesn’t make sense to really care about it. We know that it was not perfect, we even had the test cases for it, which expect failed.

What broke with Qt 5.8?

In Qt 5.8 our complete integration broke. When the platform surface created event was emitted the wl_surface was not created, see QTBUG 58423. This is in my humble opinion a clear violation of the documented behavior and thus a breakage of the stability guarantees Qt provides, but others might disagree. After some discussion, trying out patches by those who had a Qt 5.8 build we had a patch for Qt which made things mostly work together with a patch to KWin. But at the time we had the patch ready Qt 5.8 was already declared end of life with no prospect of a Qt 5.8.1 bug fix release. For our Wayland session it was just impossible to get Qt 5.8 compatible again. All we could do was to advise distributions to not combine Qt 5.8 with the Wayland session. From our side it was fine for distros to ship Qt 5.8, but if they do they should make it impossible to install the Wayland session. The state was just too broken.

Qt 5.9

With Qt 5.9 the situation looks better. The required patch is merged, it’s an LTS release and we already had the first bug fix release. Qt wants to create more bug fix releases for it and this allows us to use it as a new target for integration. But still the situation is not as good as it used to be. If you currently use our Wayland session with Qt 5.9 you will still see quite some rough corners compared to where we were with Qt 5.7.

The main problem for us is that the platform surface regression was not the only change affecting us. Pre Qt 5.7 a wl_surface lived as long as a QWindow. Now the wl_surface gets destroyed whenever the window gets hidden and a new one created on every show. Unfortunately without a platform surface created event. This means our integration breaks as soon as a window gets hidden. E.g. after closing KRunner the integration for KRunner is broken.

We tried to address this problem in various places, but it is challenging. On the show event we don’t have the wl_surface yet (too early), on the expose event the window is already mapped (too late). This creates problems for KWin which is not prepared for the integration bits to hit when the window is mapped. Our protocols were designed with the platform surface created event semantics. For example in KRunner we face an issue with the integration. KRunner is a panel, which accepts focus and allows windows to go below, also it positions manually. Now when it gets re-shown KWin doesn’t know that this window is supposed to position itself and positions it. Now we get the request to put it as panel, KWin adjusts and moves maximized windows around. And then we get the request that the panel allows windows to go below. KWin shuffles the windows again as the maximized area changed again.

This is a rather tricky situation as we cannot really do something about it. If the window is mapped it’s too late. Even if we improve our API to handle the situation better it will be too late.

There are two possibilities to handle this: Qt stops to destroy the surface or sends a platform surface created event when it recreates the surface. The latter would be my personally preferred solution as this would match the documentation again and allow us to just use the one event handler.

Other regression

The situation around the changed behavior in Qt 5.8 caused a few steps back. Our code needed to be adjusted and that sometimes caused issues. We had a few regressions which also affected the compositor, so the stability of the whole system suffered. These issues are luckily investigated and fixed. But there are still bugs lurking in the system.

For me personally the most annoying bug is a crash in Qt which affects the auto completion of kdevelop. This makes hacking in a Wayland session rather difficult. I’m running currently a patched KWin which disables the virtual keyboard integration to not hit this issue.

A huge problem is that context menus are not marked as transient windows. This means that the Wayland compositor does not know that it is a menu and positions the menu anywhere on the screen. It gives the system a very unfinished touch.

If KRunner is closed through the escape key, the key starts to repeat on the window constantly and due to that it is not possible to open KRunner again. Similar if you start an application in Kickoff through the enter key, when opening Kickoff again it automatically launches the currently selected item. This again makes it very difficult to use the session and gives the whole system an unfinished look. We are working on a workaround for this issue in the server.

Towards the future

Qt 5.9 is here to stay and that’s what we have to use as integration target. Given that Qt 5.9 and Qt 5.7 behave very differently it will become difficult for us to maintain support for both. My suggestion is that we drop support for Qt 5.7 and require Qt 5.9 for the Wayland session. In addition there is hope that we can improve the integration. Marco and David have been working on adding support for XDG Shell unstable v6 which is already supported by Qt and makes it easier to integrate with. Once this landed in KWin Qt will be switched from wl_shell to xdg shell. This will improve the situation for us quite a bit as we then have one code path for both Qt and GTK applications.

How to prevent such regressions in the future

The change of behavior in Qt 5.8 threw our Wayland efforts back a few months. This is something we communicated to Qt quite early and it’s something which worries me a lot. We cannot spend time on changing our integration every time Qt releases a new version. Given that we need to look into how to prevent that such a situation happens again.

I hope that we can improve the integration on the testing front between Qt and KDE. We have a huge test suite which can find regressions in Qt. If Qt would run KDE’s tests during the integration phase Qt would notice regressions before they hit the code base. Given that all our tests are free software it should be possible for Qt to integrate them.

But also the other side would be interesting: if we could get the latest Qt into our CI system we could also discover breakages early. We have now a new docker based CI system which allows running multiple builds of the same change (e.g. Plasma gets build on openSUSE tumbleweed and on FreeBSD) – an image with a daily or weekly Qt snapshot could help us and Qt a lot to detect breakages early.

I also hope in openQA which allows to test the full operating system. This would spot regressions like the misplaced context menus even if KWin’s own auto tests would not spot them (KWin doesn’t care about Qt there, only about the Wayland and X11 protocols). There we might need to invest some work to make sure that KWin/Wayland can be properly run in the openQA tests.

I hope that our Plasma devs can discuss this in more detail with Qt devs during Akademy in person. Unfortunately I cannot be at Akademy this year so I cannot discuss in person.

Last but not least it is important that developers test. It would help a lot if the developers working on QtWayland test their changes in a running Plasma Wayland session. We are now overall in a state that the session is suited for hacking on. I do all my Wayland hacking in a Wayland session, experiencing all the glitches like kdevelop crashing.

Of course you might wonder what about us? Shouldn’t we KDE devs also test against the latest Qt? For me personally that is not the case. I’m working on the server side and not on the client side. I’m also not testing the latest GTK for example. Nevertheless I tried to use Qt 5.9 before it got released. Used the installer, spent a day to compile everything on top of it it, just to notice that it doesn’t have QtWayland and won’t get it. I didn’t give up that easily. So I tried to compile QtWayland myself. But when I tried to use it, it turned out to not have any keyboard support, because qtbase was compiled without support for xbkcommon. At that point I gave up. Not having QtWayland is one thing, but not being able to use keyboard is another, it’s rather pointless. The only other option is to compile Qt, but that is hardly an option as it’s really difficult to compile an actually working Qt with all components. The last times I tried, I failed, wasting days compiling. If there were usable weekly images for Qt I would be happy to try it, but of course only with a properly compiled and included QtWayland.

I provided in the past few weeks some general information about my project and hopefully helpful documentation for the multiple components I’m working with, but I have not yet talked about the work I’m doing on the code itself. Let’s change this today.

You can find my work branch on GitHub. It’s basically just a personal repository so I can sync my work between my devices, so be warned: The commits are messy as nothing is cleaned up and debug lines as well as temporary TODOs are all over the place. And to be honest up until yesterday my changes didn’t accumulate to much. For some reason no picture was displayed in my two test applications, which are Neverball and VLC.

Then on the weekend suddenly the KWin Wayland session wouldn’t even launch anymore. Well, at least this issue I was able to fix pretty quickly. But there was still no picture, it seemed the presenting just halted after the first buffer was sent to KWin and without any further messages. Neither the Xwayland server nor the client were unresponsive though. Only today I finally could solve the problem thanks to Daniel’s help. The reason for the halt was that I waited on a frame callback from KWin in order to present the next frame. But this never arrived since I hadn’t set any damage in the previous frame and KWin then wouldn’t signal a new frame. I fixed it by adding a generic damage request for now. After that the picture was depicted and moving nicely.

This is definitively the first big milestone with this project. Until now all I achieved was increasing my own knowledge by reading documentation and poking into the code with debug lines. Ok, I also added some code I hoped would make sense, but besides the compilation there was no feedback through a working prototype to see if my code was going in the right direction or if it was utter bollocks. But after today I can say that my buffer flipping and committing code at least produces a picture. And when looking at the FPS counter in Neverball I would even say, that the buffer flipping replacing all the buffer copies already improved the frame rate.

But to test this I first had to solve another problem: The frame rate was always limited to the 60 Hz of my display. The reason was simple: I called present_event_notify only on the frame callback, but in the Xwayland case we can call it directly after the buffer has been sent to the compositor. The only problem I see with this is that the Present extension assumes, that after a new Pixmap has been flipped the old one can be instantly set ready to be used again for new rendering content. But if the last Pixmap’s buffer is still used by the compositor in some way this can lead to tearing.

This hints to a fundamental issue with our approach of using the Present extension in Xwayland. The extension was written with hardware in mind. It assumes a flip happens directly on a screen. There is no intermediate link like a Wayland compositor and if a flip has happened the old buffer is not on the screen anymore. Why do we still try to leverage the Present extension support in Xwayland then? There are two important features of a Wayland compositor we want to have with Xwayland: A tear-free experience for the user and the ability to output a buffer rendered by a direct rendering client on a hardware plane without any copies in between. Every frame is perfect should also remain valid when using some legacy application and that we want no unnecessary copies is simply a question of performance improvements. This is especially important for many of the more demanding games out there, which won’t be Wayland native in the short term and some of them maybe never. Both features need the the full Present extension support in the Xwayland DDX. Without it a direct rendering application would still use the Present extension but only with its fallback code path of copying the Pixmap’s content. And for a tear-free experience we would at least need to sync these copies to the frame events sent by the Wayland compositor or better directly allow multiple buffers, otherwise we would limit our frame rate. In both cases this means again to increase the Present extension support.

I plan on writing about the Present extension in detail in the next week. So if you didn’t fully understand some of the concepts I talked about in this post it could be a good idea to check back.

Next week, KDE developers will release the beta of KDE Applications 17.08. This release will again have more applications and nearly all games ported to Qt5/KF5. While Qt4 is already no longer supported for over a year, KDE has decided to support Qt4/kdelibs4-based applications a bit longer.

The 17.08 release, however, will be the last to include Qt4/kdelibs4-based applications. This means, 17.12 will only include applications that are based on Qt5/KF5. See this mailing list discussion.

We hope to find more contributors who help porting the remaining applications. Instructions are on community.kde.org. Ask for help in our developer forum, mailing list, or IRC channel. You do not need git commit rights; you can add a patch/diff via Phabricator.

Porting Status

There used to be an automatically updated porting status page. Sadly the machine that created it stopped working because of a hardware failure; its DIMM simply died.

This week, I had the chance to run its script over a checkout of nearly all KDE repositories from cgit.kde.org. Unfortunately, the repository layout is not nicely structured into directories, and includes many unmaintained and playground repositories, but maybe it is still useful.

See http://imagezero.maxiom.de/files/portingstatus.html.

For contributors helping to get it more green, there is also a shorter version that omits all-green repositories, see portingstatus-todo.html.

Hello Folks,

This is the week after the first review phase and let me tell you, the coding process hasn’t gone smoother than this before. As my older blog posts suggest and as I have told, I was thinking of fixing the UI glitches in the content downloader GUI for this week. Since I was facing an issue in making the list view of the contents that could be downloaded, I discussed it with my mentor and he suggested that we could make the UI cleanups and other small fixes at the end. He added that these kinda fixes are only done after implementing the major features into the project. So I followed as he suggested and started to work on the main features that were required to be added into the project.

I have added a progress bar feature which will help, the user to get notified what the content downloader is doing at the moment. And implemented a details section which will give the user the large description of the content that they are going to download.

I will write done a detail description on what I did and learned from doing both of these feature implementation.

From the earlier posts, you might have seen what has happened to the UI after changing it to the mock-up design that we plan to implement. It became much worse that the test UI we created Literally, It was an epic fail when we started to re-arrange things because it wasn’t getting much space to fit in and it was getting cranky for space.

This happened in my mind after re-compilation of the content downloader’s UI.

Depicting the progress using Progressbar

At first, I thought of creating a progress indicator widget as that KNewStuff actually used. But my mind, again and again, asked me that, is it the right way to implement it? Won’t there be a better way to do that? Well, in that dilemma I asked Leinir about it and he told that the progress indicator in the KnewStuff was just an old hacky way to print out the progress to the user. And hence suggested me to use the QProgressBar.

As usual :P, I started to over think that we could get the real-time information about the progress of the content through the progress bar using the SIGNAL’s emitted by KNSCore::Engine which is busy(), idle() and error(). I thought of depicting the real time progress into the progress bar using this, but I went wrong and again Leinir to the rescue, telling me that it isn’t possible at the moment, we have to revise a new method to get the real time progress of the object.

Before getting to know this, I was like stuck at it, not getting why it wasn’t showing the result. Damn! I was stuck at there and University classes also started and were in a tough state that I had to spend time in doing college works too in between while doing the GSoC project as well. Also, for the progress bar thinking it will be showing real-time progress, I tried all possible possibilities to get it running.

Me throughout the whole week.

But at last, after getting to know we cannot show the real-time progress but we can only show the instance of what it is happening, then the rest was smooth. Created some functions to make the QProgressbar visible and set the range from (0, 0) and made them slots and connected to the signals emitted from KNSCore::Engine which gives the busy. idle and error signals.

q->connect(engine, SIGNAL(signalBusy(QString)), this, SLOT(progressBarBusy(QString)));
q->connect(engine, SIGNAL(signalIdle(QString)), this, SLOT(progressBarIdle(QString)));
q->connect(engine, SIGNAL(signalError(QString)), this, SLOT(progressBarError(QString)));

And voila!! There it is, working as expected.

Loading bar alone.

Since the SIGNAL’s emitted by the KNSCore::Engine does not only sends the progress instance of the data item getting downloaded but also sends a QString message telling the user after implementation that what the downloader is doing. Hence, that was shown in the dialog just using a QLabel to print out the QString message from the SIGNAL.

Summary Description for the data item.

Actually, in the list view, where the content’s which could be downloaded are listed, there exists a short description about what the data item is. But we decided to create a details area mostly details grid viewer to show the description. It will be visible to the user only when the user clicks the details button, then it pops up at the right of the content list. Implemented using MVC architecture as always

Here are some of the screenshots of the content downloader with the summary description added into it, There is a visual glitch to the GUI but will re-touch it after the whole implementation of features and bugs are fixed.

We just used QLabel to represent the description summary of the data into the GUI.

Work planned for the next week.

• Still, some documentation is left – complete it.
• Start the second part of the project, ie, making the UI of Bundle manager/Resource manager much more appealing and user-friendly.
• Start identifying some of its bugs and fix it.
• Try to get the UI of content downloader fixed, even though these are only needed to be done at the last.

Will discuss with my Krita team and my mentors and also some artists to look at it and give some inputs if there needs something more else and I could see if that could be done.

Here is my branch were all the work I am done is going to.

https://cgit.kde.org/krita.git/?h=Aniketh%2FT6108-Integrate-with-share.krita.org

Will be back with more updates later next week.

Cheers