Spouštěcí skript a opět Launcher

Další poznámky z mého bastlení. Občas je před spuštěním aplikace potřeba z shellu nastavit nějaké ty proměnné prostředí. Pokud nemáte pevně dané umístění aplikace, ale znáte pouze její relativní umístění vzhledem ke spouštěcímu sktiptu, může si skript tuto cestu jednoduše odvodit. Je-li ve stejném adresáři, jako aplikace, kterou spouští, může spouštěč vypadat třeba takto:

#!/bin/sh
export UBUNTU_MENUPROXY=
cd "` dirname "$0"`"
./aplikace "$@" &

Proměnná $0, obsahuje řetězec, kterým byl skript volán, může to být například ./Desktop/adresář/aplikace. Příkaz dirname z cesty odstraní vlastní jméno skriptu, a ponechá cestu. Ať už je cesta relativní, vztahující se k aktuálnímu pracovnímu adresáři, nebo absolutní, příkazem cd "` dirname "$0"`", změníte pracovní adresář na ten, ve kterém se nachází skript, ze kterého příkaz voláte. Absolutní cestu pak můžete získat příkazem pwd.

Následující text doplňuje můj předchozí příspěvek Quicklisty - problém se zdvojováním ikon a souvisí právě s tématem spouštěcího skriptu.
Nazvu například pythonní skript aplikace a spouštěcí skript aplikace-spouštěč. Desktopový spouštěč, umístěný v Unity Launcheru, tedy odkazuje na spuštěcí skript, který dále spustí aplikaci a sám chcípne, protože jsem aplikaci nechal spustit na pozadí příkazem &. Stane se to, že si Launcher nedokáže spojit hlavní okno aplikace se skriptem, který spustil a vytvoří pro okno novou ikonu. Tak si říkám "třeba to jen nestihne.." a přidám na konec skriptu sleep 5. Hle, není úplně hloupý, zabralo to. No jo, ale jen pokud spustím aplikaci poklepáním přímo na ikonu. Při spuštění z menu quicklistu, se ikona opět vesele zdvojuje, stejně jako jsem popsal ve výše zmíněném příspěvku. Dále tedy zařazuji základní myšlénku, že když se budou spouštěč i aplikace jmenovat stejně, bude se i proces jmenovat stejně a to by mohlo něco řešit. Samozřejmě je nemůžu mít v jednom adresáři, tak vytvořím podadresář launcher, spouštěcí skript nacpu tam a doplním příkaz pro přesun do nadřazeného adresáře:

#!/bin/sh
export UBUNTU_MENUPROXY=
cd "` dirname "$0"`"
cd ..
./aplikace "$@" &

A sláva, funguje jak má, i bez sleepu. Cairo Dock ikony také nezdvojuje, ale zase registruje pouze první instanci a další vesele ignoruje. Je to zkrátka legrace :)

Zkoušel jsem předtím operovat i s parametrem StartupWMClass, kterým můžete v desktopovém spouštěči určit třídu okna, která k němu patří, ale to v mém případě řešení nepřineslo.

Jak se zbavit indikátoru pro přepínání uživatelů

Pokud v Ubuntu 11.10 s Unity nepoužíváte více uživatelských účtů a nezajímá vás ani účet pro hosta, není od věci uvolnit trochu místa v horním panelu a zakázat indikátor pro přepínání uživatelů. Zvláště na pidiobrazovce netbooku, kde se dá místo využít rozumněji. Stačí editovat jeden soubor:

sudo nano /etc/lightdm/lightdm.conf

přidat na konec řádek:

allow-guest=false

a restartovat LightDM (Ctrl+F1, přihlásit a spustit příkaz: sudo service lightdm restart), nebo rovnou celý systém.

Quicklisty - problém se zdvojováním ikon

Quicklisty v doku jsou fajn výmysl. Jak se dají tvořit popsal třeba Vojta Trefný v článku Deset tipů pro zlepšení Unity (a jeden můžete vidět i o pár řádků níž u mého předchozího článku), chybí tam však jedna podstatná věc. Alespoň v případě aktuálního Ubuntu 11.10. Nějaká moudrá hlava vymyslela, že spouštěče v home adresáři se budou chovat jinak, než ty v /usr/share/.. a tak můžete narazit na množení ikon v Unity Launcheru, pokud jen překopírujete spouštěč ze systému do home adresáře a doplníte quicklist. Spustíte aplikaci a místo aby se u ikony udělala šipečka, objeví se nová ikona kus vedle. I se šipečkou :) Ta už další okna sdružuje, ale zkrátka se distancuje od hlavního spouštěče. Pak je třeba naopak něco ubrat a oním problematickým řádkem je tento:

OnlyShowIn=GNOME;Unity;

Takže vůbec vlastně nejde o ty quicklisty :)

Další update uspávače pecí

Tak konečně, po skoro půlroce, dodávám další verzi nejskvělejšího linuxového časovače pro uspávání pecí a spouštění čehokoliv - Shutdown GTimer 0.3.6.

Novinek není moc, nejzásadnější je podpora quicklistů, která přenáší uložené předvolby do spouštěče v Launcheru Unity, ale podporuje je již celá řada dalších doků, včetně Cairo Docku. Ten je ale zatím nutno po přidání předvolby restartovat, aby se změna projevila, v Launcheru se aktualizuje ihned. Plánované cli rozhraní tedy zatím nabízí pouze jeden parametr v podobě jména předvolby, která se má po startu načíst. ...

Nautilus 3 je opravdu trochu jiný

Nedá se nic dělat, musím si zas postěžovat. Konstruktivně samozřejmě :) Nový Nautilus se chová v mnohém trochu jinak, než jeho předchůdce a rozhodně mi naboural navigaci. Pokud z nějakého důvodu použijete pro práci se soubory výchozího správce souborů GNOME, stále je efektivnější držet se klávesnice, než myši. V dvojkovém Nautilu otevřu adresář a dál se naviguji postupným psaním jména podadresáře (pokud ho znám), kam potřebuji. Nalezený adresář odentruji, tedy otevřu, a psaním pokračuji dále. Když se spletu Backspacem poslední písmeno smažu. A najednou je tu Nautilus 3 a všechno je jinak. Dobře, ne všechno, ale dost na to, aby mě to na..štvalo. Takže začnu psaním vyhledávat adresář, Enterem ho otevřu, píšu další adresář a... prdlačka. Co to kur..nik je? Vyhledávací políčko po otevření adresáře nezmizelo, jak jsem očekával, ale zůstalo i se svým obsahem a tak jsem zadáváním dalších znaků nemohl uspět. Kur..nik, říkám si, a začnu automaticky mačkat klávesu Backspace. Co to kur..nik zase je? Aha, vím, že Backspace v novém Nautilu supluje chybějící navigační ikonu "přejít k nadřazenému adresáři", ale i když jsem v textovém poli vyhledávání? Paráda, takže nemůžu mazat a když otevřu adresář, musím stisknout klávesu Escape (nebo jako retarda chvilku počkat, až to vyhledávací políčko samo zmizí), abych mohl pokračovat. Nezdá se mi to chytré. No co, vždy se dá ještě stisknout Ctrl+L a v adresním řádku nového Nautila je vše při starém. Když jsem (letmo) hledal bugy na toto téma, našel jsem pouze dřívější problémy s tím, že po otevření podadresáře nešlo už psaním vyhledávat vůbec. Nicméně i stávající chování považuji za bug, takže to případně zkusím ohlásit.

Těch drobných změn souvisejících s přechodem na GNOME 3 je víc, ventilovat bych chtěl příště přinejmenším vytváření rozšíření pro Nautilus 3 v Pythonu. Ale ještě tomu musím přijít pořádně na kloub, na stránkách gnome.org je dokumentace.. není :)

Jak zatočit s login znělkou v Ubuntu

Když restartuji Ubuntu (virtuální poměrně často) v noci, nejsem z ubuntí znělky zrovna nadšen. Tím méně mé okolí. V zásadě má hlasitější projev, než cokoliv jiného, co poslouchám a vůbec nejsem příznivcem nevyžádaných zvukových projevů počítače. Ubuntu používá přinejmenším od verze 10.10 skrytý spouštěč v podobě následujícího souboru:

Cairo Dock 2.4 místo Unity Launcheru?

Před pár dny jsem restartoval  mou domácí pec (samozřejmě nedobrovolně) a po spuštění systému nereagoval Cairo Dock na můj skript, kterým přes tlačítko myši ovládám jeho viditelnost. Zároveň se nad dokem objevila notifikace o změnách v nové verzi, mezi nimiž svítilo i DBus, což dávalo tušit, kde je problém. A změna metody ShowDock konečně přinesla to, co mi v Cairo Docku chybělo hodně dlouho - přepínat mezi stavy Show/Hide. Do verze 2.4 bylo možné dok schovat, nebo zobrazit, ale už né jednoduše stav prohodit, nebo alespoň zjistit, v jakém stavu se aktuálně nachází. Nově bere metoda místo boolean parametru integer a krom jasných 0 a 1 akceptuje i číslo 2, které změní sučasný stav na opačný. Volání metody z příkazového řádku vypadá takto:

Počítání sezení s ConsoleKit em

Řešil jsem problém, který spočívá v tom, že pokud je v systému přihlášeno více uživatelů než jeden, vyskočí při pokusu o vypnutí/restartování systému požadavkem na službu ConsoleKit (nevím na koho mocnějšího se obrátit :) okno, které chce akci autorizovat heslem superuživatele. Stačí se v některém terminálu přihlásit jako root pomocí příkazu sudo su (rozumnější sudo -i, sudo -s, nezakládají další session) a můj Shutdown GTimer nesplní svůj úkol. A vzhledem k tomu, že okno System policy po chvíli samo zmizí (alespoň v některých verzích Ubuntu), tak pokud není uživatel očima na monitoru, ani se nedozví proč. V nové verzi by měl být Shutdown GTimer schopen předem na tuto skutečnost upozornit. Tato systémová politika je funkční přinejmenším od Ubuntu 10.04 výš, verze 8.04, kde vypnutí systému ještě řeší HAL, toto omezení neplatí, alespoň pokud jste v rámci GNOME session přihlášeni v emulátoru terminálu jako root.

Služba ConsoleKit je správcem sezení (sessions) a tudíž je to zase ona která dodá informaci, kolik sezení je aktivních a tím zda se dá systém vypnout bez požehnání vyšší moci. Tedy služba dodá seznam, který je nutno spočítat. Šel jsem na to klasicky přes DBus, v příkazovém řádku je dotaz možno formulovat takto:

dbus-send --system --print-reply --dest=org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.GetSessions | grep Session | wc -l

nebo takto (vzhledem k tomu, že pro každé sezení založí ConsoleKit uzel (node), který odkazuje na metody a signály určené pro jeho správu):

dbus-send --system --print-reply --dest=org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit org.freedesktop.DBus.Introspectable.Introspect | grep Session | wc -l

Pro ConsoleKit jsou ovšem v systému pro příkazový řádek přímo příkazy, které se používají jednodušeji a výstup je již formátován, bez xml značek. Příkaz ck-list-sessions vypíše všechna sezení, včetně jejich atributů. Z výpisu lze vyfiltrovat počet sezení takto:

ck-list-sessions | grep ^Session | wc -l

ConsoleKit toho z příkazového řádku nabízí více, můžete si třeba zkontrolovat historii sezení a zjistit, že se vám díky nedostatečně zabezpečenému ssh serveru někdo několikrát naboural do systému :D Více třeba zde:

http://wiki.ubuntu.cz/ConsoleKit 

V Pythonu to samozřejmě řeším bez shellu, ale princip je stejný, navíc tam mám možnost se pověsit na signály, které jsou ConsoleKitem generovány při přidání, či odebrání sezení a na jejich základě aktualizovat stavovou informaci. Pro další verzi Shutdown GTimeru si ale vystačím s detekcí více sezení při aktivaci odpočtu v režimu Vypnutí a Restartu, málokdo asi při tomto použití ocení upozornění o změně situace v průběhu odpočtu. Ještě mě teď napadlo, že pokud spustíte Shutdown GTimer jako root, zmíněné omezení samozřejmě neplatí a tudíž musím v kódu podchytit i tuto situaci. Tak snad brzy, první nástřely jsou již v svn.

Identifikace USB disků podle typu připojení

Nedávno jsem narazil na problém jednoho uživatele, který chtěl svým dvěma nesystémovým pevným diskům změnit po startu systému přes hdparm chování, ale ty se mu pokaždé připojují jinam v /dev/sd*., a tak neví jak napsat skript, který by je přesně identifikoval. Chvíli jsem se na tím zamyslel, jak napsat nějaké univerzální řešení pro vypsání všech interních pevných disků, které zároveň nejsou systémové. Vzhledem k tomu, že na mých počítačích se nachází krom zmíněných pouze USB disky, napadlo mě tyto identifikovat podle způsobu připojení a z výpisu je vyřadit. Pak už zbývá jen identifikovat disk, na kterém běží systém. Dospěl jsem se svými znalostmi k následujícímu:

find /dev -regex /dev/sd. | while read dev; do if ! udevadm info -n $dev -q path | grep -q usb; then mount | grep -q "$dev. on / " || hdparm -S60 $dev ; fi; done

Tento příkaz nastaví diskům podle předchozí specifikace dobu pro uspání při nečinnosti na 5 minut (hdparm -S60 - 60x5 sekund=5minut). Kdyby to někdo z příkazu nepobral - find najde přípojné body všech disků, výstup se čte řádek po řádku a pro každý disk se nejprve zkontroluje ve výstupu udevadm -n zda je připojen na USB sběrnici a pokud není, další pomínka v podobě výstupu příkazu mount pošle příkaz hdparm -S60 pouze na disky, na kterých není kořenový adresář běžícího systému.

Seznam pouze USB disků pak můžete dostat takto:

find /dev -regex /dev/sd. | while read dev; do udevadm info -n $dev -q path | grep -q usb && echo $dev; done

Pokud chcete s disky cokoliv rovnou provést, nahradíte echo konkrétním příkazem, stejně jako v minulém příkladě.

Další možností by mohlo být vypsání všech připojených filesystémů USB disků i s přípojnými body, včetně parametrů:

find /dev -regex /dev/sd. | while read dev; do udevadm info -n $dev -q path | grep -q usb && mount | grep $dev; done

Sluchátka Creative EP-630 - ujdou

Špuntová sluchátka jsem dlouho odmítal kvůli jejich špuntovosti, nicméně nedávno jsem jim dal znovu šanci a nakonec i milost. Nesmíte s nimi běhat a jíst, ale jinak jsou snesitelná a ve veřejné dopravě jsou daleko účinnější, oproti klasickým peckovým sluchátkům. Zkusil jsem Creative EP-630, které jsem dostal za nějakých 150Kč, zatímco normálně se dají koupit kolem 400Kč, a nemohu říct, že by mě zklamala. Recenze se na ně dají sehnat veskrze pozitivní a musím i já přiznat, že za tu cenu (i tu běžnou) jsou velmi dobrá. Nízké kmitočty umí hrát údajně od 6Hz a faktem je, že basy trochu preferují, je jich hodně a jsou lehce rozplizlé, osobně bych uvítal méně dunivé a o něco pevnější basy, ale není to taková tragédie. Střední kmitočty a vokály podávají tyto Creativy příjemně a výšky jsou solidní, stejně jako prostor. Pokud jim předhodíte mainstreamové nahrávky, keré trpí nemocí z komprese, budete nejspíš spokojeni. V porovnání s mými domácími Senheiser HD 595, které stojí víc než desetkrát tolik, produkují EP-630 na těchto pomrvených nahrávkách opravdu příjemnější zvuk. Ty Senheisery si zkrátka moc nevymýšlí a tak se dozvíte i to, co nechcete. Dnešní nahrávky zní většinou lépe na sluchátkach, která kašlou na nějaký analytický přednes. Na kvalitních sluchátkách (reprobednách) budete z většiny nahrávek zklamáni, či spíše znechuceni (pokud nejste hluší), je to záležitost masteringu, který se soustřeďuje na hlasitost a při tom kurví dynamiku. Především u rocku, nedej bože metalu, je to peklo, všechno se to slije do nechutné agresivní sračky. Po pár minutách poslechu takových nahrávek mám pocit, že musím sluchátka servat z hlavy a hodit s nimi o zeď. Popravdě bych raději o zeď hodil těmi hovady, co takové nahrávky vyrábí. Sluchátka mohou utrpení trochu zmírnit a té agresivity ubrat a u EP-630 takový pocit mám, i ty nejhorší nahrávky podávají tak nějak snesitelněji a čitelnost jednotlivých nástrojů i vokálů je solidní. Ovšem ve chvíli, kdy jim předhodím opravdu kvalitní nahrávku, především akustické nástroje, je to slabší. Tedy v porovnání se zmiňovanými Senheisery HD 595, které hrají kvalitní nahrávku například Dire Straits (album Dire Straits), nebo Rebeccu Pidgeon (The Raven), naprosto lahodně, EP-630 dodají nepříjemnou bahenní příchuť. Zkrátka pro přenosná zařízení nevalných kvalit a nechutně komprimované nahrávky, jsou velmi dobrá a to bude jejich úkol.

P.S. Kompresí nemyslím ztrátové komprimační algoritmy MP3 a podobné, ale kompresi dynamiky, která vede k celkové vyšší hlasitosti nahrávky a je produktem nahrávacího studia, které ji vytvořilo. To že to stáhnete z CD do bezztrátového formátu FLAC, vám nepomůže, podělaný je už zdroj.

Bash - synchronizace historie mezi terminály

Máte otevřeno více terminálů a rádi byste v jednom spustili příkaz, o kterém víte, že jste ho použili v terminálu jiném. Každé sezení Bashe má ve výchozím nastavení (nejen) Ubuntu historii vlastní, která se ukládá až při jeho ukončení. Občas se hodí nějakou tu historii mezi terminály sdílet, nebo zajímavou historii uložit, protože pokud vám běží terminál třeba měsíc v kuse a pak kvůli výpadku proudu, nebo selhání grafického ovladače klekne bez uložení, můžete přijít o cenné kousky kódu (matlali jste je podle manuálu půl hodiny..), které jste z blbosti hned nearchivovali. Popíšu tedy nějaké ty možnosti, o kterých vím...

Nedomrlá menu aplikací v Unity

Vývojáři Unity mají před sebou ještě moře práce a nehledě na koncepci, musí vyřešit mnoho čistě technických záležitostí kolem funkčnosti jejich díla. Prozatím tu máme dost prostoru pro různá alternativní řešení a obcházení problémů více, či méně elegantní cestou. Pokud nám to za to stojí. Mám tu další z těch méně elegantních (i když jak se to vezme), týkající se nepěkného chování menu některých aplikací v AppMenu, tedy onom globálním menu Unity panelu.

Start raketoplánu je fakt mazec

Je to úplně mimo téma tohoto blogu, ale konckonců proč ne. Dneska přistál Atlantis naposled, přímý přenos jsem prošvihl, ale trochu jsem se porozhlédl po videiích NASA. Následující video začíná jako slaďáček, ale před polovinou se to rozjede :)

Unity Launcher - zasekává se hajzl. A jiné pakárny.

Nejsem sám, komu se Launcher v Unity každou chvíli zasekne a nechce zmizet, když má. Je to pakárna, restart Unity je k ničemu, ale všiml jsem si, že někdy se po čase zas ukázní. Po chvíli pátrání jsem zjistil, že stačí maličkost:

Když se Launcher zasekne, stačí demaximalizovat všechna maximalizovaná okna a on se 'odsekne'.

No není ten Launcher dokonalý? Zahrnuje i logickou hru! Vývojáři Ubuntu nechtějí své uživatele nechat hloupnout a tak jim do cesty staví různé překážky, jejichž překonávání je udrží v konvici. Koneckonců kdo by stál o uživatele, kteří takovou banalitu neprokouknou a nejsou schopni si napsat skript, který jim problém na jedno kliknutí vyřeší. Moc Unity nepoužívám, ale pokaždé skončím s "To je šmejd!" (trochu jsem výrok zkultivoval, nejsem přeci žádný sprosťák), zvláště po použití CCSM, což ve většině případů způsobí pád Unity, přestane mi fungovat rohový spouštěč pluginu Scale (to je fakt na prášky) a někdy i panel. Unity, a vůbec celé Ubuntu posledních pár vydání, je prolezlé podobnými chybami, které zásadně znepříjemňují používání desktopu. To máme problémy s gnome-settings-daemon, jehož kolabs může některým uživatelům vyhnat oběd zpět na stůl, tuhle nefunguje myš, tamhle ani klávesnice, to vyžene uživatelovu náladu do nebeských výšin, do Dashe, jehož koncepce je i tak těžko pochopitelná, si nedáte oblíbený prohlížeč Opera, chyba Compizu ohledně témat kurzorů se táhne léta, aby to v U10.10 opravili a v U11.04 zas vrátili do nepoužitelnosti (nehledě na to, že celý ten koncept je naprosto zhovadilý, ale to je dáno odkazy minulosti a třeba to časem vyřeší náhrada X). Je to nechutný slepenec plný kompromisů a omylů.

Unity má i některé světlé stránky (abych nebyl tak zlý), ale pár takových kokotin, které jsem zmínil, dokážou přebít nejednu radost.

Ovšem tento týden zcela s přehledem vede Gnome Shell, který mi ukázal svou verzi obrazovky smrti. Smrtící obrazovka je pohřebně černá, oznámí, že je problém, který se nepodařilo vyřešit a nabídne jediné tlačítko, které vás odhlásí ze systému. To celé ve fullscreenu, aby to víc vyděsilo - máte rozdělanou práci, podlehnete panice. Naštěstí je to jen bubák pro mouly, kterého zaženete klávesovou zkratkou pro zavření okna a v klidu si uklidíte. Já jsem bubáka pro jistotu zahnal i volbou v přihlašovací obrazovce, protože Gnome Shell celkem stoprocentně není něco, co bylo dizajnováno pro netbook s vertikálním rozlišením 600 bodů a touchpadem. Vůbec bych ho na netbooku nehodnotil jako cokoliv přínosného. Ale je hezčí než Unity. Které je použitelnější na netbooku.

Edit: Tak se ukázalo, že obrazovka smrti Gnome 3 umí být i světlá a vybafne i v Unity. Černá vyběhla v Gnome Shellu, světlá v Unity po té, co jsem změnil nastavení CCSM. Zde je důkaz:

Tak to bylo asi tak všechno, co jsem vám chtěl říct.. o swingu ;)

Unity Dash a Opera

Je už velmi dlouho známo, že Opera nekamarádí s Dashem v ubuntím Unity. Tedy ve verzi 11.04. Když se podíváte po webu, najdete bug reporty, najdete návody spokojených uživatelů Firefoxu a Chrome, ale fandům Opery nikdo nepomůže. Tedy k tomuto jsem se dobral já, možná jsem nebyl dost trpělivý. Přestal jsem hledat a na chvíli se pro změnu zamyslel, zjistil jsem totiž, že často se dá tímto způsobem ušetřit nejedna minuta :) Jak to s tím tedy vlastně je?