GTK 4 to be Released Next Fall

Among other things, the team has decided that before the final release, it is necessary to bring to the end 5 planned functional changes
02 September 2019   1141

A plan for the formation of the GTK 4 release has been outlined. It is noted that it will take about another year to bring GTK 4 to its proper form (GTK 4 has been developing since summer 2016). Until the end of 2019, it is planned to prepare another experimental release of the GTK 3.9x series, then in the spring of 2020 the final test release of GTK 3.99 will be offered, which includes all the intended functionality. The release of GTK 4 is expected in early fall 2020, simultaneously with GNOME 3.38.

Before the final release, it is necessary to bring to the end five planned functional changes, including the work of replacing fixed widgets with scalable views, a new API for animating and translating effects and indicators of progress on it, completing the processing of the pop-up menu system (developing ideas related to nested submenus and drop-down menus), replacing the old hotkey system with event handlers, finalizing the new API for Drag & Drop operations.

Among the optional features that team would like to add before the release of GTK 4, the "UI designer" widget, improved means for splitting the upper panels and the widget repository through which experimental widgets can be delivered without integration into the main structure of GTK stand out. The development of tools for porting applications to GTK4 is also mentioned, for example, the preparation of the corresponding versions of the GtkSourceView, vte and webkitgtk libraries, as well as the provision of platform support. For example, the OpenGL-based rendering system works well on Linux, but the Vulkan-based rendering system still needs to be improved. On Windows, the Cairo library is used for rendering, but an alternative implementation based on ANGLE (a layer for translating OpenGL ES calls to OpenGL, Direct3D 9/11, Desktop GL and Vulkan) is under development. For macOS, a fully functional rendering backend is not yet available.

Google Works on Linux Kernel Support in Android

This goal has already been partially achieved - Xiaomi Poco F1 Android smartphone has firmware based on the usual unmodified Linux kernel
21 November 2019   86

At the last Linux Plumbers 2019 conference, Google talked about the development of an initiative to transfer to the main Linux kernel the changes developed in the kernel version for the Android platform. The ultimate goal is to enable Android to use one common core, instead of preparing separate assemblies for each device based on the Android-specific Android Common Kernel branch. This goal has already been partially achieved, and the Xiaomi Poco F1 Android smartphone with firmware based on the usual unmodified Linux kernel was demonstrated at the conference.

After the project is ready, suppliers will be asked to supply a core kernel based on the main Linux kernel. Components for hardware support will be supplied by suppliers only in the form of additional kernel modules, without imposing patches on the kernel. In modules, compatibility with the main core at the level of the kernel symbol namespace must be ensured. All changes affecting the main core will be promoted to upstream. To maintain compatibility with proprietary modules within the framework of LTS branches, it is proposed to maintain stable kernel API and ABI, which will allow to maintain compatibility of modules with updates for each common kernel branch.

Over the year, features such as the PSI (Pressure Stall Information) subsystem for analyzing information on the waiting time for various resources (CPU, memory, input / output), the BinderFS pseudo-file system for the interprocess communication mechanism were transferred to the main Linux kernel from the Android kernel Binder and energy-efficient task scheduler EAS (Energy Aware Scheduling). In the future, it is planned to transfer Android from a specific SchedTune scheduler to the new UtilClamp subsystem developed on ARM, based on cgroups2 and standard kernel mechanisms.

Recall that so far the kernel for the Android platform has gone through several stages of preparation:

On the basis of the main LTS kernels (3.18, 4.4, 4.9 and 4.14), the “Android Common Kernel” branch was created, into which Android-specific patches were transferred (previously the size of the changes reached several million lines, but recently the changes were reduced to several thousand lines of code )
Based on the Android Common Kernel, chip makers such as Qualcomm formed the SoC Kernel, which includes add-ons to support hardware.
Based on SoC Kernel, device manufacturers created Device Kernel, which includes changes related to support for additional equipment, screens, cameras, sound systems, etc.

In fact, for each device its own core was formed, which could not be used on other devices. Such a scheme significantly complicates the delivery of updates with the elimination of vulnerabilities and the transition to new kernel branches. For example, the latest Pixel 4 smartphone released in October comes with the Linux 4.14 kernel, released two years ago. In part, Google tried to simplify maintenance by promoting the Treble system, which allows manufacturers to create universal hardware support components that are not tied to specific Android versions and the used Linux kernel releases. Treble makes it possible to use ready-made updates from Google as a basis, integrating device-specific components into them.