搜索
Table_bottom

标签云
Table_bottom

分类
Table_bottom

声明
文章若未特別註明,皆採用 知识共享许可协议 請自覺遵守
Table_bottom

鏈。。。
Table_bottom

存档
Table_bottom

匆匆过客
89068
Table_bottom

功能
Table_bottom

在GitLab Pages部署TiddlyWiki5

想將TiddlyWiki搭建在GitLab Pages已經很久。今日終於用半個小時時間完成此事,完成後覺得竟然如此簡單。然而之前始終找不到合適的教程,實在讓人糾結,故而記錄要點(並簡單介紹TiddlyWiki在該模式下的使用),以便有需要者。

簡介

TiddlyWiki是一個工作在瀏覽器中的wiki系統,其對我來說最有用的特性是:1) 支持插件(通過JS);2) 支持自定義宏 (macro)。

由於TiddlyWiki設計爲在瀏覽器中工作,所以理所當然地可以託管在GitHub Pages或GitLab Pages這類靜態網站上。雖然使用TiddlyWiki本身的單一HTML版即可,但我總覺得這樣比較臃腫,而且不好追蹤版本變更,所以更傾向於這種使用server版功能的方式(即每個tiddler是單一文件,之後轉換爲網站)。

雖然已有前人給出的搭建模板,只用fork過來即可使用,但我個人略有強迫症,想要一個“清淨”的版本。所以簡單翻閱了GitLab的相關說明頁面後,仿照其例子自己從頭構建了一個倉庫(及對應Pages)。

本文假設讀者有基本的git知識,並且已安裝tiddlywiki服務端軟件(tiddlywiki)。下面的描述均假設當前在一個空目錄/空的git倉庫中。

初始化TiddlyWiki

TiddlyWiki支持兩種模式:單一HTML頁面模式本地服務器模式。既然要使用版本控制,本地服務器模式更加適合:該模式下,每個頁面(即Tiddler)均分別以文件形式存放,更適宜版本控制。

首先,使用下面命令創建服務器模式的TiddlyWiki:

tiddlywiki wiki --init server

該命令將會創建一個名叫wiki的目錄,其中存放TiddlyWiki服務器模式配置。要在本地瀏覽或更改該wiki的內容,執行下面命令,並且打開瀏覽器訪問localhost:8080:

tiddlywiki wiki --server

對該wiki的編輯均會存放在wiki目錄下(的tiddlers目錄中)。而且配置、插件等也是以文件形式存在,可以說是無縫接合。

在該模式下,對tiddler的修改會自動保存(可能有較小延遲),而不需要(也不應該)使用“保存”按鈕——除非你的確想將你的wiki保存爲單一HTML。類似地,在GitLab Pages的頁面上的修改不會被持久化,因爲沒有後端服務程序在執行——但你可以將其當成一個安全的沙箱隨便修改。

GitLab Pages

GitLab Pages是使用GitLab的流水線機制而構建起來的特殊功能。其理念源於GitHub Pages,但實現方式有所區別,且GitLab Pages更爲靈活(至於github pages如要達到該靈活度,則必須依賴外部CI)。

在倉庫根目錄中,.gitlab-ci.yml控制GitLab流水線如何執行——當push發生時,GitLab會自動根據該文件執行CI。GitLab Pages在.gitlab-ci.yml中使用專門的pages節。在該CI執行結束後,倉庫(生成文件中)的public目錄中的文件會被發佈到GitLab Pages上(網址構成同GitHub Pages類似)。GitLab Pages完全依賴該配置文件中的描述,不需要像GitHub那樣手動打開Pages。

對於部署TiddlyWiki來說,所用的.gitlab-ci.yml內容其實很短:

image: node:latest

pages:
  stage: deploy
  script:
    - npm install -g tiddlywiki
    - tiddlywiki wiki --build
    - mv wiki/output public
  artifacts:
    paths:
      - public
  only:
    - master

原理上看,搭建的方法就是通過tiddlywiki的工具,在CI時生成頁面,然後放到public目錄。由於tiddlywiki是nodejs程序,所以在.gitlab-ci.ymlimage部分聲明使用nodejs的docker鏡像。

注意,如前文所說,我這裏將tiddlywiki的文件結構(tiddlywiki.info所在地)放在之前所描述的wiki目錄中。該代碼片段中所有引用wiki目錄的地方均是出於此處。

至此,GitLab方面也已經設置完畢。之後只要正常將該倉庫提交,並push到GitLab上即可。

長終端輸出“截屏”

今天偶然想把兩段終端輸出轉化成圖片發給別人(爲了保留顏色)。然而輸出特別長,一屏不足以顯示下來。於是想有沒有什麼方法可以讓我將終端的完整輸出截出來,畢竟手動一幅幅地裁剪太蠢了。

題目是聯想到一些Android設備上的所謂“長截屏”而取的,意義很是相似。

 

概要

由於沒有找到專門的工具,所以打算自己hack一個出來,故而事情分兩步:

  1. 將命令輸出存下來
  2. 將輸出轉化成圖片

然而在進行第二步的時候發現沒有工具可以一步到位,所以就通過HTML進行中轉。於是最終變成了三步:

  1. 將命令輸出存下來
  2. 將之前保存的輸出轉換成HTML
  3. 將HTML轉換成圖片

第一步:保存輸出

第一步可以直接重定向(加上強制彩色輸出),但我這種懶人使用了script命令。

script可以自動把我所有命令的輸出(帶提示行/prompt)都存下來,而且不用我再去一個個強制彩色輸出。而且啓動它以後會進入專門的環境,於是我可以首先在一個臨時目錄執行script,之後cd到我要執行命令的目錄,最後直接Ctrl+D以免弄亂我的正常目錄。

由於這許多優勢,我傾向於使用script,而不是採取輸出重定向的方案。

第二步:輸出轉HTML

第二步用ansi2html(AUR中有)將輸出轉換成HTML。由於是終端輸出,後面加上--bg=dark參數將背景設爲黑色會更合習慣;由於我的終端模擬器用的配色方案是Tango(我覺得比xterm-256color好看),所以還要加上--palette=tango。最終的命令就是這樣:

ansi2html --bg=dark --palette=tango < typescript > typescript.html

(理論上管道直接到ansi2html的輸入是可行的,但需要手動強制彩色輸出,畢竟多數軟件還是會探測輸出是否是終端的。)

然後可以先找你的瀏覽器看一下輸出是否符合你的預期(主要是配色方案這部分),確定後就可以進行下一步了。

第三步:HTML轉圖片

把HTML轉爲圖片的工具很多,我選了CutyCapt(依然是AUR上有)這麼一個傢伙,畢竟它滿足我目前的所有功能需求,而且用QtWebKit所以體積很小(我本來就有幾乎全套的Qt)。

對於我們的需求,其基本用法是:

CutyCapt --url=http://www.example.org/ --out=localfile.png

然而其默認的字號太小,怎麼看怎麼不舒服,所以我加了200%的縮放--zoom-factor=2。由於全都是文字,所以又加上僅縮放文字的開關--zoom-text-only=on(並沒有什麼卯月系列)。所以最終命令就成了:

CutyCapt --url=file://`pwd`/typescript.html --out=output.png --zoom-factor=2 --zoom-text-only=on

 

大功告成。(並沒有)

 

 

 

 

 

 

之後還需要手動使用圖片處理軟件(剪裁就可以了,所以gwenview足矣)將多餘部分去除。這樣就大功告成,可以拿去浪了。(其實還是有點小問題)

 

 

 

 

 

 

 

懸而未解

  • 經對比發現,輸出中的高亮並不正確,而且似乎沒有加粗。
  • powerline的輸出無法正確呈現。

 

遷移到awesome 4

前兩天隨手全局刷了一下更新,結果一不留神awesome提示我的配置文件有問題。檢查之下,發現awesome已經到了4了,所以立即意識到配置文件又改了。然而由於當時較爲忙碌,就又downgrade回了3.5,直到週末纔重新更上4並折騰配置,到今天算是初有所成。

 

由於我的配置沒有魔改,所以遷移起來還是比較簡單的。遷移前毫無疑問地,首要事情就是備份自己原來的配置文件;同時可以去看看官方說明文檔。

官方文檔分爲兩個,一個是“簡明遷移文檔”(然而官方自己都說這個只能保證你的配置能用,新功能就別想了),另一個是新的特性文檔。遷移文檔我看了一下就扔下了,然後對着新特性研究了一大半(然而還是沒看完)。

簡而言之呢,在我修改的時候,涉及到的新特性有這麼幾個:

  1. 增加了快捷鍵功能顯示界面(modekey+s)
    • 這個功能實際上是爲每個快捷鍵定義增加了一個可選參數,在其中寫上說明以及分組
    • 正確使用需要手動在快捷鍵設置的函數定義後增加這個參數,比葫蘆畫瓢即可
  2. 又重新增加了declarative layout(聲明式佈局?),同時默認配置中的頂部面板(panel)佈局改爲使用declarative layout
  3. 對象的屬性可以直接賦值(想來是有了鉤子/監聽器),而不必再使用set_xxx()
  4. screen現在是動態的(以前不是?)而且是個對象,並且遍歷所有屏幕建議使用awful.screen.connect_for_each_screen(function(s)
  5. 許多舊的api列爲deprecated,並將在日後逐步刪除
  6. 默認爲每個normal(通常?)和dialog(對話框)窗口加上標題欄

由於我之前也沒用什麼奇怪的庫(僅用了awesome-freedesktop和vicious),所以整個過程其實不難:將原來的配置文件($HOME/.config/awesome/rc.lua)備份一下,將新的配置文件/etc/xdg/awesome/rc.lua複製過去,然後開始vimdiff。

  • 一部分設置的位置變了,但內容沒變,所以保留原始狀態不變
  • menu的項目改成原來的
  • tasklist右鍵的默認動作單獨提了出來,不知道具體爲了什麼,但我將它留在原地
  • widget配置方式改成declarative的
    • 糅合panel配置,都放到專門的panels.lua中(因爲我搞了倆panel,上面一個、左邊一個)
  • 爲自己的快捷鍵增加說明
  • 調整窗口默認規則
  • 把normal窗口的默認標題欄去掉

嗯,基本就是這些了吧。剩下的那些邊邊角角的情況都是比葫蘆畫瓢即可。

 

讓我感到比較奇妙的是awesome 4增加的這倆東西:

  1. 新的widget
    • 尤其是其中的piechart和arcchart,感覺可以用來更好地顯示資源佔用了(我原來是用的vicious的文本)
  2. shape api
    • 其中有圓角的支持

然而由於我功力不夠,沒能摸索出來如何更好地使用這些東西……而直接搜索也沒搜到有用的信息(因爲太新了?)。所以接下來一段時間就要摸索這個咯(當然,有時間的話)……

Arch下XPS 13 9343的触摸板多指动作

昨天偶然意識到需要經常“後退”和“前進”,而又懶得用兩隻手去按鍵盤快捷鍵,於是想到觸摸板多指動作。

我的鼠標是羅技的M345,滾輪可以向左右傾斜而觸發後退和前進動作,而且不需要額外設置就可以用,於是感覺應該是有專門的通用事件來處理它,故而試圖尋找觸摸板觸發該事件的方法。

 

由於觸摸板雙指滾動已被佔用,而且知道自己觸摸板可以識別三指(點按),於是鎖定目標在三指滑動。然而synaptics驅動中似乎並沒有該功能,故而前去尋找,終於找到mtrack

該倉庫原本由BlueDragonX維護,後來擱置,於是p2rkw接手並且在持續維護。

 

AUR中有該包(xf86-input-mtrack-git指向的是p2rkw維護的),直接裝之(和xf86-input-synaptics衝突,pacman會提示卸載)。安裝後會自己放置配置文件到/usr/share/X11/xorg.conf.d/10-mtrack.conf,理論上應該可以自動切換觸摸板所用“驅動”(InputClass配置的Driver項)到其上。

然而我之前手動設置了觸摸板的一些配置(在/etc/X11/xorg.conf.d/下),所以還需要改該文件。不過在修改配置之前,首先要確認mtrack到底啓用了沒有,所以我就把我的配置文件中Driver項從synaptics改成了mtrack。

xf86-input-mtrack-git的安裝腳本會提示“可能需要把自己加到input組中”——貌似由於X不再以root運行,所以需要讓自己在input組中以便mtrack可以正確配置觸摸板。

由於X只有在啓動時會讀取配置文件,所以只好忍痛將所有程序都關掉然後重啓X。然而啓動後發現無論用xev怎麼測,三指的動作死活無法觸發(默認配置中,三指上下左右分別對應按鍵8、9、10、11)。於是懷疑是不是mtrack根本沒有啓用。而由於xf86-input-libinput現在被xorg-server依賴,所以沒辦法從源頭上排除(刪掉所有其他和觸摸板相關的東西,如果觸摸板還能工作,說明mtrack在處理它)。故而前去查詢X的日誌(用DM來管理的話在/var/log/Xorg.0.log,startx的話在$HOME/.local/share/xorg/Xorg.0.log),發現mtrack被載入了,然而有這麼幾句:

[     4.741] (EE) mtrack: cannot configure device
[     4.741] (EE) Couldn't init device "我的觸摸板名稱"
[     4.741] (II) UnloadModule: "mtrack"
搜索了很久,然而始終沒有找到對我有用的信息(都是macbook云云)。而網上一些人說道即使有cannot configure device這句,mtrack的配置依然會生效(然而他們及其後的人也說過只要把用戶加到input組中就不會再有這個消息了,可是我這還是有)。後來偶然重新去看日誌,發現上面還有
[     4.741] (WW) Touchpad has minimal capabilities. Some features will be unavailable.
然而也沒有什麼有效信息,只是讓我確認了我的觸摸板功能不夠全……於是繼續搜索了一大圈,最後意識到好像是閾值設置得太高了(SwipeDistance默認是700)……另外,所有有效的“Option”都會打出到日誌中。
 
最後在把閾值設置低一些(我設置的220)以後,通過xev成功監聽到了三指動作的觸發……(然而四指的無論如何都無法觸發,不知是硬件問題還是什麼)
它的配置文件中Scroll*代表雙指划動動作,Swipe*代表三指划動動作,Swipe4*代表四指划動動作;另外還有似乎並沒有通用行爲只是觸發按鍵的:Scale*代表的雙指縮放、Rotate*代表的雙指旋轉。
 
再然後就是配置它以使得符合我的需求。我需要的是左右划動觸發後退和前進,而上下暫時沒有需求。於是通過xev監聽我鼠標滾輪左右的事件,發現是按鈕8和9,而mtrack默認配置和我的需求不同,於是在配置文件中修改之。爲了保留原有的並不知道有什麼用的按鍵10和11,故而選擇交換上下和左右的動作。最終這部分是這樣的:
        Option "SwipeDistance" "220"
        Option "SwipeClickTime" "120"
        Option "SwipeSensitivity" "0"
        Option "SwipeUpButton" "10"
        Option "SwipeDownButton" "11"
        Option "SwipeLeftButton" "8"
        Option "SwipeRightButton" "9"

 

然而在改完了之後,忽然發現xf86-input-mtrack倉庫中的example有(且僅有)XPS 9333的配置文件……雖然是前代,但很多地方還是很有參考借鑑意義的……於是最終將它的配置文件抄過來稍加修改……

 

不過話說回來,example中有許多我是看不懂的(畢竟對X的配置理解不深刻),尤其是那堆重複寫Swipe和Swipe4動作的部分。哪位理解的話希望可以指點一下。

 

另外還見到了兩個其他相關軟件,然而我都沒有試:一個叫touchegg的似乎是截獲觸摸板動作然後改轉發其他動作的軟件;另一個叫easystroke的似乎是手勢識別軟件。