Recently the developers of the Budgie desktop environment made it known that they have made the decision to move away from the GTK library in favor of the Enlightenment Foundation Library (EFL).
Esto is due to which mentions that unfortunately, GTK4 didn't live up to expectations from developers, toother than that the continuous approach only focuses on the needs of the GNOME project, whose developers do not listen to the opinions of alternative projects and do not want to take their needs into account.
The main incentive to get away from GTK it was GNOME's plans to change the way it works with themes, making it difficult to create custom themes in third-party projects. In particular, the interface style of the platform is provided by the libadwaita library, which is linked to the Adwaita theme.
Third-party developers who do not want to fully replicate the GNOME interface should prepare their libraries to handle the styling, but in this case, there is a discrepancy in the design of applications that use the alternative library and the platform's theme library.
As such, they also mention that there is no standard means to add additional functions to libadwaita, and attempts to add the recoloration API, that would facilitate the change of colors in the applications, could not be reconciled due to concerns that other issues in addition to Adwaita, they could negatively affect the quality of GNOME applications and complicate the analysis of problems for users.
Therefore, the alternative desktop developers stuck to the Adwaita theme.
Between theThe GTK4 Features You Dislike to Budgie developers, the exclusion of the possibility to change some widgets by creating subclasses, transferring to the category of outdated X11 APIs which not compatible with Wayland (for example, in Budgie, calls GdkScreen and GdkX11Screen was used to determine connection and change monitor settings), problems with scrolling in the widget gtkListView and the loss of ability to handle mouse and keyboard events in GtkPopovers if the window is out of focus.
Having weighed all the pros and cons of switching to alternative toolkits, the developers concluded that the most optimal is the transition of the project to the use of the EFL libraries.
The transition to Qt was recognized as problematic due to the linking of this library in C ++ and uncertainties in future licensing policy. Most of Budgie's code is written in Vala, but other languages such as C or Rust were allowed as migration options.
Regarding the distribution of Solus, the project will continue to form an alternate build based on GNOME, but this build will be marked as unsupervised by the project and it will be assigned to a separate section on the download page.
As a reminder, the Budgie desktop offers its own GNOME Shell implementation, panels, applets, and notification system. To manage the windows, the Budgie Window Manager (BWM) is used, which is an extended modification of the basic Mutter plugin. Budgie is based on a panel that is similar in work organization to classic desktop panels. All panel elements are applets, allowing you to flexibly customize the composition, change the location and replace the implementation of the main panel elements to your liking.
Migration results will be offered in Budgie 11. In particular, this is not the first attempt to move away from GTK since in 2017 the project already made the decision to switch to Qt, but later revised the plans in the hope that the situation would change in GTK4.
After the release of Budgie 11, developers will evaluate its capabilities against GNOME Shell and decide to continue building the build with GNOME or discontinue providing tools to migrate to build from Budgie 11.
In the Solus compilation with the Budgie 11 desktop, it is planned to review the composition of the applications, replacing the GNOME applications with analog ones, including those developed within the project. For example, it is planning to develop its own application installation center.
Source: https://joshuastrobl.com/