W sumie to teraz by była pora na zaprezentowanie kilku ciekawych "magicznych" menu, ale nie jestem w nastroju do perlowej dłubaniny. Więc będzie o czym innym.

OK, do rzeczy. Dzisiaj na tapecie: pulpit. Hurrey.

No, to lecimy. Spróbuję zrobić to w takiej kolejności, w jakiej ja to robiłem (czyli poczynając od rzeczy które od razu rzucają się w oczy i drażnią).

Tło. Tapeta. Background. Wallpaper. Czyli te obrazki pod okienkami. No, po prostu ich nie ma. Goły fvwm uruchamia się z tym gustownym, X-owym wzorkiem. Czyli tapetę trzeba sobie samemu ustawić. Do gołych kolorów wystarczy xsetroot, można nim nawet ustawić te blackboksowe "kratownice". Do ustawiania normalnych tapet po różnych doświadczeniach polecam Esetroot (z pakietu Eterm). Jest bardzo szybki, nie przeinacza zbytnio kolorów, obsługuje wystarczająco szeroką paletę formatów graficznych. Wymaga Imlib albo Imlib2, w zależności od wersji.

Kursory. Kto uruchamiał gołe fvwm, ten wie o co chodzi. Kursor na pulpicie ma kształt iksa, na dekoracjach jakiejś pokracznej strzałki, itp. Nie wiem, może miłośnik twm uzna taki "X" na pulpicie za gustowny, ale ja nie. Ja chcę strzałki. ~/.fvwm/General:

CursorStyle ROOT left_ptr
CursorStyle TITLE left_ptr
CursorStyle MENU left_ptr
CursorStyle DEFAULT left_ptr

Ustawia to kursor na pasku tytułowym, pulpicie, w menusach i wszędzie tam, gdzie aplikacja nie wymusiła własnego kursora na kursor o wdzięcznej nazwie left_ptr (czyli ten najbardziej rozpowszechniony "strzałuś")

Szczegóły (konteksty itp.) są w manualu. Można odwoływać się do "standardowych" kursorów "po nazwach" z X11/cursorfont.h (kilkadziesiąt do wyboru), można przy okazji zmienić domyślne kolory kursora, można też załadować kształt kursora z pliku .xpm

Czyli trochę zabawy jest. Jedyne inne znane mi WM które na to pozwalają to Enlightenment i Sawfish (nie pamiętam jak IceWM, ale chyba nie ma takich funkcji).

Biurka/Strony. No, warto by je skonfigurować. Z biurkami nie ma sprawy, ale wymiar biurka (mierzony w stronach) warto ustawić. ~/.fvwm/General:

DesktopSize 2x2

Używam biurek 2x2, choć większość preferuje pewnie przynajmniej 3x3.

To by załatwiało rozmiar pojedynczego biurka. To, co mnie najbardziej wnerwiało to przełączanie się stron gdy tylko mysz dotknęła brzegu ekranu. Można sprawić, by do przełączenia był potrzebny większy "nacisk" ze strony użytkownika, ale ja tego w ogóle nie lubię, takiego przełączania. Za to lubię móc przenosić okna ze strony na stronę przeciągając je przez krawędź ekranu, wtedy chcę takiego przełączania. Ale nie od razu, a po pewnym "nacisku" z mojej strony, żeby mi nie przełączało strony gdy próbuję po prostu ułożyć okienko gimpa w rogu ekranu. ~/.fvwm/General:

EdgeScroll 0 0
EdgeResistance 200 10000
EdgeThickness 1

Szczegóły czemu tak, a nie inaczej są w manualu.

Teraz jeszcze ponadawać nazwy biurkom (nazwy będą pokazywane w liście okien i pagerze). ~/.fvwm/General:

DesktopName 0 Fvwm
DesktopName 1 Internet
DesktopName 2 Grafika
DesktopName 3 Devel

Skoro jesteśmy przy biurkach... przenoszenie okienek. Po pierwsze, nie chcę widzieć koordynatów okienka przy jego przenoszeniu. Za to chętnie widzę te cyferki przy zmianie rozmiaru. ~/.fvwm/General:

HideGeometryWindow Move

Po drugie, lubię to, co w Sawfishu zwało się "snap attraction". Czyli że okienka się do siebie przyciągają, albo są przyciągane do krawędzi ekranu, itp. ~/.fvwm/General:

SnapAttraction 7 All Screen

Tę opcję naprawdę warto skonsultować z manem, bo ma dużo możliwości "kustomizacji", jak np. "Czy przyciągać okna do ikonek?"

Po trzecie, domyślnie fvwm przenosi okna chyba w trybie "outline". A ja lubię widzieć całe okno, a nie tylko obwódkę. W końcu po coś mam tę kartę graficzną za 65 złoty :) Ustawiam tutaj przykładowo regułkę przenoszenia wszystkich okienek jako "opaque", chyba że zajmują więcej niż 80% ekranu, wtedy są przenoszone "outline" (z doświadczenia wiem, że tak wielkie okienka łatwiej jest przenosić jeśli są pokazywane tylko "symbolicznie". Ale można z tym polemizować). ~/.fvwm/General:

OpaqueMoveSize 80

Do tego potrzebne nam będą jakieś klawisze. Wycinek z mojego konfiga (konfigu?). ~/.fvwm/Bindings:

Mouse 2 R A
Mouse 3 R A
Mouse 4 R A
Mouse 5 R A
Mouse 6 R A
Mouse 7 R A

To zeruje wszystkie klawisze mojej myszy (odczepia od nich to głupie "default menu"). ~/.fvwm/Bindings:

Mouse 6 WTI A Move
Mouse 7 W A Resize
Mouse 1 R A Menu RootMenu
Mouse 4 T A WindowShade True
Mouse 5 T A WindowShade False

Moja mysz ma dwa dodatkowe klawisze boczne. Klawisz 6, umieszczony z lewej, służy do poruszania obiektami. Tutaj przesuwa okna i ikonki na pulpicie. Klawisz 7 zmienia rozmiar okienek (naciska się go gdziekolwiek w oknie, a potem przesuwa do jakiejś krawędzi/rogu, i wtedy zaczyna tą krawędzią/rogiem poruszać). Klawisz 1 na pulpicie wywołuje menu nazwane RootMenu, klawisze 4 i 5 (kółko, rolka, jak to kto zwie) na pasku tytułowym okna robi shade/unshade.

~/.fvwm/Bindings:

Key F12 A MS FvwmConsole
Key x A 4 Exec exec xterm
Key f A 4 Exec exec backsel
Key c WT 4 Close
Key m A 4 Menu RootMenu
Key z WT 4 Iconify
Key slash WT 4 Maximize toggle
Key s WT 4 WindowShade toggle
Key Home A C4 All [] PlaceAgain Anim
Key XF86WakeUp A N All [] PlaceAgain Anim
Key XF86PowerOff A N function RunGkrellm

Prosta lista klawiszy. Shift-Alt-F12 wywołuje FvwmConsole (coś jak Esc-x w Emacs ;)
WinLef-x to xterm,
WinLeft-f to backsel (moja zmieniarka tapet),
WinLeft-c zamyka okna (dodatkowy kontekst "T" jest konieczny, by skrót działał także dla okien "shaded" - bo one, gdy są zwinięte, nie posiadają przecież kontekstu "client window area"),
WinLeft-m wywołuje RootMenu (choć w zasadzie mógłbym to podpiąć pod klawisz WinMenu),
WinLeft-z robi ikonifikację,
WinLeft-s robi "shade/unshade",
Control-WinLeft-Home robi coś podobnego do Enlightenmentowego "cleanup desk", choć to trochę inaczej działa i zależy od placement policies. Tę samą akcję mam też podbindowaną pod klawisz WakeUp.
A pod klawisz Power mam podpiętą funkcję RunGkrellm. Ta funkcja, zdefiniowana w innym pliku, to nic innego jak wywołanie Gkrellm z paroma parametrami. Że powtarza się też w menu, to zebrałem to w funkcję - w razie czego wystarczy że będę zmieniał definicję funkcji. Myślałem nad rozbudową tego - żeby np. nie uruchamiał drugiego gkrellm gdy jeden już działa, itp. Dlatego też to robię funkcją.

~/.fvwm/Bindings:

Mouse 1 I A Iconify
Mouse 1 1 N Close
Mouse 1 2 N Maximize
Mouse 1 4 N Iconify

Key Right A 4 Scroll 100 0
Key Left A 4 Scroll -100 0
Key Up A 4 Scroll 0 -100
Key Down A 4 Scroll 0 100

To jest ciekawszy kawałek. Pierwsze polecenie pozwala odikonifikować ikonki przez kliknięcie na nich. Bo normalnie, na gołym fvwm-ie jest to niemożliwe - ikonki nie mają przypisanych żadnych akcji, i trzeba albo mieć na to zrobiony skrót klawiaturowy, albo myszowy, albo robić to poleceniami z FvwmConsole.

Następne trzy polecenia przypisują akcje 3 przyciskom na pasku tytułowym. Ja używam tylko 3 przycisków, choć pewnie niektórzy z chęcią zobaczą i więcej "buttonów". No, limit 10 sztuk pewnie każdemu wystarczy. Ja jestem zwolennikiem niedużej ilości przycisków, bo każdy przecież można obindować inaczej w zależności od tego, którym przyciskiem myszy się kliknie, czy będzie wciśnięty przy tym shift itp.

A ostatnie 4 polecenia załatwiają przełączanie po stronach. WinLeft+klawisze_kursora, myślę że dość logiczne. Przełączania po biurkach nie zrobiłem, bo nie miałem pomysłu pod co je podczepić. Może WinLeft+Shift+Kursory? Albo zamiast shifta control? Ale to bez sensu, bo strzałki sugerują jakąś zależność w przestrzeni, a biurka nie są przestrzennie poukładane. To może WinLeft+Control+cyfry?

Na koniec - ciekawostka. Strokes. Gestures. Wiadomo, to co ma Opera i Mozilla z odpowiednim pluginem. Machasz myszą jak głupi, i masz nadzieję że wymachałeś odpowiedni kształt. Kto kompilował swojego fvwm z libstroke, ten ma dostęp do

~/.fvwm/Bindings:

Stroke 654 6 R A Exec exec backsel

Przy tym zatrzymam się na dłużej.

Składnia jest prosta - najpierw "stroke" opisany tak, jak by wyglądał na klawiaturze telefonu albo odwróconej do góry nogami klawiaturze numerycznej.

(Jak ktoś chce mieć łatwiej, i przy definiowaniu gestu gapi się na klawiaturę numeryczną, to może zacząć swoją sekwencję literą "N" - fvwm odpowiednio odwróci wówczas definicję. Np. "852" to to samo, co "N258")

W moim przypadku jest to linia pozioma, z prawa na lewo. Drugi argument to klawisz myszy - tutaj 6. Potem kontekst, modyfikatory, funkcja do wykonania. Jak widać, polecenia fvwm są mniej-więcej spójne między sobą, chyba że nie są. Tutaj akurat są - Stroke ma taką samą składnię jak Key czy Mouse, tyle że na pierwszym miejscu wchodzi opis "stroku".

Mogą być problemy z kontekstami innymi niż R, okna aplikacji i dekoracje potrafią "wysysać" zdarzenia związane z ruchem myszy, wtedy można użyć StrokeFunc, która działa nieco inaczej, ale radzi sobie w 100% sytuacji. I pozwala nawet zobaczyć rysowany kształt.

Dla StrokeFunc definiuje się polecenia przy użyciu "zwykłej" Stroke, tyle że jako klawisz myszy podaje się 0, czyli np.:

Stroke N758 0 A A Exec exec xterm

Potem trzeba sobie gdzieś wstawić wywołanie StrokeFunc, np.

Mouse 3 A M StrokeFunc

Czyli: Mysz 3, dowolny kontekst, trzymając dodatkowo klawisz Meta (Alt). Trzymamy Alt+Mysz3, rysujemy, puszczamy klawisze. StrokeFunc przegląda, czy to co narysowaliśmy pasuje mu do tabeli Stroke-ów mapowanych na zerowy klawisz myszy, jeśli znajdzie coś pasującego, to to wykona. Przy dobrej implementacji przez fvwm-owca "feeling" nie różni się od Stroke, a ma dodatkowe "bajery" - mianowicie wywołanie StrokeFunc przyjmuje pewne specjalne opcje, które mogą włączyć np. rysowanie figury którą "machamy", wypisywanie na stderr kodu "wymachanej" figury (przydatne gdy wymyślamy gesty i chcemy wiedzieć, co tak naprawdę rysujemy), albo potwierdzanie przez ułamek sekundy (busy cursor) że StrokeFunc rozpoznał figurę i wykonuje polecenie (przydatne gdy ktoś na nienajszybszej maszynie robi Stroke na uruchomienie Mozilli czy OpenOffice, bo wiadomo od razu czy się udało, czy nie). I ostatnia opcja, chyba najbardziej przyjemna - można włączyć "wzbudzany" stroke, czyli np. naciskam magiczną kombinację klawiszy, macham myszą bez trzymania jakichkolwiek przycisków, gdy skończę machać naciskam spację, enter czy któryś z klawiszy. Ja to doceniłem, gdy przez jakiś czas męczyłem się na trackballu - nie byłem w stanie i trzymać przycisku, i obracać precyzyjnie kulką. Albo-albo. No, myślę że ludzie którzy nie mają koordynacji manualnej oscylującej w okolicach 270% normy też to docenią.

Gesty to fajna rzecz. Fvwm jest jedynym mi znanym WM (nie wiem, może są i inne, może są jakieś zewnętrzne aplikacje) który potrafi je wykorzystać. Biorąc pod uwagę :pałer: tego WM, można zrobić z tego środowisko które będzie reagowało dosłownie na delikatny, nieznaczny gest dłonią i robiło przeróżne rzeczy, czy to operowało na oknach, biurkach, pokazywało przeróżne menu, cokolwiek. Pierwszą barierą na którą się natrafia jest raczej wyobraźnia, a nie możliwości programu.

Ktoś może zechcieć sobie np. "poprzepisywać" gesty z Opery na fvwm. Np. Dół-Lewo zamyka okna, itp. I ma wtedy od razu "bardziej spójny" pulpit.

No, kończą mi się pomysły na ten odcinek. Moment...

Dobra, teraz polecą dwa bliźniacze tematy - focus–placement policies.

Placement policies to szare eminencje windowmanagerów. To te drobne rzeczy, na które albo nie ma się wpływu, albo są dostępne jakieś kryptyczne opcje, ale nie wiadomo co robią, albo <tu wstaw swoją wersję spiskowej teorii dziejów>

Ta drobna cecha, choć często przejdzie niezauważona, ma duży wpływ na wygodę korzystania z jakiegoś WM-a. Np. waimea ma absolutnie zrypaną placement policy, i pomimo wielu cudownych zalet z tego jednego powodu nie mogłem przy nim (przy niej?) wytrzymać dłużej niż dziesięć minut.

A, ale cóż to jest za źwierz, te "placement policies"? To polityki, schematy, metody, algorytmy układania nowych okien na pulpicie. Mówiłem, że drobnostka? Pewnie, że drobnostka. Chyba że zalezie za skórę.

W fvwm steruje się nimi za pomocą polecenia "Style". Samo polecenie Style to niewiarygodnie obszerny kombajn, 70% konfiguracji fvwm odbywa się za pomocą "Style". Placement policies (plural nie jest tu przypadkowy) to tylko część jego kompetencji. Składnia Style jest prosta:

Style foobar alpha, beta, plumkwa, wołacz, (...)

Pierwszy argument to określenie okna/okien. Polecenie Style rozpoznaje okna po hintach Name/Class/Resource. Mało ich, Sawfish miał dużo więcej. Jest to jeden z największych braków fvwm - przy całej jego wszechstronności jest to tym dziwniejsze i boleśniejsze. 4 na 5 ograniczeń fvwm wynikają z kulawego rozpoznawania okien przez Style. Pozostałe, piąte ograniczenie jest zwykle związane z dekoracjami okien. No, ale dosyć czepiania się - w końcu niektóre WM nie oferują takich funkcji w ogóle.

Więc pierwszy parametr to jakieś określenie okna. Można używać dwóch specjalnych znaczków w nazwach: * oraz ?, które mają tradycyjne znaczenie - gwiazdka to dowolny ciąg znaków, a znak zapytania do jeden dowolny znak. Użycie samej gwiazdki oznacza, oczywiście, wszystkie okna. A potem podaje się listę opcji, oddzielanych przecinkami. Opcji do Style jest mnóstwo. Naprawdę. Ja teraz się zajmę tymi, które odpowiadają za rozmieszczanie okien.

OK, dostępne opcje:

CascadePlacement

jasne. Klasyka.

TileCascadePlacement

Coś jak powyższe, tyle że najpierw próbuje okno ułożyć tak, by nie zasłaniało innego okna.

TileManualPlacement

Jak powyższe, tyle że jeśli nie można ułożyć okna "bezkolizyjnie", to włącza się tryb ManualPlacement.

MinOverlapPlacement

Układa okna tak, by jak najmiej się zakrywały. Ta abstrakcyjna wartość "jak najmniej" liczona jest w pikselach powierzchni.

MinOverlapPercentPlacement

Jak poprzednik, z tym że inaczej ustala sobie "jak najmniej". Liczy to w procentach wielkości zakrywanego okna. Różnica w praktyce jest taka, że ten model lepiej radzi sobie z zachowaniem odkrytych niewielkich okien czy ikonek. To jego zwykle używam.

MinOverlapPlacementPenalties

To nie jest tak naprawdę styl, a mechanizm konfigurujący obydwa powyższe. Przyjmuje do 6 argumentów, które określają "wagę" wykroczenia, jakim jest przykrywanie ikon, okien na niższych warstwach, obszarów "zarezerwowanych" za pomocą EWMHWorkingArea (Hint GNOME2/KDE3), czy też okien w trybie "sticky" (zwykle jakiś pager czy inny gkrellm). Te 6 wartości jest ważone między sobą, są rozważane różne warianty ułożenia okien i jest w końcu wybierany ten, który generuje najmniejsze "wykroczenie". W sumie bardzo interesujący mechanizm.

MinOverlapPercentPlacementPenalties

A to dodatkowy modyfikator dla MinOverlapPercentPlacement (bo ten poprzedni go tak czy siak obowiązuje). Ten przyjmuje tylko 4 parametry, które powodują dodatkowy "bonus" do kary za ułożenie w zależności od tego, czy okno-ofiara zostanie zakryte w 100, 95, 85 czy 75 procentach. Jeśli zbierze się do kupy te 3 ostatnie parametry, to tego WM naprawdę nie piszą ludzie. Pokażcie mi człowieka, który by wymyślił tak rozbudowany mechanizm decydowania o tym, gdzie ma się ułożyć okienko. Bardziej przesadzony by był tylko wtedy, gdyby dodatkowo analizował fengshuistyczną konstelację okienek, i ew. sprawdzał aktualne fazy księżyca i położenie planet "Byk w domu Wenus, a Księżyc w drugiej kwarcie... żaden xterm nie może zostać zakryty. W połowie tygodnia spodziewaj się dużej ilości okienek GVima, nie ufaj Pannom i gimpowi, coś przed tobą ukrywają" ;)

ManualPlacement

Okienko pojawia się jako "outline", juzer musi je gdzieś umieścić i kliknąć lewym klawiszem myszy, albo nacisnąć jakiś klawisz na klawiaturze. Ale nie Escape, bo jeśli naciśnie Escape okienko zostanie automagicznie umieszczone w lewym górnym rogu. Jeśli naciśnie drugi przycisk, to po umieszczeniu okna od razu zaczyna robić jego "resize". Jeśli włączona jest emulacja MWM, to może też wejść w ten tryb działania przez Shift+Mysz1
Może też nacisnąć trzeci klawisz myszy (czyli środkowy), wtedy okno zostanie umieszczone i otagowane stanem "PlacedByButton3". Takie okienka można później w poleceniach All, Next, Current wyróżniać równie łatwo jak te zmaksymalizowane czy "sticky". I można je np. pomijać przy "Cleanup Desk".
Trochę złożone jak na proste "ManualPlacement"? Że sparafrazuję WO "Nagle zrobiło się bardzo ef-fałwuemowsko". Nie, moment, cofam to. WO by w życiu nie powiedział "fvwm". Raczej "fvmvwfm" ;)

No, to by były wszystkie PlacementStyles.

Ja używam MinOverlapPercentPlacement, "nietuningowanego", przynajmniej jeszcze nie robiłem tuningu :)

Tutaj trzeba zaintonować, że ponieważ robi się to za pomocą polecenia Style, to każdej grupie okien można przypisać inną politykę rozmieszczania okien. To bardzo ważne, gdy np. okaże się że okienka gentoo jednak powinny się na siebie nakładać, a nie starać unikać, bo efekty mogą być wtedy nieciekawe. Na szczęście takie rzeczy są tutaj dość proste. W tej materii fvwm mógłby zostać przegoniony tylko przez Sawfisha, w którym teoretycznie można by zrobić własne mechanizmy rozmieszczania. Tyle że to mnóstwo dłubaniny w lispie, na dodatek sawfish nie był specjalnie przewidziany do przypisywania różnych polityk rozmieszczania różnym oknom. I moje doświadczenia z fvwm i sawfishem jednak pokazują, że to fvwm sobie tutaj lepiej radzi. Może dlatego, że zamiast wybieranych z combo-boksa 5 opcji można sobie to wszystko w miarę "osobiście" dokroić na miarę.

Placement już był, teraz czas na focus. Niedawno przeszedł "małą rewolucję" i trochę się rozrósł. Uwaga taka sama, jak przy placement - można przypisywać różne zachowania różnym oknom. Dobra, spis opcji dla polecenia Style:

Najpierw stare, bazowe modele:

ClickToFocus

Wiadomo.

MouseFocus/FocusFollowsMouse

Wiadomo. Mysz nad oknem - masz focus. Ruszysz mysz z okna - tracisz focus

SloppyFocus

Jak powyższy, tyle że gdy przesuniesz mysz nad "root window" to focus się nie zmieni. Nie zmieni się również, gdy przesuniesz mysz nad okno "ClickToFocus" (w końcu ono się uaktywnia tylko, gdy je klikniesz, prawda?)

Dobra, teraz "nowy model". Może on spokojnie koegzystować ze starym, ale jeśli w którymś ze styli zaczniemy używać nowych opcji, to te stare staną się już dla tego stylu, jakby to powiedzieć, nieokreślalne. Najlepiej założyć, że albo definiuje się styl "po staremu", albo "po nowemu". Tych opcji jest sporo, więc może wymienię wszystkie, a skomentuję tylko te wybrane, które nie są "samotłumaczące".

FPEnterToFocus, FPLeaveToUnfocus, FPClickToFocus, FPClickDecorToFocus, FPClickIconToFocus

Te są chyba jasne, prawda?

FPFocusByProgram

Okna mogą "wziąć" fokus gdy tego zechcą.

FPFocusByFunction

Okna mogą zyskać fokus przy użyciu funkcji Focus i FlipFocus.

FPFocusByFunctionWarpPointer

Robi "warp" kursora myszy na określone okno po użyciu funkcji Focus.

FPLenient

Według konwencji ICCCM jeśli jakaś aplikacja przy starcie ustawi sobie hint input::false, to oznacza to, że nie zechce nigdy wziąć fokusu. Można wymusić tutaj ignorowanie tego. Ale to dotyczy chyba tylko bardzo starych aplikacji - nigdy tego nie potrzebowałem.

FPFocusClickButtons

Lista przycisków które mogą realizować przekazanie fokusu czy wydobywanie okna. Nieco zdublowane, bo to samo można osiągnąć odpowiednio definiując obłożenie myszy. No, ale niech będzie. W końcu lubimy redundancję ;)

FPFocusClickModifiers

Można podać modyfikatory (Alt, Control itp.), które będą konieczne by działał ClickToFocus/Raise. Uwaga j/w.

FPPassFocusClick

Wiadomo, czy Focus-Click ma być od razu przekazywany aplikacji. Zwykle tak się _nie_ robi.

FPAllowFocusClickFunction

To samo, tyle że pozwala od razu kliknięciu aktywującemu wyzwolić funkcję, jeśli jakaś była podpięta pod ten klawisz myszy. No, po ludzku mówiąc: Mamy np. zrobione tak, że Mouse1 na pasku tytułowym pokazuje WindowOpsMenu. I teraz: Czy to menu ma się pojawić od razu przy kliknięciu aktywującym na pasku tytułowym, czy trzeba będzie kliknąć jeszcze raz?

FPIgnoreFocusClickMotion

Jeśli przy kliknięciu aktywującym będzie się poruszać myszą, to zdarzenie ruchu i kliknięcia zostanie przekazane do aplikacji, ale okno się nie uaktywni. To, czy aplikacja sobie poradzi jest tutaj nieokreślone. Manual podaje przykład z zaznaczaniem tekstu w termie bez jego (terma) aktywacji.

FPSortWindowlistByFocus

Czy wewnętrzna lista okien ma być sortowana według kolejności mapowania (pojawienia się) okien, czy też według kolejności ich aktywacji?

FPClickRaisesFocused, FPClickDecorRaisesFocused, FPClickIconRaisesFocused, ClickRaisesUnfocused, FPClickDecorRaisesUnfocused, FPClickIconRaisesUnfocused, FPPassRaiseClick, FPAllowRaiseClickFunction, FPIgnoreRaiseClickMotion

Chyba jasne w kontekście już opisanych?

FPGrabFocus, FPGrabFocusTransient

Okno dostaje fokus od razu przy zamapowaniu (no, a teraz podyktujcie ostatnie zdanie komuś przez telefon. Mi się niedawno za coś podobnego oberwało za "rozmawianie szyfrem" a w ogóle to ja "jakieś tajemnice robię", i pewnie "znowu się z kumplami zmawiam na wypad do baru")
Co do FPGrabFocus to różnie bywa, czasem jest niepotrzebny. Ale okienka "transient" to zwykle okienka które pojawiają się na chwilkę, by przyjąć jakiś tekst albo by wybrać jakąś opcję/coś potwierdzić. Zwykle warto by od razu otrzymywały fokus.

OverrideGrabFocus

Okno, które ma tę opcję nigdy nie pozwoli sobie odebrać fokusu przez pojawiające się okna z FPGrabFocus/FPGrabFocusTransient. Zwykle ustawia się przeróżnym *termom opcję OverrideGrabFocus, wtedy żadna pojawiająca się aplikacja nie psuje nam zabawy. Nie ma nic gorszego niż wpisywać jakieś polecenie, i nagle zauważa się że połowa "inputu" poszła do jakiegoś "znienacka wyskoczonego" okienka jakiejś aplikacji która do tej pory sobie spokojnie spała (albo coś robiła, nie uprzedzajmy faktów i nie obgadujmy nieobecnych ;)

FPReleaseFocus, FPReleaseFocusTransient, FPOverrideReleaseFocus

Czy to okno, gdy już zniknie, odda swój fokus poprzedniemu "właścicielowi"?

Większość "nowomodnych" opcji można negować przez prefiksowanie wykrzyknikiem, np. FPGrabFocus/!FPGrabFocus, co stwarza oczywiście szerokie pole do popisu.

Dobra, na dzisiaj to już prawie wszystko. Teraz tylko "ikonki na pulpicie", ale po łebkach. Fvwm ma wbudowaną możliwość pokazywania zikonifikowanych okienek na pulpicie, jako ikonek. shot_useless.jpg w moim nowym repozytorium pokazuje dwie takie ikonki - jeden xterm, i jedną brzydką ikonkę Dillo (ikonka brzydka, ale częściowo przezroczysta :) Ikonki przypisuje się poleceniem Style, używając opcji "Icon", np.

Style Mozilla Icon mozilla.xpm

Po zminimalizowaniu okna powinna się pojawić odpowiednia ikonka. Aby przypisać ikonkę "domyślną", coś w rodzaju "fallback-icon" która jest używana, gdy okno nie ma żadnej własnej czy zdefiniowanej, używa się gwiazdki.

Style * Icon defaulticon.png

To trochę mylące, bo w zasadzie taki zapis powinien wymusić defaulticon.png na wszystkich oknach. No, ale to fvwm. Nie musi być do końca spójnie. Jedną ikonkę na wszystkie okna można wymusić za pomocą

Style ** Icon defaulticon.png

A, zanim zapomnę - jest też polecenie DefaultIcon, które robi to, co "Style * Icon foobar.png".

Istnieje też coś takiego:

Style foobar * NoIcon

To nie tylko wyłącza ikonkę, ale okna foobar po minimalizacji w ogóle nie pojawią się na pulpicie. Będą dostępne tylko przez window list. Używa się tego często w połączeniu z modułami zarządzającymi ikonkami, ale to teraz nieważne. A, jeśli zamiast "foobar" podstawi się pojedynczą gwiazdkę, to zadziała ona na wszystkie okna, czyli jak podwójna gwiazdka z "Icon". A, żeby po prostu wyczyścić ikonkę, ale pojawiała się odpowiednia pozycja na pulpicie, robi się "Icon" bez podania pliku graficznego. Np.

Style XTerm Icon

spowoduje, że xtermy się i owszem, pojawią na pulpicie, ale tylko jako "podpisy pod ikonkami".

Układanie ikonek: Można określić obszary, w których będą układane konkretne ikonki. Np. u mnie wszystkie ikonki pojawiają się w obszarze lewo-górnym, oprócz xmms, które pojawia się w obszarze dolno-prawym, pod gkrellm. Robi się to dodając do polecenia Style opcję IconBox, która przyjmuje, jako parametr, standardowe określenie geometrii X-ów. Czyli np. 200x300+0+0 (prostokąt 200x300, licząc od piksela 0,0), albo 200x300-0-0 (200x300, licząc od prawego dolnego rogu). Można też podać geometrię w dziwacznym formacie fvwm, ale to sobie odpuszczę. Można zdefiniować kilka IconBox-ów w jednej linijce ze "Style", wtedy będą po kolei wypełniane, w kolejności definicji. Jeśli się przepełnią, albo nie został żaden w ogóle określony, to fvwm korzysta z domyślnego IconBoksa wielkiego na cały ekran. Dodatkowe opcje, których można użyć w połączeniu z IconBox to IconGrid, które definiuje siatkę do której będą "przyciągane" ikony (nb. to samo można zrobić i z oknami, ale to, że tak się wyrażę, kaszana się robi). Czyli jak gęsto te ikony da się upakować. Do tego można jeszcze dodać IconFill, które przyjmuje jako parametr 2 literki - określają one kierunek wypełniania ikonboksa. IconBox w lewym górnym rogu sensownie wypełniać jest najpierw z góry na dół, a później dodawać kolejne paski z boku. Ale jeśli taki ikonbox jest oparty o dolną krawędź ekranu, to bez sensu robi się wypełnianie od góry. A, manual chyba kłamie, bo pisze o możliwości przyjmowania także całych słów (left, bottom, etc.), ale mój fvwm akceptuje tylko pojedyncze literki. Opcja IconSize pozwala narzucić limity na wielkość ikonek. Określa się 4 liczby: najpierw wielkość minimalną, jeśli ikonka jest mniejsza to zostanie wyśrodkowana. I wielkość maksymalną, jeśli będzie większa to ją przytnie. Wartości "-1" oznaczają "default", co oznacza "no limits". Dobra, przykład:

Style xmms Icon xmms.png, IconBox 100x300-0-0, IconFill BR, IconGrid 4 4

Albo

Style * Icon default.png, IconSize 32 32 96 96

Dobra, takie głupoty jak ignorowanie ikonek "dostarczanych" przez aplikację pominę. A, oprócz "Icon" można też użyć "MiniIcon". Ta opcja przyjmuje jako parametr tylko nazwę pliku z piksmapą, i nie ma nic wspólnego z "Icon". Definiuje "mini ikonkę", która może być używana np. przez listę okien, kilka modułów (np. FvwmPager), albo pokazywana na guziku na pasku tytułowym okna. Np.

Style XTerm Icon term.png, MiniIcon term_tiny.png

MiniIcons powinny być nie większe niż 16x16 pikseli. Tzn. nie ma jakiegoś limitu, w liście okien np. ładnie wyglądają i ikonki pełnych rozmiarów, ale już w przycisk na dekoracji okna, albo w miniaturkę okienka w pagerze trudno jest wepchnąć choćby ikonkę 20x20.

OK, już wystarczy na dzisiaj. W zasadzie to te ważniejsze fvwm-owskie rzeczy już były. Teraz zostały tylko własnoręcznie wystrugane funkcje i jakieś różne funkcje "misc".