Portál AbcLinuxu, 30. dubna 2025 09:13
Moc jsem o tom nepsal, ale nedávno jsem začal experimentovat s prostředím Enlightenment. Přineslo mi to pár zajímavých okamžiků.
Na úvod musím říct, že mi ta věc od začátku moc dobře nefungovala. Narazil jsem na pár problémů, které už třeba ani nejsem schopný specifikovat. Nakonec to dopadlo tak, že používám verzi z Gitu a čas od času si vyberu nějaký problém, který mi trochu víc vadí, a snažím se ho pořádně nareportovat, případně i vyřešit.
Z druhé strany nemůžu říct, že bych našel nějaký zásadní technický či uživatelský důvod, proč
Enlightenment používat. Přesto se po nějakých těch týdnech testování usadilo na mém laptopu
a denně ho používám. Pokud existuje něco, co bych mohl považovat za důvod Enlightenment používat,
tak jsou to lidi na #e
.
Bývá zajímavé uvážit svá rozhodnutí v kontextu ostatních možností. Projekt KDE mě přestal zajímat v době, kdy v aplikacích docházelo ke změnám, po kterých mi přestávaly vyhovovat, což bylo někdy během životního cyklu KDE 3, navíc nejsem zrovna nadšený z C++, kdybych se někdy chtěl na vývoji podílet. Gnome jsem vzdal během životního cyklu Gnome 3, kdy jsem příliš dlouho čekal, až budu mít pocit, že se nová řada začíná stabilizovat. Nějakou dobu jsem používal i Openbox a později Awesome a uvažoval jsem, že vyzkouším i další minimalistické projekty, ale nějak mě to přestalo bavit.
Tedy zatím u Enlightenment zůstávám a zřejmě by musel přijít nějaký důvod, proč změnit, ať už ze strany Enlightenment, nebo ze strany dostupných alternativ.
V době, kdy jsem používal KDE byly hlavním motivem aplikace, nikoli samotné prostředí. To stejné jsem se snažil uplatňovat i v Gnome a používal jsem Gnome aplikace. Množství chyb a časté změny mě ovšem vždycky přivedly k tomu, že jsem maximum práce dělal v terminálu. Jednu dobu jsem dokonce v terminálu používal i mail, ale to mě prozatím přešlo. Nakonec jsem zjistil, že používám jen minimum pečlivě vybraných aplikací mimo terminál.
Jako terminál momentálně používám Terminology a stále mám dojem, že třeba za terminálem z Gnome
krutě zaostává, minimálně v tom, jak mně vyhovuje terminál používat. Zrovna při pokusu zkopírovat
tento zápisek z terminálu do formuláře na Abclinuxu vynechal prázdné řádky v té části, při jejímž
označování došlo k rolování, takže radši použiju xsel
. Ale na druhou stranu to není
tak krutě, aby mě to během těch pár měsíců donutilo přejít zpět, takže se ho zatím držím.
Pokud jde o samotnou konfiguraci Enlightenment a souvisejícího software, tak ta je značně podobná konfiguraci Gnome nebo registrům Windows (se zdůrazněním toho, že se bavíme pouze o uživatelské konfigurační databázi, nikoli systémové). Výchozí konfiguraci nevnímám jako nějaký zázrak. Uživatelem zvolená konfigurace se nezapisuje samostatně, ale vepisuje se do binární konfigurační databáze, člověk tedy nemá přehled o tom, které volby si nastavil on sám a které jsou výchozí.
Nemám tenhle způsob konfigurace rád, radši bych si s sebou nosil konfigurační soubor, který by měnil jen těch pár voleb, které si chci nastavovat ručně, abych mohl po aktualizaci setrvat ve stavu, kdy mám všechno ostatní z defaultu.
Podstatně horší je ovšem absence dokumentace a to nejlépe dostupné přímo v GUI konfiguračních nástrojích. Většina voleb je nazvaná tak, že nemám nejmenší tušení, co znamenají, a rád bych si při nastavování přečetl nějaký popis toho, co daná volba dělá.
Enlightenment mi občas zatuhne nebo se začne chovat divně. Když na to dojde, prvně zkouším
magickou zkratku Ctrl+Alt+End
a pak z virtuálního terminálu za uživatele
killall -9 enlightenment
. To druhé mi často shazovalo celou session, ale
v poslední době (připomínám, že používám git master) už se session udrží a nová instance
window manageru si zpravidla se vším lépe či hůře poradí.
V poslední době mám problémy při startu Enlightenment při připojeném externím monitoru, dávám tedy laptop do docku až po spuštění, ale tady spíše podezřívám X11 v Gentoo stable než Enlightenment.
Jedna z prvních věcí, co mě trkla na Enlightenment byla, že mi systray fungoval špatně, nepřizpůsoboval správně velikost a dělal další pochybné věci. Opravoval jsem to již zmíněnou magickou zkratkou na otočení window manageru. Vývojáři mi řekli, že se to nebude opravovat, protože klasický systray založený na Xembed je špatně. Mimochodem jsem podporu pro tento mechanismus musel už tehdy ručně zapnout.
Vadilo mi, že je v Enlightenment špatná implementace Xembed systray, což se nedávno v masteru vyřešilo a tento protokol už není podporován vůbec. Tím mi ze systray zmizelo všechno. Na druhou stranu oceňuju, že se vývojáři chytili za hlavu a odstranili vlastnost, kterou stejně už nikdy nikdo nebude opravovat. Od té doby v případě potřeby spouštím stalonetray, samostatnou implementaci Xembed systray. Taky nefunguje kdovíjak zázračně, ale používat se to dá.
Když jsem do appletu z projektu network-manager-applet začleňoval podporu libappindicator, knihovny, která umí jak Xembed systray, tak i systray pomocí dbusového API (appindicator systray), narazil jsem na to, že appindicator není všude podporován stejně.
Například ikonky v menu lze z aplikace zasílat pomocí jména nebo pixmapy (nikoli však obojího zároveň, podle informací od Dana Williamse a dalších). Enlightenment systray zvládá zobrazit jedině ikonku zadanou jménem, ale nm-applet v nabídce wifi připojení skládá pixmapu z ukazatele signálu a ukazatele zabezpečení. Jiné implementace ty pixmapy zobrazit zvládají.
Tiskni
Sdílej:
Tak vidíš túto fjučúru si v blogu ani nezmienil.1) Nejen diskuzí živ je ábíčkář. Přečti si ten blog. O stabilitě se v něm píše, stejně jako o tom, že používám Enlightenment z Gitu. 2) Výše jsem psal jsem o „experimentálním systému“, nikoli o Enlightenment.
S IceWM by sa ti to ľahko môhlo staťJasně. Když budu místo Enlightenment používat IceWM, překompiluju si kernel nebo větší množství jiných věcí, a budu potřebovat restartovat, tak budu podle tebe dělat co? Zaříkávat duchy a běhat nahý kolem ohně?
že appindicator závisí na glib2 je zcela mylnáAsi máš pravdu. Sice v Archu jo, ale koukám, že zatím jde dbus zkompilovat bez systemd, kterej na tom závisí.
Pokud se DE snaží o nějakou konzistenci, je xembed hodně na škodu. Každá aplikace si řeší svou systray ikonku po svém, chová se jinak… Nechat DE ať se o to stará po svém je podle mě mnohem lepší.Nevím, jak to přesně myslíš, ale třeba ten nm-applet jakýkoli pokus řešit ikonky ze strany systray akorát ten applet degraduje, což je vidět i na té současné implementaci přes libappindicator bez pixmap.
Myslel jsem to tak, že xembed je embedované miniokno v trayi.V tomto případě. Často narážím na to, že vývojáři netuší, že to je jenom použití Xembed, nikoli jeho podstata.
Bohužel v tomto případě je zdá se implementace ne zrovna povedená :/Obávám se, že je v tomto případě nepovedený i samotný protokol.
Pokud je někdo neiplementuje, je to blbost pouze a jen jeho.Což ovšem nemá vliv na to, zda je standard dobrý nebo špatný.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.