Ponownie xinitrc

[Tomasz Kłoczko]

On Tue, 18 Jan 2000, Bartosz Waszak wrote:

> Przyjrzałem  się  modułowi Xsession, co sądzicie o tym, aby wykorzystać
> go jako  podstawę   xinitrc.

Dla mnie jest to oczywiste jak słońce :)
Włśnie dlatego przechwiciłem to z debian-devel że było wystarczająco
elastyczne w ogólnym szkielecie jaki to tworzy.
Tylko ten szkielet trzeba jeszcze nieco przemyśleć.

> Na razie jedną poprawkę, którą należałoby
> wprowadzić   to nakazać mu  używać  /etc/X11/{window,desktop}-manager/*
> zamiast pliku  /etc/X11/window-managers  i druga to  kazać  mu pobierać
> ustawienia z /etc/profile.d. Dobrze też by było żeby plik np:
> 
> /etc/X11/window-manager/wmaker oprócz danych o pliku uruchamiającym go
> zawierał inne dane np:
> - Pełna nazwa (przyda się później przy narzędziach GUI do konfiguracji
> tego)
> - Plik uruchamiający.
> - Parametry dla wmconfig (docelowy katalog i format)
> 
> pliki /etc/X11/desktop-managers:
> - To samo co powyżej + info o tym czy sam wywołuje window managera
> (gnome-session robi to a KDE nie )
> 
> Co sądzicie o obecnej koncepcji. Sporo, rzeczy   jest do wykorzystania.
> Np: sprawdzanie   czy  dany wm  jest dostępny  na  podstawie  tego  czy
> istnieje  plik w  /etc/X11/window-manager  i sprawdzałby czy user  może
> wywoływać inne wm'y z poza listy itepe.
> 
> Pomóżcie ustalić  potrzebne informacje  do  stworzenia template wm i dm
> i można zacząć ładować do specy jeśli  nawet początkowo     jeszcze nie
> będzie działało, ale skrypt można poprawić mając pliki z danymi.

Po pierwsze zdaje się, że dałoby się wyodrębnic nie dwie co conajmniej
trzy warstwy w tej części czyli: sm, dm, wm czyli sessim manager, desktop
manager i window manager. Każdy następna zawierałaby coś co jest
podzbiorem konfiguracji poprzedniego. I tak podstawowy SM może zawierać
domyślny DM (np. SM=gnome-session może chcieć domyślnie korzystać z DM=gmc
i WM=wmaker) ale w nastpnym kroku mogłoby być to zmienione. konkretny DM
może używać domyślnego WM ale moznanby też to przysłaniać w miare
posuwania sie dalej w kolejce uruamianych rzeczy. To po pierwsze.

Po drugie powinna być możliwość rezygnacji z poszczególnych warstw i to w
kolejnosci "od czapy" czyli SM=none, ale DM=gmc, WM=afterstep (w przypadku
AS nie ma jeszcze np. supportu do GNOME wm_hint i nie ma sensu używać go
SM=gnome-session). Przy SM=DM=WM=none powinno sie IMHO uzyskać efekt
podobny do tego jaki widać po uruchomieni gołego xinit z wyświetleniem
małego okinka umożliwiającego zakończenie sesji.

Wogóle całą sprawę zależności między poszczególnymi skryptami w
/etc/X11/Xsession.d i tym jak ma to współgrać z tym jak zapisywać
konfigurację w pliku konf urzytkownika trzebaby jeszcze przemyśleć.
Osobiście byłbym za tym, żeby wszystko było w pliku standardowum
opisującym X sesję czyli w ~/.Xsession lub ~/.Xclients w postaci zmienych.
Plik ten powinien być włączany w srodowisko skryptów startowych na samym
początku i o ile nie byłoby w nich rzadnych zmiennych, a byłyby tylko
uruchamiane programy tak jak to się klasycznie robi np.

------
xterm &
exec wmamker
------

To po zakończeniu działania ostaniego programu pokazane (w tym wypadku
wmamkera) byłoby tylko jeszcze raz okienko potwierdzajace zakończenie
sesji. W sumie dałoby to coś co byłoby dość elastyczne o ile nie chciałoby
sie tego całego bagażu modularnych skryptów X sesji użyć chcąc używać to
"tak jak ociec to robili" dawałoby jednocześnie możliwość używania tego
dokładnie po swojemu bez oglądania się na to jak to można robić "po
nowemu".

Przy braku pliku ~/.Xsession lub ~/.Xclients mogłaby sie urucomić jakaś
mała aplikacyjka służąca do skompletowanie pierwszej wersji tych plików
odpytując sie o to jakiego chce sie mieć SM, DM, WM, lub inne dodatki jak
wołanie ssh-agenta co oznaczać by musiało, że /etc/X11/Xsession.d/S*setup
musiałby być sywołuwany przed error, SM, DM i WM (w zasadzie na S01).

> Jest już jakieś  ustalone rozwiązanie odnośnie  genrowania menu dla wm,
> które nie rozumieją .desktop (tzn  można to  uruchamiać    z crona albo
> podczas instalacji pakietu  zawierającego       taki  plik,     napisać
> odpowiednik   debianowego  programu generującego   Menu dla  wszystkich
> obecnych w systemie wm.

Ogólny pomysł jest nieco inny i IMHO prostrzy w konstrukcji choć nieco
bardziej skomplikowany w realizacji. Wszystkie aplikacje i WM-y opisujemy
wyłącznie plikami desktop/kdelnk przechowywanymi we wspólnym katalogu
/usr/X11R6/share/applnk (i tak teraz robią wszystkie pakiety jakie są na
ftp), a wm-y indeks aplikacji lepiej żeby czytały nie przez
wyspecjalizowane narzędzie co poprzez mała biblioteczkę, która bezie na
bierząco udostepnaiął to co jest w tym katalogu tak jak to robi kpanel z
KDE czy panel z gnome-core. Mam zaczątek takiej bibliteczki bazującej na
kodzie wyciętym z panela gnomowego ale dawno do tego niezaglądałem.

> Jak  prześlecie  swoje  opinie i ostatecznie coś  sie w końcu ustali to
> zabieram się za porządek  z tym  (to  musi być coś  genialnego na miare
> rc-inetd dla problemu z inetd'ami ;))))))
> 
> PS. Czy X'y umożliwiają  używanie różnych map  klawiatury   dla różnych
> userów  via mechanizm  xkb, żeby   móc   to  zaimplementować to   w tym
> skrypcie,  dane mógłby pobierać  z ustawień local'e  usera (czy możnaby
> zrobić plik typu ~/etc/locale,  ~/etc/lang     i tam byłyby    trzymane
> ustawienia  locale jusera,  a shelle via /etc/profile.d   itp ustawiały
> zmienne.    Ewentualnie    dodać  możliwość tworzenia userowi  własnego
> konfiga dla pam_env ->  ~/etc/environemnt,  z którego by po zalogowaniu
> pobierał zmienne  i ustawiał jeśli główny konfig na to zezwala. pam_env
> jest na prawde  bardzo dobrym narzędziem (z założenia) tylko trzeba  je
> dopracować bo może on naprawde wiele problemów ze zmiennymi rozwiązać.

Widać już, że będą musiały się pojawić skrypty
/etc/X11/Xsession/*{locale,kbssetup} i prawdopodobnie bedą one musiały być
wołane po setup i error a przed uruchomieniem wszystkich innych warstw
żeby dać możliwość ustawienia włąściwie języka itd.

Wogóle jak sam widzisz jest jeszcze sporo do przemyślenia żeby ustalić co
ma być przed czym uruchamiane, jak ma wspólgrać w tej całej "kolejce" i
ma być przechowywana konfiguracja takiej "kolejki". Jeżeli uda się całął
konfigurację opisać wyłacznie zmienymi to w ogólnym przypadku konfigurację
X sesji dałoby sie takze łątwo przenosić o ile by sie chciało do bazy
dostępnej po LDAP.

Jeżeli coś Ci się jeszcze narzuca na płat skroniowy albo komuś innemu w
tym temacie to prosiłbym o zagadywanie i pytanie się bo teraz jest
właściwa pora obgadywania takich szczegółów.

> PS2. KDE2 przechodzi na unikod jak to się ma do locali do nowych X
> 4.0.

IMHO bez unicode jaki jest planowane w KDE jest bez sensu bez unicode na
warstwie nizej czyli na tej jaką udosepnia już XF 3.9.x/4.0. Ludzie z
GNOME rozumieja to w tym wypadku i nikt nie stara sie wyskakiwać przed
orkiestrę, a rozwiazania unicodowe są szykowane dopiero w gtk+ 1.4 albo
jeszcze dalej (choć w cvs są kawałki kodu które leżakują w odpowiednich
branchach).

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*