The developers of the Budgie desktop environment have decided to move away from using the GTK library in favor of the EFL (Enlightenment Foundation Library) libraries developed by the Enlightenment project. The results of the migration will be offered in the release of Budgie 11. It is noteworthy that this is not the first attempt to move away from using GTK - in 2017 the project already decided to switch to Qt, but later revised plans, in the hope that this would change in GTK4.
Unfortunately, GTK4 did not live up to the expectations of the developers due to the continued focus only on the needs of the GNOME project, the developers of which do not listen to the opinions of alternative projects and are unwilling to consider their needs. The main impetus for moving away from GTK was GNOME's plans to change the way it works with skins, which makes it difficult to create custom skins in third-party projects. In particular, the style of the platform interface is provided by the libadwaita library, which is linked to the Adwaita theme.
Creators of third-party environments who do not want to completely repeat the GNOME interface should prepare their libraries for style processing, but in this case there is inconsistency in the design of applications that use the alternative library and the platform theme library. There is no native means to add additional features to libadwaita, and attempts to add a Recoloring API that would allow easy color changes in applications could not be agreed upon due to concerns that non-Adwaita themes could negatively affect the quality of applications for GNOME and make it more difficult to analyze problems. at users. Thus, the developers of alternative desktops found themselves tied to the Adwaita theme.
Among the features of GTK4 that cause dissatisfaction among Budgie developers, the exclusion of the possibility of changing some widgets through the creation of subclasses, the transfer to the category of obsolete X11 APIs that are not compatible with Wayland (for example, in Budgie calls GdkScreen and GdkX11Screen were used to determine the connection and change the configuration of monitors) ), scrolling issues in the GtkListView widget, and missing the ability to handle mouse and keyboard events in GtkPopovers if the window is not in focus.
After weighing all the pros and cons of switching to alternative toolkits, the developers came to the conclusion that the most optimal is the transition of the project to the use of EFL libraries. The transition to Qt is considered problematic due to the binding of this library to C ++ and the uncertainty in the future licensing policy. Most of the Budgie code is written in Vala, but a C or Rust toolkit was allowed as migration options.
For the Solus distribution, the project will continue to generate an alternative build based on GNOME, but this build will be marked as uncurated by the project and placed in a separate section on the download page. After the release of Budgie 11, developers will evaluate its capabilities compared to the GNOME Shell and decide whether to continue building the GNOME build or stop, providing tools to migrate to the Budgie 11 build. to analogues, including those developed within the project. For example, it is planned to develop its own application installation center.
Recall that the Budgie desktop offers its own implementation of the GNOME Shell, panel, applets, and notification system. To manage windows, the Budgie Window Manager (BWM) window manager is used, which is an extended modification of the basic Mutter plugin. Budgie is based on a panel that is similar in organization to the classic desktop panels. All panel elements are applets, which allows you to flexibly customize the composition, change the layout and replace the implementations of the main panel elements to your liking. Available applets include the classic application menu, task switcher, open window list area, virtual desktop view, power management indicator, volume control applet, system status indicator, and clock.
Source: opennet.ru