Forum Debian Users Gang

[ppp wersja "pro" - propozycja projektu programistycznego]

Mam już powoli tego dość.

Gdy pierwszy raz uruchomiłem Linuxa z płyty CD przywitał mnie pulpit KDE. Wtedy byłem pod wrażeniem konfigurowalności, która dziś jest moim utrapieniem. W windowsie miałem wybór pomiędzy win32 classic a luną, ewentualnie można było pasek zadań przesunąć na górną krawędź pulpitu lub włączyć autoukrywanie.

Dziś muszę mieć środowisko tak dokładnie dopasowane do moich potrzeb, że chyba od 5-6 miesięcy jeszcze sobie go nie skleiłem. Robiłem najmożliwsze i najniemożliwsze mieszanki najróżniejszych desktop envów, window managerów, paneli, docków, launcherów, rootmenu, appletów, dockappów, emulatorów terminala, theme'ów, naśladowałem nextstepa, cde, mac os classic oraz x, a nawet (tfu, tfu! ale któż nie próbował... aero robi wrażenie) viśtę.

Wśród próbowanych wariantów były do tej pory: KDE, Gnome, Gnome/Beryl, Beryl/perlpanel, E16, E17, Fluxbox, Windowmaker, AfterStep, xfce4, i kilka minimalistycznych wariantów w stylu twm, wszystkie w najprzeróżniejszych konfiguracjach, nierzadko łącząc i przeplatając elementy z jednych środowisk do innych. Komponowanie tych środowisk i doprowadzanie ich do odpowiedniego stanu zajęło mi tyle czasu, że przez ostatni miesiąc napisałem jakieś 400 linijek kodu. Kiedyś tyle pisałem w jeden dzień (o ile go nie debugowałem :P). Nie mogę więcej tracić na to czasu. Muszę skompletować pulpit, który nie będzie przeszkadzał mi w pracy. (Całe szczęście że programowanie jest póki co jedynie moim hobby. Gdybym na tym zarabiał... Umarłbym z głodu.)

Nadal co chwilę coś mi nie pasuje. KDE za ciężkie. Gnome kiepsko radzi sobie z wirtualnymi pulpitami. Beryl niestabilny i mimo ostatnich ulepszeń nadal pożera pamięci niemało. E16 - prawie ideał, ale właśnie ta "niemal idealność" mnie w nim wkurza - będąc tak blisko, nie mogę jej osiągnąć. E17 ma wiele wirtualnych pulpitów zamiast jednego większego z bardziej delikatnymi granicami. Fluxbox też jakoś mnie już nie pociąga. Windowmaker jest mało intuicyjny, jeszcze mniej AfterStep (w dodatku trzeba kliknąć na pasek tytułu by wysunąć okno na pierwszy plan).

Doszedłem do wniosku, że trzeba poradzić się ludzi, którzy mają dłuższy staż w środowiskach uniksowych. Część moich wymagań na pewno spełnią istniejące WMy, i z nich trzeba będzie czerpać fragmenty kodu. Czas więc napisać własnego menedżera okien oraz towarzyszące mu tałatajstwo. Próbuję skleić coś, co wyglądałoby i działałoby następująco.

Dekorator / menedżer okien powinien dać się skonfigurować tak, aby były dostępne następujące akcje (za pomocą konfigurowalnych skrótów klawiaturowych): zamknij okno, shade, zabij proces właściciela okna, przesuwaj/zmień rozmiar okna (alt+klik). Na pasku tytułowym (najlepiej tytuł wyśrodkowany) powinny znaleźć się następujące ikonki: po lewej zamknij, shade, maksymalizuj, po prawej może być jakiś ładny obrazek :) fajnie gdyby dało się je poprzekładać. Okna powinny być dekorowalne za pomocą pixmapek (sam se je zrobię). Focus on mouse over (tradycja uniksa...). Jak najwięcej rzeczy powinno dać się robić z klawiatury.

Wirtualne pulpity muszą być, ale nie mogą być jednowymiarowe (KDE, Gnome, Fluxbox), a już nawet dwuwymiarowe mi nie starczą (E16, E17, AfterStep). Chodzi mi o takie "bezgraniczne", duże workspace'y. Dostarczany wraz z LessTif mwm ma coś takiego, że można kliknąć prawym przyciskiem na dowolnym miejscu na pagerze i znaleźć się w połowie drogi między jednym workspacem a drugim. Od strony technicznej jest to jeden duży wirtualny pulpit bez barier (i chyba mam nawet pomysł jak to ukodzić, niestety nadal nie zajarzyłem API Xów na tyle by to zaimplementować). Myślę, że gdybym miał pisać własnego wma, wyszedłbym właśnie od mwm - tylko że czekałoby mnie naprawdę sporo pracy, bo AFAIK tenże nie obsługuje nawet "focus on mouseover" - kolejnej opcji bez której nie przeżyję.

Ważna opcja to "sticky". Przyklejone okna powinny niezależnie od tego co się dzieje pozostawać "przyklejone do szkła od monitora", co jednak nie oznacza że powinny zostawać zawsze na wierzchu (cholernie mnie to denerwowało w AfterStepie). Warstw układania okien powinno być conajmniej 5 (zawsze na dole, pulpit, normalna, powyżej, sam wierzch). W E16 wkurzało mnie, że jest ich tylko 4.

Mając kod źródłowy chętnie zacząłbym przerabiać tego WMa by można było potraktować pulpit trochę jak mapkę w starcrafcie czy innych settlersach. Niedawno skonfigurowałem sobie Beryla, by obracanie kostką zaczynało się od kliknięcia lewym na pulpit. Kliknięcie na pulpicie i tak zazwyczaj nie wywołuje żadnej akcji, a okazuje się że przewijanie workspace'ów tą metodą jest *cholernie* wygodne (i, co najważniejsze, wymaga tylko jednej ręki, oraz ogólnie niewiele celowania. A to ogromny plus).

Dalej, fajnie by było gdyby każdej aplikacji można było "przyczepić karteczkę z napisem "zawsze siedź w lewym górnym rogu pulpitu", albo "gdy zbliża się do ciebie mysza - uciekaj na bok"", czyli coś w rodzaju ~/.e16/e_config--0.0.snapshots, innymi słowy, zapamiętywanie ustawień.

Konfiguracja - poprzez pliki tekstowe o możliwie najprostszej możliwej składni. Podoba mi się styl konfiguracji fluxboksa; E16, gdy już się zrozumie co jaki klucz robi, też jest dość przyjemny. Niech wszelkie pliki XML idą do piekła! Są może fajne do parsowania gdy ma się libxml, ale czytanie ich (i pisanie) to droga przez mękę. Proponuję coś w stylu "klucz:wartość" lub "klucz wartość", po jednej parze na linijkę, ewentualnie { i } aby pogrupować klucze w grupy, czyli zamiast

blah.shit:lol
blah.fuck:rotfl

napisać:

blah {
  shit:lol
  fuck:lol
}

Nie ukrywam że inspirowałem się moim wcześniejszym projektem, czyli The Net Code :D


W sumie na menedżerze okien kończy się najdłuższa moja lista problemów, ale nadal nie są rozwiązane następujące kwestie.

Uruchamianie programów. Wpisywanie nazwy każdego programu w oknie terminala jest tró i trendy i h4 i 1337, ale na dłuższą metę prosty pasek z ikonkami w stylu docka z osx lepiej daje radę. Lepszą opcją byłoby jakieś menu pulpitowe, klikalne prawym przyciskiem (fluxbox, windowmaker), z prostą składnią menu (E16, fluxbox, w sumie wszystko = zła składnia). Dobra składnia to byłoby coś w stylu:

Epiphany:epiphany -n
Terminal:~/bin/term
XKill:/usr/bin/xkill
Some menu:
  Pierwsza pozycja w menu:jakisprogram -w -a
  Druga pozycja: Menu Kontratakują!:innyprogram --jakas-opcja
  Po tej opcji konczy sie menu:~/bin/bardzofajnyskrypt.py -xdfcg -2
::
Restartuj WM::restart
Koniec pracy::exit

Dlaczego składnia np. we fluksie jest zła? Zawiera zbyt wiele artefaktów. Co innego chciałbym zrobić z typowym wpisem w menu, jak nie uruchomić z niego program? Dlaczego muszę grzebać się i wpisywać tak oczywiste rzeczy jak [exec] kilkanaście razy? Bardziej szczegółowa składnia powinna pozostać na okazję rzadszych wpisów. Składnia nie musi być śliczna. Jeżeli trzeba konfigurować coś edytując pliki tekstowe - i tak nie jest to user-firendly, więc czemu nie popchnąć dźwigni na maksa i zrobić czegoś, co w końcu będzie wygodne dla h4x0rów.

Parser wykonam sam ;] już umiem :D

Kolejna rzecz to dock/slit. Fajnie gdy przewija się jakiś wykres użycia procesora, no i jest taka mała aplikacja, docker, która pełni funkcję traya (nie trzeba implementować własnego, uff...). Problem w tym, że kawałek softu najśliczniej implementujący takiego docka - fluxbox - jest na niezbyt lubianej przeze mnie licencji typu BSD ;] tak więc muszę go napisać od zera, albo spełnić me marzenie o "standalone" docku (już kiedyś nawet zakładałem na forum DUGu temat o takowym).

Zegar - nie potrzebuję! szczęśliwi czasu nie liczą :D ale gdyby był - z datą, kalendarzem, i jakimś prostym budzikiem / przypominaczem (żadnej integracji z evolution czy inną krową). W sumie mogę ukodzić sam, tylko nie chciałbym zaczynać od zera.

Pager - jako samolotne okienko (mwm, E16), ewentualnie dokowalne (jak fbpager). Śmiesznie by było gdyby pulpit miał takie rozmiary (oczywiście w skali) jakie w danej chwili pager - powiększasz pagera, wirtualny pulpit również się powiększa.

Programy powinny być możliwie jak najprostsze, pożerać tylko tyle pamięci ile to niezbędne (poza pixmapami, które powinny być opcją), zostawiać miejsce na dodawanie ficzersów. Preferowany język to C++ tam, gdzie liczy się wydajność (algorytmy rysowania różnych bzdur czy gradientów) oraz python tam, gdzie C++ nie jest niezbędny.



To by było na tyle. Wszystkie programy, od których mógłbym wyjść, powinny być (najlepiej) na GNU GPL v2 lub nowszej, ewentualnie tylko GPLv2 lub LGPL, w miarę możliwości jak najdalej od tz. "liberalnych" licencji typu MIT/BSD (nie kocham ich za brak copyleftu) czy jakichś egzotycznych, niekompatybilnych z GPL.

Błagam o jakieś wsparcie w tej sprawie ;] głównie potrzebowałbym wskazówek - które istniejące projekty spełniają najwięcej z przedstawionych warunków, możliwie będąc dość znane, oparte na popularnych (i stabilnych!) bibliotekach, a przy tym możliwie jak najprostsze (chciałbym dość szybko zrozumieć kod i zacząć je rozszerzać zamiast tracić (znowu) czas na próby załapania API które potem okaże się niewygodne). Jeśli komuś podoba się pomysł i/lub ma podobne zboczenia co ja, a przy tym odróżnia perla od asemblera, bardzo mile by mi było zaprosić do wspólnej pracy nad kodem. Przydałyby się też jakieś linki do godziwych tutoriali (najlepiej po angielsku - naprawdę coraz gorzej czyta mi się polski...) na temat API Xów, LessTif, tworzenia "miksowanych" aplikacji w C++/Pythonie, hakowania menedżerów okien, i tym podobne. Gdy już proces dewelopienia ruszy - będę potrzebował tylu beta-testerów ilu się nada. Zasypcie moją skrzynkę majlową bugreportami! Chcę nie mieć czasu na siedzienie na slashdocie :) Nie zapominajmy też o tym, że np. KDE też zaczęło się od szalonego pomysłu rzuconego przez jednego hakera na jakiejś grupie w usenecie, kto wie, czy za parę lat nie wyjdzie z tego projektu jakieś DDE :P