快轉到主要內容

KDE Plasma與GNOME桌面比較,最終我還是選擇KDE

人文藝術 自由軟體議題 Linux GNOME KDE Plasma
🗓️ 民國112年 癸卯年
✍ 切換正體/簡體字
目錄

本文討論為何Ivon我偏好KDE Plasma勝過GNOME當Linux桌面的理由。我盡量先從客觀的角度來比較兩者差異,再過度到極度主觀的個人意見。

目前Linux發行版有20種以上的桌面環境供使用者選擇,其中最常見的就是「GNOME」和「KDE Plasma」了。從下面這張圖就可以看出他們的設計語言差別巨大。

得益於Linux的高自由度,Linux可以多重桌面環境共存,但是大多數人都會習慣使用在裝系統的時候就裝的桌面吧?安裝過程需要自行組裝的「Arch Linux」亦同。

我在不同的電腦裝Arch Linux,曾嘗試裝過GNOME和KDE Plasma桌面,經過幾個月反覆比較後,得出了我未來偏好桌面環境的抉擇:若要distro-hopping,那就是以KDE Plasma為優先考量,GNOME次之。也就是說裝桌面環境一律以KDE Plasma為主。

Source: https://www.reddit.com/r/linuxmasterrace/comments/tj03r4/totally_unbiased_meme_that_isnt_going_to_make/

為什麼我會這樣認為?請看下面分曉。

  • 作業系統:Arch Linux
  • 通訊協定:X11,偶爾用Wayland
  • GNOME版本:44
  • KDE Plasma版本:5.27.6
  • GPU廠牌:Nvidia

本文提及的GNOME和KDE桌面皆是指「原版無修改」的vanilla版,像Ubuntu這種重度patch的不算在列。

先從一個好玩的統計資料開始。 Arch Linux官方有統計桌面環境套件安裝量,我們可以發現KDE在2018年後下載量是逐漸超過GNOME和XFCE的。

1. 穩定度比較
#

常見的說法是,同為開源專案,GNOME的程式碼有來自各大商業公司的支援維護,包括Redhat。他們會將GNOME當作自家商業發行版的桌面,那可是要部署到關鍵伺服器上的,所以不會隨便糟蹋專案(?)

GNOME每六個月固定發表一個大版本,相較之下KDE新版本的排程不固定。

參考這張2020年的圖表,你可以看到GNOME前幾名的開發貢獻者都是耳熟能詳的大公司,雖然Debian社群比重也很高就是了。 資料來源

相較之下,KDE就是純民間社群,雖有企業贊助,但似乎都是世界各地的開發者互相合作得來的成果。且採用KDE的商業Linux發行版較GNOME少,著名的只有openSUSE和Kubuntu,古早的Mandriva Linux已經死翹翹了。

那麼KDE程式碼如此龐雜的情況要如何維持專案進行?

其實KDE很強調全球社群的協調,使得專案不至於非常混亂,每個國家都有KDE在地化小組負責翻譯界面。KDE社群編寫的規則、手冊、文件也是十分詳細,跟GNOME官網的開發文件不相上下。

KDE的貢獻者人數一直都很活躍,各大Linux發行版都有許多開發者維護KDE套件。

以下2020年的圖表顯示KDE貢獻者人數逐年增加,很多還是新血。 資料來源


我自己用Arch,不論GNOME還是KDE都甚少崩潰,桌面環境不會擺在那邊,什麼都不做就自己崩潰。即使是在跑重度繪圖計算、開虛擬機、玩大型遊戲情況下,這些桌面能游刃有餘。

GNOME和KDE對X11支援都很成熟了,應用程式縮放和多螢幕支援開箱即用,通常不需要指令。

至於未來主流的顯示協定「Wayland」支援度來說,一開始是GNOME領先,後來KDE也迎頭趕上了。儘管GNOME和KDE都逐步放棄X11,新功能都往Wayland加,例如支援觸控板手勢、更好的多螢幕支援、HDR等,但Wayland穩定度仍然不如X11,大部分時候我還是待在X11。

就現況而言,我很難推薦人家用Wayland,無論哪個桌面環境。這又跟顯示卡問題無關,Nvidia閉源驅動導致Wayland不穩定是2022年以前的問題,現在已經改善很多。最主要是Wayland模式下很程式仍有很多bug,例如Flatpak版LibreOffice字體模糊、Google Chrome預設跑在XWayland下導致效能不彰、Fcitx5輸入法無法喚醒、KDE圖示不見、繪圖板不支援等問題。

開發者應該要讓應用程式開箱即用,而無需設定一堆環境變數強迫應用程式跑Wayland,或者逼使用者自行找workaround解決各種小bug。等到99%應用程式優先以Wayland支援我才能完全切換到Wayland。

2. 附屬應用程式比較
#

講到附屬應用程式,我們一定會談到「BLOATED」這個話題,這是Linux社群常批評Windows系統的話:系統肥大。

此時的GNOME和KDE:

我跟你說,Arch Linux有"package group"能一次裝該桌面環境的相關套件,俗稱全家桶,從瀏覽器到小遊戲全包的那種。

全家桶可以類比為「附屬應用程式」,GNOME與KDE在安裝全家桶的情況下,二個桌面環境都一樣肥,套件大小3~5GB,開機佔用的RAM起碼都有1GB。

硬要比的話,KDE桌面的依賴套件比GNOME多很多,因為有些發行版的KDE全家桶連元素週期表都有,還有一些KDE自己發明的背單字小工具,使得日後拆掉KDE要花很多時間。

Arhc Linux光kde-applications的group就有176個套件

儘管Arch Linux允許把桌面環境跟附屬應用程式拆開裝,但裝這些附屬應用程式並不是壞事,他們能讓使用者方便些,不需要額外安裝軟體便能完成日常事務的處理。

儘管KDE軟體多,若比較應用程式的功能,就會發現KDE系的應用程式通常也是比較多功能的,GNOME的應用程式功能普遍很精實。

諸如圖片檢視器Eye of Gnome對比 KDE Gwenview。Gwenview編輯圖片的功能要方便太多了,有時候甚至不用開GIMP就能修好圖。

影片播放器Gnome Totem對比KDE Dragon Player…其實這二個都不好用啦。

文字編輯器GNOME Gedit對比KDE Kate。Kate整合搜尋目錄和Git編輯功能因此略勝一籌。

GNOME截圖工具 對比 KDE Spectacle。前者完全被後者屌打,Spectacle能延時截圖、標記、截圖後編輯、複製到剪貼板等操作。

以上僅供比較,其實很多程式我是不會用桌面環境全家桶的附屬應用程式的,會另外找替代品,例如影片播放器我會找VLC,截圖工具有Flameshot,螢幕錄影有OBS Studio等。

最後還有重要的檔案管理員界面對比,這是下一節要講的主題。

3. 檔案管理員界面比較
#

檔案管理員是桌面環境重要的一環,因為每天都會用到,所以要挑個順手的來使用。

GNOME預設的檔案管理員叫Nautilus,KDE的叫Dolphin。

Nautilus包含基本的瀏覽檔案、掛載遠端硬碟的功能。

這些Dolphin都有,還更強。

例如顯示檔案目錄結構只有Dolphin做的到

Dolphin尚能整合其他搜尋用的應用程式。

KDE Dolphin不會把遠端硬碟掛載的功能藏在「地址」欄位裡面,而是有貼心的圖形化引導設定。


在檔案選擇器(file chooser)方面,Dolphin也比較好用。

即使Linux可以自由切換檔案管理員,但是常常是跟桌面環境耦合在一起的,意即應用程式在出現檔案選擇器時可能只會呼叫GTK而非Dolphin。Firefox還好些,可以用環境變數GTK_USE_PORTAL=1試圖使用Dolphin當預設的檔案選擇器,但是其他的應用程式就不見得是這樣的了,有些還是硬編碼的,不遵守XDG規範。

GTK的檔案選擇器到最近幾年才加入縮圖功能,還是差強人意。

然而還是沒Dolphin好用。Dolphin能即時在選取檔案的框框內刪除、變更檔案。

一個桌面環境下的應用程式是很難移動到另一個環境使用的,更多的是整合度用下來,奇檬子的問題。

4. 軟體商店比較
#

現代人誰何嘗不希望Linux系統能像手機點一點安裝應用程式,而不是用指令裝一堆套件。所幸現在不論是GNOME還是KDE,都逐步將套件管理員整合到應用程式商店了,讓使用者能方便搜尋程式。

但就是應用程式商店,不同桌面提供的體驗也不太一樣。

GNOME Software的界面比KDE Discover好看一點。

KDE Discover看起來像軟體目錄而非商店。

…GNOME Software也就界面好看一點而已,GNOME Software下載軟體沒有明確的進度條,點進去還會顯示沒在安裝,很容易讓人誤以為卡死,整個回應緩慢。

KDE Discover雖然一整個工程師風格,可確實有讓人知道目前進度的安心感。

5. 自定義程度比較
#

我不是那種像r/unixporn的用戶喜歡玩極致美化、從頭尻出桌面的人。只是有時候想加一些小元件,卻發現GNOME步驟十分麻煩。

在GNOME與KDE皆安裝全家桶的情況下,GNOME還是需要裝擴充套件我才會用得好。

GNOME應用程式列表搞的像手機一樣,程式一多很難找。

預設乾淨的GNOME不加任何擴充套件真的用不下去。要我習慣視窗沒有縮小、放大鍵,以及以工作區為主的模式我沒意見,我有嘗試過以工作區為主的工作方式,可是預設GNOME畫面上的功能太少了。

通常我會開 Extension Manager抓一些擴充套件,把它整成這樣才用的下去。例如開左上角的應用程式分類選單解決應用程式不好找的問題、安裝右上角的輸入法指示器方便切換Fcitx5的簡繁輸出,以及將「桌面捷徑」的功能加回來。


相較之下,KDE不用去裝一堆有的沒的擴充元件,內建的就夠我玩了,想怎麼擺放桌面元件隨意放。

KDE的系統設定可以調整的東西很多,將很多指令的東西都圖形化了,連防火牆都有整合。就算調壞了,按一下回復預設值即可。

別看KDE選項這麼多好像很複雜,其實不然,一般使用者一進入桌面也不用調什麼,預設就很好用了。

另外,GNOME沒有像KDE一樣對應用程式按右鍵,快捷編輯應用程式啟動選項的功能。

此功能用來找出應用程式安裝位置很有用處,也能在裡面加入額外啟動參數。換作在GNOME,就得用到命令行去編輯desktop entry檔案了。

KDE要安裝主題和小工具也不是難事,KDE在系統各處加入了一鍵下載主題的功能,不必像GNOME、XFCE一樣要手動將主題解壓縮放到指定位置。

KDE要把桌面的工作列元件全拆裝其他Dock也不會阻止你,甚至還可以搞 動態桌布引擎呢,自由度比較高。

不過共識是,我不喜歡把東西放在桌面,這點KDE和GNOME皆然,所以我沒在放桌面小工具。

GNOME的設計其實很適合觸控裝置,大圖示、支援手勢之類的,平板電腦或手機會用的不錯。可是若是以傳統桌上型電腦來看,我還是比較愛KDE那種使用方式。

6. GTK相較於QT實在太醜了
#

這是非常主觀的一個段落。

GNOME的附屬應用程式多半使用GTK開發,GTK 4以前有點擬物化的風格。KDE則是採用QT,預設主題叫Breeze,在QT5之後全面扁平化。

GNOME預設的GTK主題叫做Adwaita,黑色模式下還不錯,白色實在不好看。Ubuntu有Yaru主題,但還是不行;PopOS研發的扁平風格更醜,elementaryOS硬要向MacOS靠攏;ZorinOS向著Windows的方向去了,無須贅言。

GNOME採用最新GTK 4撰寫的應用程式風格我比較能接受,跟QT一樣的扁平化風格,例如這款新的GNOME終端機就比KDE Konsole好看一些。

但一堆GKT應用程式還在使用舊版GTK,例如Firefox。參考下圖GTK與QT主題比較,就知道有多醜。

GNOME下的QT應用程式會被變成GTK風格,靠近看變得更醜了。

相較之下,KDE下的GTK應用程式顯得沒那麼不堪了,GTK會自動變成KDE風格的主題。舊版GTK的應用程式也不會那麼難看。

那何不換圖示就好了?GNOME也是支援換圖示和主題的呀。老實說,不論是GNOME換Breeze圖示,還是KDE換Adwaita圖示,都是很不搭嘎的組合,所以我不會這樣做。

桌面環境應該有自己獨特的美感,而非要後天裝一堆主題來美化。GNOME和KDE都做到了自己的美感,只是我更愛KDE的風格。

7. 結語
#

總的來說,KDE操作比較接近Windows,功能多且界面自定義程度更高。

GNOME操作接近MacOS,應用程式風格統一且界面更加極簡化。

我認為,不論GNOME如何強調「簡潔易用」,它還是不如KDE的「方便強大」。

Linux用戶有選擇的自由,我偏好KDE,較符合工作流程和習慣而已。GNOME和KDE二者並非是你死我活競爭的關係,無非是有自己的目標客群罷了。而二者應彼此借鏡,發展統一標準,改善Linux桌面環境生態。

附錄:搭載KDE桌面的Linux發行版
#

以下Linux發行版預設就是KDE桌面:

  • openSUSE
  • Kubuntu(KDE桌面 + Ubuntu LTS套件,更新比較慢但穩定)
  • KDE Neon(最新版KDE桌面 + Ubuntu LTS套件)
  • KaOS
  • Fedora KDE Spin
  • SteamOS

以下Linux發行版KDE桌面要自己裝,或者說官網首頁提供的ISO不是搭載KDE:

  • Manjaro
  • Debian
  • Arch Linux
  • Ubuntu
  • Fedora
  • Gentoo

相關文章

Linux系統用Flatpak安裝軟體的優缺點
人文藝術 自由軟體議題 Flatpak Linux
Android是最好的Linux發行版?對Linux桌面發行版的怨氣
人文藝術 自由軟體議題 Free Software Android Linux
監控更甚以往,我們能做些什麼?讀史諾登《永久檔案》心得
人文藝術 自由軟體議題 Linux

留言板

此處提供二種留言板。點選按鈕,選擇您覺得方便的留言板。要討論程式碼請用Giscus,匿名討論請用Disqus。

這是Giscus留言板,需要Github帳號才能留言。支援markdown語法,若要上傳圖片請貼Imgur連結。您的留言會在Github Discussions向所有人公開。

這是Disqus留言板,您可能會看到Disqus強制投放的廣告。有時留言可能會被系統判定需審核,導致延遲顯示,請見諒。