Budgie 桌面環境的開發人員已決定放棄使用 GTK 庫，轉而使用由 Enlightenment 項目開發的 EFL（啟蒙基金會庫）庫。 遷移的結果將在 Budgie 11 的發布中提供。值得注意的是，這並不是第一次嘗試放棄使用 GTK - 在 2017 年該項目已經決定切換到 Qt，但後來修改了計劃，在希望這會在 GTK4 中改變。
不幸的是，GTK4 沒有辜負開發者的期望，因為繼續只關注 GNOME 項目的需求，開發者不聽取替代項目的意見，也不願意考慮他們的需求。 放棄 GTK 的主要推動力是 GNOME 計劃改變它使用皮膚的方式，這使得在第三方項目中創建自定義皮膚變得困難。 特別是，平台界面的樣式是由 libadwaita 庫提供的，它鏈接到 Adwaita 主題。
不想完全重複 GNOME 界面的第三方環境的創建者應該為樣式處理準備他們的庫，但在這種情況下，使用替代庫和平台主題庫的應用程序的設計存在不一致。 沒有向 libadwaita 添加額外功能的本機方法，並且由於擔心非 Adwaita 主題可能會對 GNOME 和使用戶更難分析問題。 因此，替代桌面的開發人員發現自己與 Adwaita 主題聯繫在一起。
在引起 Budgie 開發人員不滿的 GTK4 功能中，排除了通過創建子類更改某些小部件的可能性，轉移到與 Wayland 不兼容的過時 X11 API 的類別（例如，在 Budgie 中調用 GdkScreen和 GdkX11Screen 用於確定連接和更改監視器的配置）），GtkListView 小部件中的滾動問題，並且如果窗口未處於焦點，則缺少在 GtkPopovers 中處理鼠標和鍵盤事件的能力。
在權衡了切換到替代工具包的所有利弊之後，開發人員得出的結論是，最優化的是將項目過渡到使用 EFL 庫。 由於該庫與 C++ 的綁定以及未來許可政策的不確定性，向 Qt 的過渡被認為是有問題的。 大多數 Budgie 代碼是用 Vala 編寫的，但允許使用 C 或 Rust 工具包作為遷移選項。
對於 Solus 發行版，該項目將繼續生成基於 GNOME 的替代構建，但該構建將被項目標記為未管理，並放置在下載頁面的單獨部分中。 Budgie 11 發布後，開發人員將評估其與 GNOME Shell 相比的功能，並決定是繼續構建 GNOME 構建還是停止構建，提供工具以遷移到 Budgie 11 構建。 例如，計劃開發自己的應用程序安裝中心。
回想一下，Budgie 桌面提供了它自己的 GNOME Shell、面板、小程序和通知系統的實現。 為了管理窗口，使用了 Budgie Window Manager (BWM) 窗口管理器，它是基本 Mutter 插件的擴展修改。 Budgie 基於在組織上類似於經典桌面面板的面板。 所有面板元素都是小程序，允許您根據自己的喜好靈活地自定義組合、更改佈局和替換主要面板元素的實現。 可用的小程序包括經典應用程序菜單、任務切換器、打開的窗口列表區域、虛擬桌面視圖、電源管理指示燈、音量控制小程序、系統狀態指示燈和時鐘。
來源： opennet.ru