新專案 LXTerminal 和 LXLauncher2 嘗鮮!

長久以來,總是找不到 Lightweight 的終端機程式,因此在 LXDE 上一直好像缺少了什麼。而 GNOME-Terminal 之肥,實在令人不敢恭維;XFCE4-Terminal 夠輕,但需依賴 XFCE4-Library ,在 LXDE 裡使用就顯得有點愚蠢;而 Roxterm 什麼都好,但效能極差,在我的 EeePC + Compiz 上,回應的速度實在是令人難以接受;至於 Sakura,因缺少 Process Sharing 機制,所以記憶體用量大,完全無法與 XFCE4-Terminal 相比;而 Evilvte 縱使省掉 GUI ,但因為 Based on sakura 所以情況差不了多少,Lilyterm 等其他號稱輕量的 Terminal,則也都幾乎有著相同的缺點。有些 Terminal 還使用了 Dbus ,更是先被我打上大叉叉。

其實這得怪罪於 VTE 本身的癡肥和問題,使 Terminal 的開發者沒有一個不用 dirty hacking 的方式,去解決所有的 Bugs 和減少記憶體用量,研讀各家的 Source Code 就能發現其端昵。在自己實作後,也發現其難度。

但為了使 LXDE 有個良好又輕量的開發環境〔只是為了這單純的目的〕,LXTerminal 還是誕生了,雖然目前功能不多,但可支援 Tab、更改字型、剪貼字串,比較可惜的地方是尚未支援 Process Sharing,所以記憶體用量上稍微大了些。不過此功能已著手開發,在正式 Release 時就會支援。

EeePC 上的 LXDE

另外從 Screenshot 裡可以看到,LXLauncher2 緒勢待發,架構其實已經完全改變,現在可支援多層目錄,背景也改用 Cairo 畫。其中有趣的是,改用了 gnome-menu 來處裡 .desktop 等分類的問題,不過別擔心, gnome-menu 並不需要依賴其他 GNOME 的東西,總體上也還算輕盈。

據 PCMAN 所說,在 svn head 的 gnome-menu 改用痴肥的效能殺手 gio,而現在版本只有使用 GLib,所以未來將考慮 fork 目前的版本,或許將會叫做 lx-menu 也說不定。

或許有人會好奇,LXLauncher 連 1.0 都還沒出,怎麼就出現了 LXLauncher2 ?因為 LXLauncher 一直只是實驗階段的實作,擁有不少問題,所以將可能如同 lxsession 被放棄。而這新版 Launcher 其實全名叫做 LXLauncher-gmenu,是因為要與之前版本的 Launcher 做區分,所以我們暫且稱做 LXLauncher2,以防混淆罷了。

目前這些新的專案,可從 LXDE SVN 上找到,有興趣的人可以嘗鮮看看。 :-)

留言

  1. lxlauncher2 跟 gnomefiles 裡面的 lxlauncher-0.2 不一樣嗎?我看 0.2 好像也支援了 libgnome-menu。

    回覆刪除
  2. lxlauncher-gmenu 最後還是被直接當成下一版的 lxlauncher 0.2。

    不過在 Release 之前,我們都把它當做新的 Project 來看,因為它是完全重寫的專案。

    所以以後仍稱為 LXLauncher ,其他只是過渡期的名稱。

    回覆刪除
  3. hi Fred, 您寫 code 我很尊重您的專業,也很高興這個社會有您這樣的善心人願意投身自由軟體。我只是個無恥無貢獻自由軟體消費者。但您指名道姓列舉這麼多的 Terminal 貶損他人成就,來凸顯自己 code 的偉大,這樣做未免太不道德了。

    我知道自己生的小孩最好,您的 code 如果不好也不會願意發表,但別人的 code 也相同是他人心血。正面評論,缺失報告,這很好,任何人都歡迎,但你的表答方式,除了討戰外,我看不出任何建議及價值。

    貶損他人然後強調自己好,這樣的宣傳手法是很不道德的。

    lloyd huang

    回覆刪除
  4. evilvte 作者對本文的回應:
    http://hyperrate.com/topic-view-thread.php?tid=5284

    回覆刪除
  5. 『正面評論,缺失報告』

    首先,我已指出一些解決方法和問題,並非無的放矢。若是 Terminal 的開發者,應該曉得我所指出的問題在哪。

    其次,LXTerminal 並非真的好,最重要的 Process Sharing 也尚未完成,在這前提之下,就算再好充其量也只不過與 Sakura 相同,在多視窗時資源消耗還是很大。

    此外,libvte 本身就無法避免掉許多資源的消耗〔痴肥〕,但因編碼等問題卻是一時之選。在這架構下,如何應用『手段』讓資源壓低是各開發者的挑戰,由各家的 Source Code 實作可看出端昵,而優缺點也可從 Code 中見其真相。

    不用使用太深奧的理論,有個最簡單的方法就可證明各家 Terminal 的好壞,就是請各開 20 個 Terminal 立見高下。

    目前 LXTerminal 只是為了解決在 EeePC + LXDE 上沒有好用的 Terminal ,因此而寫出來的小 Project,但一切還只是開發階段,在 Process Sharing 還沒完成前根本只是堪用罷了。

    LXTerminal 最終目標會考慮使用 rxvt 再加入 Unicode 等支援,畢竟相較之下 rxvt 還是比 VTE 來的輕量許多,不過因目前沒太多時間而暫且擱著。

    回覆刪除
  6. 評論以及宣傳的手法不是以打擊他人來凸顯自己的。因為扣這頂帽子手法很惡劣,如果沒有真相或是其他 term 都默不坑聲,那往後 google 時都會看到這篇打壓它人凸顯自己的論點。

    如果您真心想要評論,應該是提供一個第三者可以複製的測試環境測試方法以及報告,而不是再這邊說,xxx ram 用量肥大,愚蠢,效能及差,反應速度慢芸芸。提供一個『第三者可以複製的測試環境測試方法以及報告』,遠比用情緒化的語言,或貶損人的方式來的強烈以及正確,而且你可以肯定的說明你的測試方法絕對經的起考驗嗎?測試的方法及方向不同,會產出南轅北轍的報告,『了解有關微軟與Linux的事實 Windows伺服器的整體擁有成本更低 作業系統執行效能更卓越!』這就是極佳例證。。有很多東西都是功能以及效能來衡量,小及速度快,已經不再是絕對優勢,不符合功能或需求就是零分,速度再快 RAM 再小也是零分。

    您要真心宣傳,可以強調您所著墨的功能或特性,秀出來寫出來強調出來,畫出未來性,吸引您所想要吸引的族群,讓他們來使用這個工具,回饋正向循環,這也遠比您先踢後自褒來的正確。

    可以的話真心建議您修改這篇 blog ,將貶損收起來,改用數據來左證您的想法,有數據有方法才可以比較分析,公開自己的方法,他人再可以針對問題戳插或是認同。

    lloyd huang

    回覆刪除
  7. 我猜大概是沒去詳細看 evilvte 的 code?不然,應該是不會和 sakura 聯想在一起。

    回覆刪除
  8. To lloyd huang:
    首先,文中只有指出各家缺點,並提出可改進的機制〔話說這方法也不是我想出來的,可見各大 Terminal Source Code〕。這可能造成的影響,我想也不需我再證明才是。

    此外,文中也有指出 LXTerminal 目前『相同的缺點』且『尚未改進』。更重要的是,我指出的部份缺點和『功能或需求』其實是沒有關係的。那只是一個常見用來壓低 VTE 使用資源的手段。

    還有,請別『斷章取義,頭尾亂接』。講話請講明白,不然 Google 大神也會看到您南轅北轍的『斷章取義』:

    GNOME 為何『肥』?在 LXDE 用 XFCE4 Library 為何『蠢』?沒使用 Process Sharing 的機制會如何?

    別人的本義也並不是您所說的那樣,別以偏蓋全的說他人嘴巴不乾淨,妨礙他人名譽並扣帽子是令人生氣的。

    而且,在文內並未說到 LXTerminal 比較好,只是因為覺得很多 Terminal『不是肥就是慢』,想自己重寫看看,但革命尚未成功,我看不出目前的 Code 有何偉大之處,『凸顯自己』一詞何來之有?

    To LGJ 前輩:
    小弟不才,不敢說研究透徹,但各家 Terminal 多少都將 Source Code 看過了,這應該是最基本的功課,且我不會在沒參考過多數實作的情況下,就做出評斷。相信一向謹慎的您,應該也是會在研究過數家成果後才會評斷才是。

    而 Sakura 的缺點和 Evilvte 完全是如出一徹的,縱使重寫再多東西,只要使用 VTE 的方法一樣,在多視窗時的記憶體用量就會爆增。這也是為什麼有些 Terminal 要用到 Dbus 等方法,來達成 Process Sharing 的實現。

    備註:
    我同意以數據形式來證明論點,但並不同意有人對看不懂的名詞視而不見,然後多加評論,且反而要求我給出數據。

    套句 LGJ 之前所引用的話『有些人有種奇怪的想法-- 認為一些客觀知識的總合即為智慧(林語堂.啼笑皆非)』

    回覆刪除
  9. 我暫時先把一些「雜音」去除不論。

    重點應該是態度的問題?使用一些較尖銳的用詞時,精準些、緩和些,這樣能讓多數人接受的可能性會增加才對。

    在 evilvte/lilyterm 開始的時候,我就曾提出過 vte 太肥(相對於 lightweight 的要求而言)的問題,當時 eliu 也曾提議過把 libvte 減肥。我會說和 Sakura 不一樣,指的並不是用到 vte。

    但是各個 terminal,他的設計目的並不會一樣,而且一開始實作時和過一段時間改進後也不會是一樣的面目。

    lloyd 的用意應該是很明顯,重點是在:競爭,而不是互批,甲的良藥可能卻是乙的毒藥,這種例子實在是太多了。

    以上參考。

    回覆刪除
  10. 補充一點。

    LXTerminal 的 Process Sharing 機制已經在早上被實作出來,有興趣的人可嘗試 svn 內的最新版本。

    回覆刪除
  11. 我個人還是認為,只要是用到 VTE 的
    都應該把 lightweight 字樣從廣告中拿掉
    當然,包括 evilvte 和 lxterminal 在內。
    同類程式資源消耗九成以上都在 VTE 上
    在其他地方東省西省,開一個分頁就回來了。
    所以做這樣的東西,個人認為是很沒有效益的。
    這也是為何我本來也想寫 vte-based 的
    後來取消了 (殘渣還留在 svn 內)
    不管怎麼改,到最後各家消耗的資源還是很接近
    分頁開越多越明顯,省下的部份差異小到可以忽略
    如果不能有革命性的新實做,個人覺得
    用 VTE 在那裡東省一點西省一點,其實真的很沒有意義。

    VTE 要減肥極為困難,除了拿掉多種 backend 之外
    剩下的部份很難再瘦了,否則 i18n 支援可能會不正確
    urxvt 在中文正常,但是在中東語言會怎樣沒人知道
    VTE 作者似乎是那些地區的人,所以支援完整。
    VTE 其實已經做了很多提昇 performance 的技術了
    改善還是很有限,我不覺得改寫 VTE 可以改善多少
    尤其我們並不知道在其他語系下,到底會如何。
    寫 terminal emulator,其實很難的...

    回覆刪除
  12. evilvte 把 lightweight 拿掉了:
    http://hyperrate.com/topic-view-thread.php?tid=5309

    回覆刪除
  13. 我查過了,urxvt 不支援阿拉伯文等複雜的語言
    也不能支援由右寫到左的語言,所以,不能用。
    可惜,否則 urxvt 還有支援嵌入到其他程式內

    mlterm 支援比較好,不過 code 有點可怕
    看來 VTE 還是不得已當中的選擇....

    回覆刪除
  14. 現在,大家不過都是在 VTE 之下搶空間而已,在可用性不差的前提上,搶最少的 dependency、最少的記憶體浪費、最佳的反應效能。

    唉,以作為一個良好開發環境的目標來說,好的多國語系支援是很重要的呀 :(

    對 VTE 真是又愛又恨。

    回覆刪除
  15. 我個人比較傾向繼續使用 roxterm,而不是自己重包一個 vte 殼
    另外,效能問題不可能是 roxterm 獨有
    一樣都是 VTE,不可能在繪圖部份有差別
    roxterm 唯一有問題的是 dbus 部份
    而那個可能是 debian 的 bug,因為在其他 distro 沒遇到
    我也沒發現程式碼裡面有什麼異常

    建議不要浪費太多時間在這裡...
    除非你有什麼特別好的新點子。

    另外 user-friendly 在 terminal 我個人不會太看重
    只要可接受即可,畢竟會用 terminal 的 target audience
    多半是 power user。

    以上是個人一點和你看法不同的地方...

    回覆刪除
  16. 我原本是使用 Sakura 和 Lilyterm(忘了是誰推薦了),後來改用 XFCE-terminal 為了享受那單一 process 的資源節省,後來又聽你的推薦,改用 Roxterm,最後受不了暫時改用 xterm 來開發 LXTerminal。

    經過一連串更換使用和惡夢後,我想每家 Terminal 在我的 EeePC 上都有公平的待遇和測試條件。況且我用 Terminal 最主要是使用 vim,所以,我能接受 Terminal 效能差,但再差也不能讓我在 coding 時感到痛苦。

    決大部份的 Terminal 扣掉記憶體用量問題外,都有可接受的速度,但只有 Roxterm 在我的 EeePC-900 630Hz + Compiz 上回應速度低落,且情況極為嚴重,這問題明顯的是它獨有。經檢查 sourcecode 後,發現這問題不是出在 VTE 上,而應該是他在處理 VTE 的相關問題時,所使用方法所造成的。

    因此,其他 Terminal 並沒有這效能差的問題。不可否認, Roxterm 搞定了很多 VTE 所產生出來的難搞 BUG,只是效能不彰就是了。

    回覆刪除
  17. 也許可以 bug report to roxterm's author
    roxterm 是我用過這麼多家比較之後
    覺得 bug 最少的。別人有的問題他幾乎半個都沒有
    而且 performance 問題在我的系統上都沒發生
    所以就像我們之前懷疑的,可能跟 compiz 有關

    目前有支援切換編碼的 vte-based 不多,
    除 gnome-terminal 外大概只有 rox & lily
    roxterm 又有 single instance 支援,並且有完整 config UI

    如果不是你說的問題,這真的是我目前用過最喜歡的 vte-based terminal.
    很希望你說的問題有天他能修好,你可以發 bug report 給作者嗎?

    回覆刪除
  18. Hi Fred,
    我已經為 Eee PC 打包好了大部份的 lxde 軟體,但是新版的 LXLauncher 遇到問題,就是 gtk 要求比 Eee PC 提供的高(像firefox3的case),請問有方法可以用回舊版的 gtk 嗎?
    如果能夠告訴我那一個 function 是新 gtk 獨有的也可以,我試試修改。

    回覆刪除
  19. 據我所知,新版 LXLauncher 因為用到了 cairo ,所以至少就要 GTK+ 2.8 以上版本才能跑了。

    回覆刪除
  20. 請問一下, lxlauncher-0.2要如何才能換background, 原始的source code已經把background那段comment掉了, 是有什麼問題嗎? 謝謝.

    回覆刪除

張貼留言

這個網誌中的熱門文章

有趣的邏輯問題:是誰在說謊

Web 技術中的 Session 是什麼?

淺談 USB 通訊架構之定義(一)

淺談 USB 通訊架構之定義(二)

Reverse SSH Tunnel 反向打洞實錄