21 Oct 2019

feedPlanet KDE

KDevelop 5.4.3 released

KDevelop 5.4.3 released

We today provide a stabilization and bugfix release with version 5.4.3. This is a bugfix-only release, which introduces no new features and as such is a safe and recommended update for everyone currently using a previous version of KDevelop 5.4.

You can find the updated Linux AppImage as well as the source code archives on our download page.

ChangeLog

kdevelop

  • ProblemNavigationContext: Fix incorrect link target for file:line links with declarations. (commit)
  • ProjectManagerView: Make items with an empty icon have the same indent as items with a valid icon. (commit)
  • Welcome page: fix version of QtQuick.XmlListModel import to match Qt 5.7 ff. (commit)
  • Welcome page: fix version of QtQuick.Layouts import to match Qt 5.7 ff. (commit)
  • [Grepview] Use the correct fallback icon for Collapse All. (commit)
  • FileManagerListJob: use a semaphore for locking. (commit)
  • Fix Infinite Recursion in DUChain. (commit)
  • Cache the defines/includes for gcc-like compilers per language type. (commit)
  • Only write defines file when needed. (commit)
  • Don't set super long name on completely anon structs. (commit)
  • Use type name as fallback ID for anon typedef'ed structs/unions etc. (commit. fixes bug #409041)
  • Fixed crash when filtering class list. (commit. code review D22660. fixes bug #406931)
  • Gcclikecompiler: properly resolve include paths with symbolic links. (commit. fixes bug #405221)

kdev-python

No user-relevant changes.

kdev-php

  • Fix expressions using array constants. (commit. fixes bug #405719)
  • Don't mark class constants as normal members. (commit)

kossebau Mon, 2019/10/21 - 18:31

Category
News
Tags
release

21 Oct 2019 4:31pm GMT

AAB Support in Qt for Android

Android_Robot

21 Oct 2019 12:56pm GMT

Qt 3D: One too many threads

Qt 3D makes heavy use of threads, as a way to spread work across CPU cores and maximize throughput, but also to minimize the chances of blocking the main thread. Though nice on paper, the last case eventually leads to added complexity. Sometimes, there are just one too many threads.

In the past, we've been guilty of trying to do too much within Qt 3D rather than assuming that some things are the developer's duty. For instance there was a point in time where we'd compare the raw content of textures internally. The reason behind that was to handle cases where users would load the same textures several times rather than sharing one. This led to code that was hard to maintain and easy to break. Ultimately it provided convenience only for what can be seen as a misuse of Qt 3D, which was not the the original intention.

We had similar systems in place for Geometries, Shaders… Part of the reason why we made such choices at the time was that the border between what Qt 3D should or shouldn't be doing was really blurry. Over time we've realized that Qt 3D is lower level than what you'd do with QtQuick. A layer on top of Qt 3D would have instead been the right place to do such things. We've solved some of these pain points by starting work on Kuesa which provides assets collections.

In the past couple of Qt releases we've been trying to simplify the code where it had become overly complex for debatable convenience. For Qt 5.14 we have decided to rework the threading architecture.

Before we dive into what has changed and what we gain from it, let's first go over the architecture that was in place until 5.13.

Qt 3D Threading Architecture as of 5.13

The Main Thread

This is the Qt application thread where the Qt 3D Entity/Component scene tree lives.

The Aspect Thread

This is the thread in which Aspects live. Each Aspect is responsible for maintaining an internal backend tree that reflects the frontend tree. A messaging mechanism has been set up in order to maintain frontend and backend trees in sync. Most of these messages contain a property name as a string and a value as a variant.

The ThreadPool

Each frame, based on changes and content of its backend tree, and each aspect will get a chance to schedule work that needs to be performed:

The RenderThread

Pure Qt 3D Case

This is the thread tasked to submit the rendering commands that have been created previously by the render aspect's jobs. The idea is that submitting these commands in a dedicated thread allows to unlock the Aspect and Main threads so that we can prepare content for frame n + 1 while rendering frame n.

One thing to be noted however, this thread is only available when using "pure" Qt 3D, in other words when using Qt 3D without QtQuick and Scene3D.

Scene3D Case

When using Scene3D, we instead rely on the SceneGraph Thread (which can potentially be the same as the main thread) to ask for the rendering commands to be submitted.

Since the Scene Graph thread is outside of our control, when it asks for Qt 3D to submit commands it could be that the Render aspect jobs in charge of preparing said commands have yet to be completed. To handle that case, we would return early in the renderer and expect that when we're called again in the future, jobs would finally have completed.

This means that potentially Qt Quick and Qt 3D would not be rendering at the same refresh rate. This can be seen as good or bad depending on your use case:

If 3D content is just there but not critical, then having Qt 3D not block Qt Quick can be interesting for you. If on the other hand you want Qt Quick and Qt 3D to be synched, this was until recently not possible.

The Simulation Loop

The loop behind Qt 3D that drives aspects, rendering and synchronization:

  1. We wait for the Renderer to be ready for the next frame
  2. Synchronize the aspect's backend trees by distributing change messages from the frontend tree stored in the ChangeArbiter
  3. Ask each aspect to launch jobs that need to be performed for the current frame
    • One job from the RenderAspect will notify the RenderThread that all RenderCommands have been prepared
  4. We wait for all jobs to be completed
  5. We wait for the next frame
    • Once RenderThread has all that's required for rendering, it calls proceedToTheNextFrame and does the graphics submission
    • This allows to start the next loop of the simulation loop while we are still rendering.

What has changed in 5.14?

As you can see, aspects are living in their own thread. The main reason for this is to allow Aspect to launch jobs and communicate while the main thread is blocked. This unfortunately forces to use string based messages to synchronize the trees. It also makes synching between threads to handle all cases quite difficult.

What have we done for Qt 5.14? Simply put, we've removed the Aspect Thread.

Why?

Well, what's the gain of having it? Even if the Aspect thread can spin freely while the main thread is blocked do we really benefit from this behavior?

From experience, in 90% of cases, we use Qt 3D with Scene3D. Which means that if the main thread were to be locked, Qt Quick wouldn't sync and Qt 3D wouldn't render anything.

So arguably, we have a thread that's making things more complex to handle a case that very few of us might benefit from. This benefit couldn't offset the difficulties that resulted from it:

What do we gain from that?

This now means Aspects and the simulation loop are performed in the main thread.

Gains from that are:

  1. We don't need to use messages to sync, we can just compare against the frontend nodes directly:
    • This removes lots of allocations, string comparisons
    • QVariant comparison was a huge performance hit because of the way it handles multithreading
    • Technically we could now go as far as not having a copy of the tree in the aspects
    • This should make caching commands a lot easier.
  2. This allows to have a greater control over the simulation loop:
    1. We can now decide whether Qt 3D should be in the driver seat or not
    2. Control can now be manual, done by the user
      • Makes integrating Qt 3D with 3rd party engines a lot easier
      • Scene3D integration uses that approach.
  3. Qt Quick and Qt 3D now run in sync at the same refresh rate
    • The downside is that if Qt 3D content is slow to render, Qt Quick will be impacted.
  4. Should allow us to introduce more sync stages to avoid having to wait more than 1 frames to react to things like inputs, capture request…
  5. Greatly simplifies startup and shutdown sequences.

What's next?

In a follow up article, we will see how Qt 5.14 was also modified to change the way the scene state get sync'ed between frontend and backend nodes, providing significant performance gains on very dynamic scenes.

The post Qt 3D: One too many threads appeared first on KDAB.

21 Oct 2019 8:00am GMT

20 Oct 2019

feedPlanet GNOME

Ruxandra Simion: Five-or-More Modernisation: Now You Can Properly Play It

As Google Summer of Code is officially drawing to an end, all of my attention was focused towards making the Five or More Vala version feature-complete. As you probably already know from my previous blog post, the game was somehow playable at that time, but it was missing some of the key features included in the old version.

So what’s new this time? First and foremost, you can surely notice the game board now sports a grid, which wasn’t there until now. On the same note, there are also animations used for clicking a piece on the board, for an improved gaming experience. For further accessibility, some header bar hints are available at different stages in the game: at the start of any new game, at the end of each game, as well as whenever there is no clear path between the initial position and the cell indicated by the user for the current move.


Overall final game look


By using libgnome-games-support, I was able to implement a high scores table, which gets updated each time the player gets a score ranging in the top 10 highest scores for the chosen board size. The high scores for each of all of the three categories can also be viewed as showed in the screencast below. Also, you can see I have done quite my fair share of testing the functionalities and assuring everything worked as planned ðŸ˜".


High scores


Further changes include theme changing, although this momentarily only works for the vector themes available in Five or More, namely the ball and shape themes, as implementation for raster images is not fully functional as of this moment.


Changing theme


Also, now window size is being saved in between runs, so each time the game starts it will take into consideration the last window size settings, including wether the window was full screened or not.

As for the most exciting change revealed in this blog post, it concerns playing Five or More using keyboard controls. Basically, the user can play the game by navigating with the keyboard arrows, the home, end, page up, page down and space, enter or return keys, as described in the wikipage section for using the keyboard.


Playing Five-or-More usig keyboard controls


If you have been following my journey with GSoC up closely, you probablly remember me mentioning something about extra-features in my first blog post, such as adding gamepad support, sounds, or making some design changes. I need to say I feel optimistic about getting some of these features done in the weeks to come, post GSoC. I feel the ground has been already laid down somehow for gamepad support by adding keyboard controls. Also, Five or More has already undergone some slight design changes, such as widget spacing and alignment.

20 Oct 2019 11:42pm GMT

Ruxandra Simion: Five-or-More Modernisation: It's a Wrap

As probably most of you already know, or recently found out, at the beginning of this week the GSoC coding period officially ended, and it is time for us, GSoC students, to submit our final evaluations and the results we achieved thus far. This blog post, as you can probably tell from the title, will be a summary of all of the work I put into modernising Five or More throughout the summer months.

My main task was rewriting Five or More in Vala since this simple and fun game did not find its way to the list of those included in the Games Modernisation Initiative. This fun, strategy game consists of aligning, as often as possible, five or more objects of the same shape and color, to make them disappear and score points.

Besides the Vala rewrite, there were also some other tasks included, such as migrating to Meson and dropping autotools, as well as keeping the view and logic separated and updating the UI to make this game more relatable for the public and more fresh-looking. However, after thoroughly discussing the details with my mentor, Robert Roth (IRC: evfool), more emphasis was placed upon rewriting the code to Vala, since the GSoC program is specifically designed for software development. However, slight UI modifications were integrated as to match the visual layout guidelines.

Some of the tasks, namely porting to gettext, porting to Meson and dropping autotools happened earlier on, during the pre-GSoC time frame, in the attempt to familiarise myself with the project and the tasks that would come with it.

Afterward, I started with the easier tasks and advanced towards the more complex ones. At first, I ported the application window and the preferences menu and added callbacks for each of the preferences buttons. I then continued with porting the preview widget displaying the next objects to be rendered on the game board.

Next, it was time to channel my attention towards porting the game board, handling board colour changes and resizing the board alongside the window resize, by using the grid frame functionality inside the libgnome-games-support library.

The following target was implementing the actual gameplay logic, which consisted of a pathfinding algorithm based on A*, erasing all objects of the same shape and colour aligned in a row, column or diagonal from the board, if there were either five or more than five, and adding to the score whenever that happened. I also made the object movement possible with both clicking and keyboard keys, for more ease of use.

Finishing touches included adding the high scores tables via the libgnome-games-support library, displaying an option to change the theme of the game, adding a grid to be able to make out easier the actual cells in which different shaped and coloured objects should reside, as well as updating some information contained by the help pages.

Some features, however, could not be done during the GSoC period. These included handling raster game themes, making significant UI updates, as well as some other extra-features I wanted to add, which were not part of the original project description such as gamepad support or sound effects. The fist feature mentioned in this list, handling raster images was decided upon skipping as a suggestion from my mentor, as the existing raster themes were low-resolution and did not scale well to large size and HiDPI displays.

For easier reading, I decided to also include this list of the tasks successfully done during GSoC:

All code is available by accessing this merge request link.

20 Oct 2019 11:42pm GMT

feedplanet.freedesktop.org

Hans de Goede: Disney+ streaming uses draconian DRM, avoid

First of all, as always my opinions are my own, not those of my employer.

Since I have 2 children I was happy to learn that the Netherlands would be one of the first countries to get Disney+ streaming.

So I subscribed for the testing period, problem all devices in my home run Fedora. I started up Firefox and was greeted with an "Error Code 83", next I tried Chrome, same thing.

So I mailed the Disney helpdesk about this, explaining how Linux works fine with Netflix, AmazonPrime video and even the web-app from my local cable provider. They promised to get back to me in 24 hours, the eventually got back to me in about a week. They wrote: "We are familiar with Error 83. This often happens if you want to play Disney + via the web browser or certain devices. Our IT department working hard to solve this. In the meantime, I want to advise you to watch Disney + via the app on a phone or tablet. If this error code still occurs in a few days, you can check the help center ..." this was on September 23th.

So I thought, ok they are working on this lets give them a few days. It is almost a month later now and nothing has changed. Their so called help-center does not even know about "Error Code 83" even though the internet is full of people experiencing this. Note that this error also happens a lot on other platforms, it is not just Linux.

Someone on tweakers.net has done some digging and this is a Widevine error: "the response is: {"errors":[{"code":"platform-verification-failed","description":"Platform verification status incompatible with security level"}]}". Widevine has 3 security levels and many devices, including desktop Linux and many Android devices only support level 1. In this case e.g. Netflix will not offer full HD or 4k resolutions, but otherwise everything works fine, which is a balance between DRM and usability which I can accept. Disney+ OTOH seems to have the drm features kranked up to maximum draconian settings and simply will not work on a lot of android devices, nor on Chromebooks, nor on desktop Linux.

So if you care about Linux in any way, please do not subscribe to Disney+, instead send them a message letting them know that you are boycotting them until they get their Linux support in order.

20 Oct 2019 1:23pm GMT

feedPlanet GNOME

Hans de Goede: Disney+ streaming uses draconian DRM, avoid

First of all, as always my opinions are my own, not those of my employer.

Since I have 2 children I was happy to learn that the Netherlands would be one of the first countries to get Disney+ streaming.

So I subscribed for the testing period, problem all devices in my home run Fedora. I started up Firefox and was greeted with an "Error Code 83", next I tried Chrome, same thing.

So I mailed the Disney helpdesk about this, explaining how Linux works fine with Netflix, AmazonPrime video and even the web-app from my local cable provider. They promised to get back to me in 24 hours, the eventually got back to me in about a week. They wrote: "We are familiar with Error 83. This often happens if you want to play Disney + via the web browser or certain devices. Our IT department working hard to solve this. In the meantime, I want to advise you to watch Disney + via the app on a phone or tablet. If this error code still occurs in a few days, you can check the help center ..." this was on September 23th.

So I thought, ok they are working on this lets give them a few days. It is almost a month later now and nothing has changed. Their so called help-center does not even know about "Error Code 83" even though the internet is full of people experiencing this. Note that this error also happens a lot on other platforms, it is not just Linux.

Someone on tweakers.net has done some digging and this is a Widevine error: "the response is: {"errors":[{"code":"platform-verification-failed","description":"Platform verification status incompatible with security level"}]}". Widevine has 3 security levels and many devices, including desktop Linux and many Android devices only support level 1. In this case e.g. Netflix will not offer full HD or 4k resolutions, but otherwise everything works fine, which is a balance between DRM and usability which I can accept. Disney+ OTOH seems to have the drm features kranked up to maximum draconian settings and simply will not work on a lot of android devices, nor on Chromebooks, nor on desktop Linux.

So if you care about Linux in any way, please do not subscribe to Disney+, instead send them a message letting them know that you are boycotting them until they get their Linux support in order.

20 Oct 2019 1:23pm GMT

17 Oct 2019

feedplanet.freedesktop.org

Peter Hutterer: libinput and tablet pad keys

Upcoming in libinput 1.15 is a small feature to support Wacom tablets a tiny bit better. If you look at the higher-end devices in Wacom's range, e.g. the Cintiq 27QHD you'll notice that at the top right of the device are three hardware-buttons with icons. Those buttons are intended to open the config panel, the on-screen display or the virtual keyboard. They've been around for a few years and supported in the kernel for a few releases. But in userspace, they events from those keys were ignored, casted out in the wild before eventually running out of electrons and succumbing to misery. Well, that's all changing now with a new interface being added to libinput to forward those events.

Step back a second and let's look at the tablet interfaces. We have one for tablet tools (styli) and one for tablet pads. In the latter, we have events for rings, strips and buttons. The latter are simply numerically ordered, so button 1 is simply button 1 with no special meaning. Anything more specific needs to be handled by the compositor/client side which is responsible for assigning e.g. keyboard shortcuts to those buttons.

The special keys however are different, they have a specific function indicated by the icon on the key itself. So libinput 1.15 adds a new event type for tablet pad keys. The events look quite similar to the button events but they have a linux/input-event-codes.h specific button code that indicates what they are. So the compositor can start the OSD, or control panel, or whatever directly without any further configuration required.

This interface hasn't been merged yet, it's waiting for the linux kernel 5.4 release which has a few kernel-level fixes for those keys.

17 Oct 2019 11:23pm GMT

Peter Hutterer: libinput and button scrolling locks

For a few years now, libinput has provided button scrolling. Holding a designated button down and moving the device up/down or left/right creates the matching scroll events. We enable this behaviour by default on some devices (e.g. trackpoints) but it's available on mice and some other devices. Users can change the button that triggers it, e.g. assign it to the right button. There are of course a couple of special corner cases to make sure you can still click that button normally but as I said, all this has been available for quite some time now.

New in libinput 1.15 is the button lock feature. The button lock removes the need to hold the button down while scrolling. When the button lock is enabled, a single button click (i.e. press and release) of that button holds that button logically down for scrolling and any subsequent movement by the device is translated to scroll events. A second button click releases that button lock and the device goes back to normal movement. That's basically it, though there are some extra checks to make sure the button can still be used for normal clicking (you will need to double-click for a single logical click now though).

This is primarily an accessibility feature and is likely to find it's way into the GUI tools under the accessibility headers.

17 Oct 2019 10:56pm GMT