Xwindow i xinit, inn, itp

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Wto, 6 Lip 1999, 11:22:02 CEST


On Thu, 24 Jun 1999, Bartosz Waszak wrote:

> Czy ktoś pracuje nad INNem, bo ten pakiet wymaga jeszcze sporo pracy
> przede wszystkim nad initem bo to z /etc/rc.d/init.d/innd i /etc/rc.d/rc.news
> uwaza za rzecz karygodna. Całość powinna być w /etc/rc.d/init.d/innd

Dokładnie to samo twierdzę. Dodatkowo kiedyś opisywałem możliwe kierunki
rozwoju tego skryptu (dalej). Niemniej sam na inn znam się jak świnia na
gwiazdach.

[..]
> Jak wygląda sprawa z X. Chodzi mi o xinity bo chyba nie przyjęto jeszcze
> żadnych ustaleń, które mają obowiązywać. Ja uważam, że pomysł z WMEXEC
> w .bashrc nie jest za dobry nie każdy używa basha, najlepiej, żeby
> za to odpowiadał plik .wm_style, standardowy windowmanager powinnien
> byc wybierany z /etc/sysconfig ale nie w taki sposób jak jest w RH6
> gdzie trzeba sie zdecydować na grupę typu GNOME, KDE, AnotherLevel (wmaker,
> afterstep itp).

Włąśnie .. co z tym jak ktoś będzie używał tcsh ?
Zauważ, że startowanie DM i WM przy logowaniu się via XDM lub zamiennik
powoduje, że to co masz w .bashrc wykona się dopiero jak po zalogowaniu
się uruchomisz xterma lub zamiennik i to wtrybie long shell.

> Ja widzę to w taki sposób:
> 
> /etc/X11/xinit/window-managers/* -- tam znajdowałyby się pliki typu:
> WindowMaker, AfterStep, KDE, GNOME i każdy z tych plików zawierałby
> definicję środowiska i uruchamiał poszczególnego winmanagera.

Spokojniej ciut. Chodzi o to, że w zasadzie mamy dwie warstwy. Jedna do
jest warstwa DM  (Desktom Mgr), a druga to WM (Window Mgr). Pierwszej może
nie być (np. goły WM), a druga jest uzupełnieniem pierwszej. Także
wymienianie WindowMakera, AfterStepa, KDE, GNOME w jednym ciągu to drobna
pomyłka.
Po za tym /etc/X11/xinit/window-managers/ to chyba też nie to. Raczej
jeżeli już to /etc/X11/window-managers/. Powyższe nie ma związku z xinit
lub jeżeli już to xinit i jego ustawienia wiążą się z WMami ale także z
tymi samymi WMami jest związane zarządzanie sesją.

> Plik xinitrc by pozostał taki jak jest teraz ale w Xclients zaszłyby
> zmiany, które powodowałyby, że nie szukałby on na własną rekę winmgrów
> (na razie są obsługiwane tylko te wmgry, które zostały przewidziane
> przez autora skryptu) tylko pobierał szukał by w $HOME/.wm_style,
> który by zawierał nazwę odpowiadającą plikowi w
> /etc/X11/xinit/window-managers/ jeśli by nie znalazł pliku o podanej
> nazwie w .wm_style (albo by nie znalazł samego pliku .wm_style)
> uruchamiał standardowy (ustawiony na przykład w
> /etc/sysconfig/desktop. Rozwiazało by to problem rejestracji
> windowmanagera przez pakiet rpm i nie były by potrzebne wymyślne
> sposoby typu skrypt RunWM do uruchamiania wmgrów. Problem stanowi
> jedynie to, że pakiety zrobione w ten sposób utrudniałyby ich
> użytkowanie w innych dystrybucjach. Byłoby to jak sądze przydatne
> także w konfiguracji xdm, wdm, gdm -- po odpowiednim spatchowaniu
> powinny zacząć obsługiwać ten sposób wybierania managerach na zdalnych
> konsolach na przykład. Po zainstalowaniu pakietu od razu wszelkie
> programy Xowe zaczeły by widzieć nowe wmgry -- Przy połączeniu z
> wmconfigiem możnaby jeszcze updateować menu.

Wydaje mi się, że pchanie w tym wypadku wszystkiego do /etc/sysconfig to
chyba ciut nie tak. To są sprawy X11 więc bardziej adekwatnym byłaby chyba
lokacja /etc/X11. Co do reszty to generalnie zgoda czyli rejestracja rzezy
typu DM i WM, a także posiadanie domyślnego DM (bąć nie) i WM dla osób
które jeszcze nie wybrały.

Tak czy inaczej pojawia się chyba jeszcze co najmniej trzecia jeśli nie
cwarta warstwa w tym wszystkim. Chodzi mianowicie o tematy. Czyli oprócz
ExecDM, ExecWM (nie style bo to jest trochę mylące) byłoby/mogłoby być
jeszcze ThemeDM, ThemeWM.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*



Więcej informacji o liście dyskusyjnej pld-devel-pl