Dobra, czas przejść do bardziej interesujących spraw. Najpierw: konfiguracja. Co, jak, i gdzie?

Pliki konfiguracyjne to archaiczny plaintekst ;), utrzymany w klasycznym, linuksowym duchu ~/.foo

Główny plik konfiguracyjny to .fvwm2rc

Najpierw jest poszukiwany w katalogu ~/.fvwm, potem w $FVWM_USERDIR (zmienna może przyjąć postać podobną do $PATH), potem bezpośrednio w ~, a potem ew. szuka pliku system.fvwm2rc gdzieś w głównym drzewku instalacyjnym. Bla bla bla, te szczegóły nas nie interesują.

Trzeba po prostu założyć sobie katalog "~/.fvwm", a w tym katalogu stworzyć plik ".fvwm2rc". Plik ten będzie odczytywany przy (re)starcie fvwm. OK, teraz trzeba nieco się zastanowić: Nie ma żadnej "właściwej" czy "jedynej" drogi zorganizowania sobie konfiguracji, ale z moich doświadczeń wynika jedno:

Konfiguracja takiego programu jak fvwm może się szybko rozrosnąć, więc dobrze jest sobie ją podzielić na sensowne kawałki, według "sfery kompetencji". Plik .fvwm2rc sprowadzimy do roli "startera", który po prostu po kolei wczyta resztę plików konfiguracyjnych. Nazwijmy to może "config clustering" ;)

Ja u siebie w ~/.fvwm stworzyłem dodatkowe pliki (przedstawiam w kolejności wczytywania ich przez mój fvwm):

"General"

Ustawia ogólne opcje fvwm, takie jak rozmiar biurek, domyślny font, ścieżki do tekstur, etc. Rzeczy które dotyczą fvwm w ogólności, ale nie dają się specjalnie zakwalifikować do jakiejś kategorii. W zasadzie, to lepszą nazwą by było "Misc", ale "General" dodatkowo implikuje "podstawowość" tego pliku. Hmm, czy w ogóle powinienem roztrząsać takie rzeczy, jak arbitralnie wybrane nazwy plików? ;)

"Functions"

Tutaj umieszczam swoje definicje funkcji. Funkcje to zbyt duże słowo, w fvwm "funkcją" nazywa się jakieś polecenie fvwm, a to, co ja tutaj umieszczam to tak naprawdę "complex functions" - funkcje złożone. "Funkcja złożona" to po prostu funkcja, tyle że złożona z innych poleceń.

"Bindings"

Tutaj umieszczam definicje obłożenia klawiatury i myszy.

"Theme"

A tutaj definicje "colorsets"[*] i wszystko to, co wpływa na wygląd - globalny styl, różne dekoracje dla okien czy menu. W zasadzie można by to jeszcze bardziej rozbić. Lepszą nazwą by było może "Look".
[*] - Słowo "colorsets" nie pasuje mi do języka polskiego, więc na potrzeby listu spolszczę je sobie do "kolorsetu". Wiem, głupio wygląda, ale jeszcze głupiej się czuję nie mogąc tego porządnie odmienić albo pisząc przez "c".

"Styles"

Ważny plik, bardzo ważny. Tutaj umieszczam definicje styli, o poleceniu "Style" napiszę osobny list. Tutaj znajdują się te wywołania polecenia "Style", które wpływają albo w jakiś sposób "globalnie" na okna, albo na indywidualne okienka (np. xmms), albo definiują focus/placement policies, albo inne rzeczy które w zasadzie są niezależne od używanego Theme.

"Menus"

Jak łatwo się domyślić, definicje menu. Zawiera li i tylko definicje _składu_ menu, bez wnikania w ich wygląd. Instrukcje definiujące wygląd menu są w "Theme", i częściowo w "Styles".

"Final"

pusty plik(?) Hmm, widać po coś go założyłem, i zapomniałem. Nie wiem, do czego miał służyć. E, nieważne :)

OK, więc powiedzmy że mamy już ustalony pomysł na "szkielet" konfiguracji (jak ja nie lubię takiej demagogii, "powiedzmy że mamy już ustalony". Akurat, *ja* mam ustalony. Kto inny może mieć inny, może lepszy pomysł jak zrobić cluster konfiguracji.)

Teraz trzeba zadbać, by te pojedyncze pliki z ~/.fvwm były interpretowane przy starcie. Załatwi to wstawienie do ~/.fvwm/.fvwm2rc następujących wierszy:

Read General
Read Functions
Read Bindings
Read Theme
Read Styles
Read Menus
Read Final

Jak widać bardzo proste. Polecenie "Read" przyjmuje jako argument nazwę pliku, można ją podać ze ścieżką (bez)względną. Plik zostaje wczytany a jego zawartość zinterpretowana jako polecenia fvwm. Coś jak #include. Tutaj przy okazji narzuciłem kolejność parsowania - jest ważna. Najpierw idzie "General", potem funkcje. To jest ważne - funkcje należy zdefiniować jak najwcześniej, by móc ich potem użyć w Bindings czy Menus. Potem jest Bindings, potem Theme które definiuje dekoracje na potrzeby Styles i Menus. A potem ten tajemniczy, artefaktyczny Final :)

W tym momencie można powiedzieć, że .fvwm2rc już nie będziemy zmieniać. Jedyne co będzie się zmieniać, to te inne, specjalizowane pliki.

Nie będę teraz, od razu, opisywał każdego z plików. To by mi rozwaliło odgórny plan. Powiem teraz tylko tyle, ile będzie konieczne do robienia potem jakiegoś theme.

Plik "General": ~/.fvwm/General

ImagePath /home/grzegorz/.fvwm/images:+

Na razie tylko jedna linijka. Polecenie ImagePath definiuje ścieżkę w której fvwm szuka obrazków. Składnia jest taka sama, jak $PATH, czyli katalogi oddzielane dwukropkiem. Kolejność przeszukiwania jest ważna. A ten plus na końcu oznacza po prostu poprzednią wartość ImagePath. Czyli tutaj po prostu dodaję do ImagePath katalog ~/.fvwm/images i dodatkowo ma on największy priorytet (bo jest pierwszy). W tym katalogu trzymam swoje obrazki dla fvwm. A, można używać zmiennych środowiskowych, czyli powinien przełknąć $HOME czy ${SIAKIS_PATH}.

Niedawno ImagePath wzbogaciło się o rozumienie takiej składni:

ImagePath /some/dir;.ext

Nie rozumiem tego do końca, bym musiał poeksperymentować. Chodzi o jakieś wymuszanie rozszerzenia dla wszystkich plików w danym katalogu. Naprawdę tego teraz nie rozumiem - zainteresowani sobie sięgną do manuala.

Plik "Functions" sobie na razie podarujemy.

"Bindings": ~/.fvwm/Bindings

Zdefiniujemy teraz tylko dwa skróty, jeden który otworzy nowy xterm, i jeden który otworzy FvwmConsole.

Key x   A  4    Exec exec xterm
Key F12 A MS    FvwmConsole

Polecenie "Key" definiuje przypisania klawiszy. Może wyglądać kryptycznie, ale jest w gruncie rzeczy bardzo proste jeśli się wie, o co chodzi fvwm.

Pierwszy parametr to nazwa klawisza który opisujemy. Drugi to kontekst. Tutaj jest "A" - "Any", czyli klawisz zadziała niezależnie od kontekstu. Obsługiwane konteksty to:

"R" - "root window" (czyli pulpit)
"W" - Window, czyli jakieś okno
"D" - "desktop application", czyli np. pulpit zarządzany przez kdesktop, Nautilusa czy ROX-Filera
"T" - title bar, czyli pasek tytułowy jak mawiają Francuzi
"S" - "window side", czyli ramka dookoła okna
"[", "]", "-", "_" - też ramka, tyle że tym razem specyficznie: lewa, prawa, górna, dolna
"F" - "frame", czyli narożniki okna(?!) No, nieźle... chłopaki przy nadawaniu skrótów obiektom chyba się świetnie bawili...
"<", "^", ">", "v" - poszczególne narożniki okna
"I" - ikonka zikonifikowanego okna
"0"-"9" - odpowiednie przyciski na pasku tytułowym.
"A" - "Any context"

Konteksty można ze sobą łączyć, np. "WT" oznacza "w oknie i na pasku tytułowym" (bo "okno" odnosi się tylko do tego, co "w środku".

Tutaj przypomnę linijkę, żebyście nie musieli przewijać artykułu:

Key F12 A MS FvwmConsole

Trzeci argument to modyfikatory. Rozpoznawane modyfikatory to "S" - Shift, "M" - Meta, "C" - Control, itp. Tutaj jest to "MS", czyli Meta+Shift. A więc ogólniej, kombinacja klawiszy to Meta-Shift-F12. Meta to na większości klawiatur PC "alt", jeśli ktoś nie wiedział.

Ale spójrzmy na tą drugą linijkę:

Key x   A  4    Exec exec xterm

Tutaj modyfikator to "4" (?) Nie, nie chodzi o klawisz "4", ale po prostu o to, co "xmodmap" zwraca jako Mod4. Dzięki temu można używać niestandardowych modyfikatorów, odwołując się do nich po numerkach - u mnie pod Mod4 jest lewy klawisz windowsowy.

A cała reszta wywołania to po prostu funkcja do wykonania. "FvwmConsole" jest proste - wywołaj funkcję (tak naprawdę to akurat jest moduł, ale nie zaprzątajmy sobie głowy drobiazgami) o nazwie "FvwmConsole". Przykład z xterm jest trochę bardziej zamotany. Skąd to podwójne "exec"?

Otóż, pierwsze "Exec" to funkcja fvwm. Wykonuje ona jakiś zewnętrzny program (nieblokująco, czyli fvwm nie czeka na wyjście klienta, czyli nie trzeba dodawać "–"). Drugie "exec" to już polecenie shella. Chodzi o to, że fvwm wykonuje polecenia przekazując je do /bin/sh. Jeśli doda się ten drugi "exec", to proces /bin/sh jest zastępowany przez xterm, co pozwala zaszczędzić jeden pid i odrobinkę ramu. Trzeba to dokładniej tłumaczyć? W każdym bądź razie, zadziałałoby i tak:

Key x   A  4    Exec xterm

Dobra, a teraz zbierzmy to do kupy:

Key x   A  4    Exec exec xterm

"Przypisz kombinacji Mod4+x wywołanie xterm, w dowolnym kontekście"

Key F12 A MS    FvwmConsole

"Przypisz kombinacji Meta-Shift-F12 uruchomienie FvwmConsole"

I, żeby było od A do Z:

Istniejące obłożenie można skasować podając zamiast funkcji "-". Czyli np.

Key F12 A MS -

wyczyści tę kombinację.

Oprócz polecenia "Key" istnieje także polecenie "PointerKey". Działa tak samo, tylko jego kontekst nie jest związany z fokusem a położeniem kursora. Ktoś to zrozumiał? Nie? No dobra, to dam przykład. Pod np. "F10" mamy zamknięcie okna (Key F10 W A Close). Mamy otworzone 2 xtermy (nazwijmy je xterm-1 i xterm-2), a mysz w trybie click-to-focus.

<przyklad>
Mamy aktywny xterm-1, i chcemy zamknąć xterm-2. Musimy najpierw w niego kliknąć tak, aby uzyskał fokus, a potem nacisnąć F10. Polecenie PointerKey robi inaczej - jako kontekst nie liczy się to, co ma akurat fokus, ale to, nad czym wisi kursor myszy. Czyli po (PointerKey F10 W A Close) możemy mieć fokus w xterm-1, a żeby zamknąć xterm-2 wystarczy przesunąć nad niego mysz i nacisnąć F10. To xterm-1 ciągle ma fokus, ale to xterm-2 zostanie ubity. Czegoś takiego nie ma żaden znany mi inny WM.
<przyklad>

Żeby nie było za różowo - PointerKey jest tak niestandardowy, że potrafi mu często odbić (a w zasadzie to nie jemu, a niektórym aplikacjom). You have been warned. Ale warto wiedzieć, że takie coś istnieje.

A skoro już jesteśmy w temacie - istnieje trzecie polecenie oprócz Key i PointerKey. Jest nim "Mouse". Składnia podobna do Key, tyle że nie można odstawić tej szopki z rozróżnieniem "klawisz wciśnięto/klawisz puszczono", co zresztą i tak nie jest potrzebne.

Przykład:

Mouse 3 R A Exec exec xterm

Pierwszy argument to numer klawisza myszy, drugi to kontekst (jak w "Key"), trzeci to modyfikatory, a czwarty to funkcja. Tutaj akurat oznacza to "Kliknięcie trzecim klawiszem myszy na pulpicie powoduje uruchomienie xterma". Podwójne/potrójne/(...) kliknięcia nie są obsługiwane tak prosto, do obsługi wielokrotnych kliknięć należy napisać sobie prymitywną "complex function".

(Niech mi ktoś za dwa-trzy odcinki przypomni, że mam też napisać o "IgnoreModifiers" oraz "Stroke" - to powiązany temat, ale nie chcę przesadzać z nawałem informacji)

Dobra, to by było tyle co do "Bindings"

Teraz mamy już fvwm który startuje i nic nie umie, oprócz uruchomienia xterma przez Mod4-x i FvwmConsole przez Alt-Shift-F12.

Ten list jest już chyba wystarczająco długi, na razie wystarczy...

Następnym razem w końcu (hurrej!!) pokażę jak zbudować własny, prosty theme. A może nawet i kilka od razu. Materiały przyniosę z sobą ;)

Podsumowanie:
a. Załatwiamy sobie fvwm (najlepiej z CVS, choć ostatecznie może być i "zwykła" 2.5.x), instalujemy.
b. Tworzymy sobie katalog ~/.fvwm
c. W tym katalogu tworzymy plik .fvwm2rc, o zawartości podanej w liście.
d. Oprócz tego pliku, tworzymy tam również puste pliki o nazwach "Final", "Functions", "Menus", "Styles", "Theme".
e. Tworzymy tam też pliki "Bindings" i "General" o zawartościach podanych w liście.
f. Tworzymy tam też podkatalog "images", i ew. zaczynamy w wolnym czasie rozglądać się za obrazkami które może nadadzą się na ikonki do menu (dajcie odżyć duchowi łowcy i zbieracza!)
g. Czekamy na następny odcinek, albo mówimy mi żebym przestał.

Są pytania, uwagi?