Budoucnost šetřiče obrazovky v projektech KDE

Martin Gräßlin, vývojář KWinu, zdůvodňuje plány na odstranění šetřiče obrazovky, který od nahrazení CRT monitorů LCD nechrání obrazovku před poškozením, ale přitom zbytečně spotřebovává energii a v principu neplní bezpečnostní funkci uzamykání obrazovky. O zamykání obrazovky by se měl správně starat kompozitor. Změny, pokud se vývojáři na jejich realizaci shodnou, by se měly dotknout až vydání KDE SC 4.8.

10.4.2011 20:20 | Fluttershy, yay! | Zajímavý článek

Komentáře

[chrono]

Šetrič obrazovky zbytočne spotrebováva energiu aj pri CRT monitoroch, ale to určite Martin Gräßlin vie. Problém je ale asi v tom, že pre zmenu, ktorú plánuje, nedokáže vymyslieť žiadne rozumné zdôvodnenie (ale pozitívne je, že zatiaľ do KWin neplánujú pridať emailového klienta, či niečo podobne dôležité). :)

[Fluttershy, yay!]

Pardon, to jsem já špatně formuloval.

They were required to prevent serious hardware damage on CRT screens. This is even implied by the name: a screensaver saves the screen from damage. Now we live in the second decade of the 21st century and the world has changed. I can’t remember when I last saw a CRT computer screen, they have been completely replaced by LCD screens. LCD screens on the other hand don’t show the danger of burn-ins. They don’t need to be “saved”. (...) Especially in the current time it is extremly important to save power.

Jinak zdůvodnění je jasné (vedle úspory energie, která se spotřebuje pro výpočty toho, co se má zobrazovat):

We have seen that parts of the screen can be leaked which means there can be privacy issues. Even worse is the situation with OpenGL screensavers. They sometimes use ARGB windows and don’t clear the screen (this used to work fine in the pre-compositing era), all areas not repainted by the screensaver are leaked. In case you have a buggy driver it is even likely that either the screensaver or the compositor will not survive that both are used. According to our bug reports this is a common problem. Now driver bugs should be fixed but reality shows: it is not happening.

[JoHnY2]

Nemas pravdu. Screensaver je puvodne o zivotnosti CRT monitoru bez power managementu, se spotrebou nema  nic spolecnyho. Je to jedoduse dany tim, ze CRT ukazujici prevazne cernou skoro neopotrebovava obrazovku.

[chrono]

Pôvodne možno áno, ale CRT monitory bez správy napájania sa nevyrábajú už dosť dlho (teda presnejšie, niekde sa možno ešte vyrábajú, ale dosť pochybujem, že sa ti taký podarí niekde kúpiť).

[Nicky726]

No a o tom celý ten článek je. Dnes používané spořiče obrazovek vznikly kdysi dávno a od té doby se svět natolik změnil, že v něm pozbyly většinu smyslu své existence.

[marvn]

a neni problem spis v tom, ze si chces do Martina Gr????lina kopnout, ale v tomhle pripade nevis jak? (ale pozit??vne je, ??e zatia?? si ho nenarknul z planu pridat do KWin IM klienta) :smajlik:

[chrono]

Píšeš z KDE? :)

[stativ]

Ne, evidentně se něco rozbilo na abíčku, tenhle post byl ještě před chvílí v pořádku. A není jediný.

[stativ]

To „ne“ se nevztahovalo k otázce, ale bylo to takové uvození, něco jako ehm.

[Tomáš Bžatek]

gnome-screensaver-3.0.0 taky nema moznost menit temata a zobrazuje se vzdy jen cernota.

[pic]

to není bug, ale ...

[AsciiWolf]

[Tutor]

...to je gnome

[Fluttershy, yay!]

Bohaté možnosti nastavení GNOME 3. ^___^

Teda Plasma Desktop na tom u mě není o nic lépe, ale to je jen tím, že nemám kdeartwork.

[Fluttershy, yay!]

Jinak toho času jsem používal (v KDE 3.5) jako šetřič docela hezké hodiny, to bylo i užitečné.

[D.A.Tiger]

+1 taky jsem je míval nastaveny. To mi připomíná, že v dobách DOSu se dal sehnat prográmek, který zobrazoval na monitoru tuším že Rollexky :) No pokud člověk skousl, že to musel spustit ručně...

[Mandarinka]

Oni hlavně ty "šetřiče" nemají žádnou šetřící funkci. Naopak, obyčejně nejenže brání procesoru přejít do úsporných/vypnutých stavů, navíc ho ještě kolikrát hodně vytěžují, takže mu ani nedovolí spadnout na ekonomickou frekvenci - spotřeba může být klidně vyžší než při běžné práci, nedjebože když je ještě ten šetřič 3d a běží při něm navíc grafika...

Za účelem šetření je zde přepnutí monmitoru do standby režimu!

[Tutor]

"šetřiče" skutečně šetřící funkci mají. Jen se vůbec netýká elektrické energie. Proč tu všichni papouškujete blbosti?

[kavol]

"šetřiče" skutečně šetřící funkci mají. Jen se vůbec netýká elektrické energie.

ehm, co si pamatuju, tak vzruchy v mozku se přenáší právě elektricky

(aneb funkce "šetřiče" je dnes často relaxační, má význam pro uživatele ... ale už si zvykám, že v KDE se na uživatele sere - i když na druhou stranu mě překvapuje, že se ruší grafická píčovinka, ty většinou přibejvaj ...)

[D.A.Tiger]

Jj - pokud zobrazují černou obrazovku

[trekker.dk]

obyčejně nejenže brání procesoru přejít do úsporných...

To není pravda, rozhodně ne obecně. Šetřič - teda alespoň v KDE 3.5 běží s nice 19, takže se procesor klidně zpomalí.

[Semo]

Nemusi, zalezi na tom, ako je nastavene ignore_nice v ondemand alebo conservative governore.

[trekker.dk]

Což to vim, ale mám zato, že je to ve výchozím nastavení zapnuté.

[michich]

Více než zpomalení (P-stavy) je pro spotřebu významnější setrvání v klidovém režimu (C-stavy).

[trekker.dk]

To nepopírám, ale moje tvrzení se tím nijak nemění

[Tomáš Bžatek]

Ja nevim, ale nejakych par Wattu navic me nezajima, zvlast kdyz ten setric bezi jen par minut denne. Chapu, ze notebookari to asi budou resit a take ti, kteri maji grafiku-vysavac, zvysujici spotrebu o 100-200 W v 3D rezimu

A neustale prepinani do standby modu je nejlepsi cesta ke koupi noveho monitoru, ze ty jsi agent vyrobcu monitoru?

[Bilbo]

Např. u xlocku lze dát parametr -delay který určuje jak často se updatuje obraz na obrazovce. Když se dá na půl sekundy a zvolí nějaký nenáročný mód (např. swarm) tak zatížení procesoru je naprosto minimální.

U notebooku to má pak oproti blank tu výhodu, že když člověk otevře víko, tak hned pozná jestli notebook naběhl, nebo jestli se nepovedlo ho probrat ze standby (což se čas od času stává).

[pushkin]

Neee, já mám své ASCII rybičky rád

[Pavel Stárek]

Nu což, tak použij xscreensaver. Ale nevím, zdali v něm jsou ASCII rybičky.

[Dragon Jake]

to já taky :) hlavně ponorku

[pard]

ja zraloka ...

[anonymouse]

a já kulervoucí a baterkuždímající electric sheep. chudák dick, teď už na něj každý zapomene.

[arch_way]

Budoucnost šetřiče obrazovky v pr... deli?

[ikarr]

Dvakrát v životě jsem viděl něco natvrdo vypáleného do stínítka monitoru. Poprvé před dvaceti lety přihlašovací obrazovku do monitoru u SGI stanice, podruhé letos do LCD monitoru AOC rámečky a pole ovládácího panelu přístroje, řízeného linuxem. Sceeensaver to po několika dnech provozu poněkud zlepšil, ale stejně tam je ten statický obrázek vidět jako duch pořád. Tak nám zase nějaký zelenáč tvrdí, že je něco nemoderního a je to třeba zrušit. Už mne ti arogantní cucáci, co ví o všem kulové ale zato mají pořádné ego, docela štvou.

[David Heidelberg]

samozřejmě, že DPMS vypne obrazovku, místo spořiče, což její životnost jistě prodlouží víc, než blikající screensaver (který prakticky v dnešní době moc obrazovku nešetří)

[Zopper]

Ach jo... Šetřič nemá prodlužovat životnost, šetřič má bránit vypálení statického obrazu - proto ty animace a barvy. A vypnutí vám nepomůže, když jediné, co se tam po zapnutí zase objeví, je ten stejný obraz.

[ikarr]

Přesně tak.

V uvedeném případě LCD samozřejmě obsluha nestojí o to, aby jí nějaké DPMS vypínalo obrazovku. A poblikávající kostičky přes noc, kdy u toho nikdo není výrazně zlepší vypálený obraz. Dokonce existují i paterny, které při přehrávání screensaverem mohou probudit některé zdechlé pixely na LCD.

jistou logiku má nepoužívání screensaveru na laptopech, tam to asi fakt pouze vybíjí baterku, ale na desktopech?

[Filip Jirsák]

Pokud LCD potřebuje mít nějaký režim pro zotavení z vypáleného obrazu, mělo by takovou funkci implementovat samo LCD. Může to implementovat mnohem lépe, než nějaký šetřič obrazovky (cíleným překlápěním jednotlivých subpixelů – navíc u toho nemusí být zapnuté podsvícení).

[Oskar]

Příklad je vidět třeba na LCD monitorech v pražském Metru: první a třetí verze screensaveru...

[xkucf03]

O zamykání obrazovky by se měl správně starat kompozitor.

A když spadne KWin, tak se obrazovka odemkne? IMHO by to mělo fungovat takhle:

1. Kdo chce, aby se mu na obrazovce po dobu nečinnosti promítaly nějaké obrazce, ať se mu promítají – i kdyby to měla být 3D grafika nebo HD video – je to jeho počítač a jeho účet za elektřinu.
2. Zamykání by se mělo řešit nějak systémově (možná už to tak je…). Obrazovka by se zamkla (podobně nedobytně, jako když na tty1 bliká login prompt) a spořič by mohl do nějaké „roury“ vysílat, co se má na obrazovce dít – kdyby spořič spadl, zůstal by tam prostě ten poslední obraz nebo prázdno, ale obrazovka by byla pořád zamčená.

[David Heidelberg]

Souhlasím, ale popravdě ono se špatně shazuje kwin, když s ním nemůžeš téměř nic udělat. Oni si to posychrují, aby to nešlo schodit v režimu zamknuté obrazovky

[Bilbo]

xlock -mode blank (spouštěný xautolockem) řeší věci uspokojivě. Když se k tomu ještě přidá nastavení dpms aby se monitor po 5 mintách vypl, tak je vyřešeno :)

[xkucf03]

xlock -mode blank (spouštěný xautolockem) řeší věci uspokojivě

jj, to funguje a některé spořiče tam jsou docela pěkné, navíc to oldschool odemykání Jenže jak se to liší od třeba KDEčkového spořiče? Když odjinud dám killall xlock, tak se obrazovka odemkne – počítám, že stejně se to bude chovat i když spořič spadne. Šlo mi o to, jestli by tu nemohla být nějaká „vyšší autorita“ (X server), která by zajistila nějaké neprůstřelné zamykání a spořič by byl zodpovědný jen za generování obrazu.

[Bilbo]

Mně osobně xlock teda nikdy nespadl, ani jsem neviděl, že by někde spadl. Ovšem pokud by zamykání bylo integrováno přímo ve window manageru, tak by to pak tak trochu takhle fungovalo - jelikož pokud window manager skončí (např. pokud sletí) tak Xka to berou jako odhlášení a zruší hned celou session :)

A pokud někdo má přístup ke commandline, že může dát killall xlock tak vůbec nemusí řešit nějaký spořič, ale může rovnou použít příkazy typu rm -rf ~ nebo tar -cvjf /mnt/flashka/ukradena_data.tar.bz2 ~

[pavlix]

jelikož pokud window manager skončí (např. pokud sletí) tak Xka to berou jako odhlášení a zruší hned celou session :)

To pokud vím obecně neplatí.

[Bilbo]

Pravda, u mně ne (protože místo windowmanageru jsem si tam dal vlastní skript co při jeho pádu ho znovu spustí), ale obecně mám dojem, že všude jinde při skončení windowmanageru skončí i X session.

Kde například je to jinak?

[pavlix]

Kde například je to jinak?

Dal jsem killall gnome-shell. Všecko zmizlo, během pár vteřin se znovu objevilo a dokončuju tento komentář (Fedora 15 Alpha). Dřívější zkušenosti budou podle mě určitě z Gnome 2, možná z KDE. Opačnou zkušenost mám myslím jen u Openboxu zatím.

[stativ]

O zamykání obrazovky by se měl správně starat kompozitor.

A když spadne KWin, tak se obrazovka odemkne? IMHO by to mělo fungovat takhle:

1. Kdo chce, aby se mu na obrazovce po dobu nečinnosti promítaly nějaké obrazce, ať se mu promítají – i kdyby to měla být 3D grafika nebo HD video – je to jeho počítač a jeho účet za elektřinu.
2. Zamykání by se mělo řešit nějak systémově (možná už to tak je…). Obrazovka by se zamkla (podobně nedobytně, jako když na tty1 bliká login prompt) a spořič by mohl do nějaké „roury“ vysílat, co se má na obrazovce dít – kdyby spořič spadl, zůstal by tam prostě ten poslední obraz nebo prázdno, ale obrazovka by byla pořád zamčená.

Ad 1.) To je fakt, klidně ať si tam dotyčný pustí nějaké demo. Spořič není vlastně nic jiného, zamykání IMHO do kompetence spořiče nepatří.

Ad. 2.) Řekl bych, že mít zamykání v KWin je systémovější než na to mí samostatnou aplikaci, u které lze jen doufat, že bude mít exkluzivní přístup ke klávesnici a nepůjde ji ani jinak obejít. Ideální by byl přesun přímo do X serveru. To se asi nestane, nicméně pro wayland je to v plánu.

[Laco]

Vo Windows 7 nie je defaultne nastaveny ziadny screensaver. Monitor sa po 10min. vypne. Da sa vsak nastavit. Na vyber je 5 picovyn + 1 blank screen...

[Mandarinka]

Sláva, pokrok.

[MeeeTaaaLiiiCaaa]

Fap Fap Fap

[munich machine]

to je velmi zaujimave

[vain]

Hehe, úplně to samé jsem si pomyslel, když jsem to četl =)

[trekker.dk]

To není pravda, je tam nastavená černá obrazovka, PAK se monitor vypne.

[Laco]

Neviem ako v tvojej verzii, ale v mojej nie je cierna obrazovka nastavena. Okamzite sa vypina.

[stativ]

Super! Nechápu, proč to tolika lidem vadí.

Za prvé v dnešní době se s monitorem, který se dá vypálit (s výjimkou AMOLED) člověk nesetká, za druhé chlapci z KDE narozdíl od vývojářů GNOME dávají možnost nastavení, takže bych se nebál toho, že už nepůjde nastavit nějaká animace a za třetí je kravina mít spořič obrazovky jako samostatnou aplikaci a nemít ho v kompozitoru.

IMO hlavně u zamykání je to problém, protože samostatná aplikace bude určitě obsahovat spoustu různých hacků aby zaručila, že bude exkluzivně zachytávat vstup. Přesun do kompozitoru je tedy naprosto logický krok (BTW: wayland by to měl řešit úplně stejně). Problémy co popisuje Martin na svém blogu se mi zdají taky naprosto legitimní.

[R]

Nie? Staticky obraz sa vypali do CRT a plazmy. Pri LCD je ten fyzikalny proces iny, ale vysledok rovnaky.

[stativ]

Plasma ani CRT se už běžně nepoužívají. Zbytek viz výše – tak si tam pusť nějaké demo.

[trekker.dk]

Nechápu, proč to tolika lidem vadí.

Já zas nechápu, proč tolik lidí skáče radostí kvůli odstranění něčeho, co se dá snadno vypnout (pokud to náhodou není vypnuté už ve výchozím nastavení)

[stativ]

Já skáču radostí, protože se pro mě (a spoustu dalších lidí) důležitá funkcionalita zamykání přesouvá na vhodnější místo, než je screensaver.

[Atom321]

Dovolím si nesouhlasit:

• CRT se stále vyrábějí - pro profesionální grafiky. K počítači se občas připojují plazmové televize. Je docela dobře možné, že problémem displejů bl9zk0 budoucnosti (na bázi OLED) nebude spotřeba, ale naopak zase vypalování pixelů.
• Přechod do plného provozu ze screen-saveru je prakticky okamžitý, narozdíl od úsporných režimů monitoru. Jako mezistupeň je to praktická věc.
• Distribuované výpočty na nevyužitých počítačích (BOINC).
• Některým lidem se "šetřič" prostě líbí, i když nic nešetří.

[stativ]

Jak už jsem zmínil – nevěřím tomu, že by možnost tam dát animaci úplně odstranili a hlavně – jaký je problém v tom pustit si xsreensaver nebo animaci ručně?

Já nevím co máte pořád s tím screensaverem – je to aplikace jako každá jiná, akorát se jí říká screensaver. I puštěné fullscreen video je schopné screensaver co se týče relaxace a ochrany proti vypálení zastoupit. Akorát se to nejmenuje screensaver.

[Zopper]

Jenže zprávička vyznívá tak, že "k čemu je spořič, nebudeme se zdržovat jeho programováním, prostě půjde jen nastavit, kdy se má monitor vypnout." Ruční pouštění postrádá smysl... Když opouštím pc v práci, tak ho samozřejmě zamknu, ale doma prostě jen odejdu.

Nemluvě o tom, že znám lidi, kteří od pc odběhnou a zapomenou, že je zapnutý - poté, co několikrát jel pc zcela zbytečně přes noc jsem deaktivoval vypínání monitoru a dal tam divoký spořič - od té doby problém zapomínání zmizel (u notebooku nelze z bezpečnostních důvodů nechat odemknutou obrazovku).

[xkucf03]

jaký je problém v tom pustit si xsreensaver nebo animaci ručně?

Problém v tom není – jde jen o to, že spořiče znamenají jakési API resp. jednotný přístup ke spouštění těchto programů (jinak souhlas – spořič je obyčejný program) – abys nemusel pouštět jednou VLC kvůli videu a jindy OpenArenu kvůli nějakému 3D demu – prostě je to řešené jednotně + k tomu je možnost tyhle programy pouštět po určité době nečinnosti automaticky. Navíc jde rozpoznat, zda se právě spoří – a podle toho může např. IM klient poznat, že uživatel odešel od obrazovky – nebo naopak video přehrávač může zakázat spuštění tohoto programu (spořiče), zatímco spuštění jiného programu by těžko zakazoval…

[stativ]

Problém v tom není – jde jen o to, že spořiče znamenají jakési API

Teoreticky. Nejsem žádný odborník na spořiče, ale podle toho co jsem zrovna nedávno četl v mailing listu Mplayeru to tak růžové není.

[Bilbo]

I v LCD se vypálí statický obraz, pozoruju to, když přepnu z jedné plochy kde je otevřené delší dobu nějaké okno na jinou která je prázdná (tmavé pozadí) - to okno tam je pořád vidět. Ale narozdíl od CRT to není nevratné a během cca půl hodiny se to "přepálí" na nový obraz.

[Martin Mareš]

Předpokládáte mimo jiné zcela mylně, že všichni na světě touží po používání kompozitoru. Mít screen saver oddělený od window manageru a kompozitoru je proto velmi rozumné.

[stativ]

OK, v tom případě si nahraďte kompozitor za window manager.

[pavlix]

A co se tím změní? Vznikne symetrická situace, ne?

[stativ]

Window manager nemusí nutně používat kompozitor. Jaksi předpokládám, že dotyčný bude chtít používat nějaký window manager. Popravdě si nedovedu moc představit, že by někdo chtěl používat něco ve smyslu xinit xscreensaver.

Podle mého by screensaver a uzamykání měli být řešeny systémověji – jak už jsem zmiňoval nejlépe v Xkách, anebo alespoň ve WM (což u moderních WM znamená, že by to bylo nejspíš v kompozitoru).

Oproti řešení externí aplikací vidím jen samé výhody. Nejsou zde problémy s překreslováním (jedině WM samotný může stoprocentně zajistit, že plochu nic jiného nepřekreslí). Jsou tu teoreticky i bezpečností výhody – když sletí externí aplikace, která má sloužit jako zámek, dostanu se na plochu uživatele. Když sletí WM, tak to uživatele odhlásí nebo přinejmenším systém nepůjde moc používat (což sice není nic moc, ale pořád lepší než volný pohyb). A kdyby to bylo v Xkách, tak to bude ještě lepší.

[pavlix]

Window manager nemusí nutně používat kompozitor.

Tvrdil někdo opak?

Jaksi předpokládám, že dotyčný bude chtít používat nějaký window manager.

Až na výjimky uživatel bude chtít window manager, ano.

Popravdě si nedovedu moc představit, že by někdo chtěl používat něco ve smyslu xinit xscreensaver.

Argumenty ad absurdum kvalitu diskuze obvykle snižují. Tenhle navíc strhává pozornost k něčemu nepodstatnému, co ti lze sice lehce vyvrátit, ale s tématem to nemá moc společného.

Oproti řešení externí aplikací vidím jen samé výhody.

Tak tradiční výhody jsou jednoduchost a univerzálnost. Jedna aplikace pro jednu úlohu.

Když sletí WM, tak to uživatele odhlásí nebo přinejmenším systém nepůjde moc používat

Naposled, když mi spadl WM, tak se spustil znovu. Tedy žádná výhra.

(což sice není nic moc, ale pořád lepší než volný pohyb).

Takže bys dal přednot polovičatému, nesystémovému řešení... bezva.

A kdyby to bylo v Xkách, tak to bude ještě lepší.

Aby bylo jasno, já neříkám, jestli má být screensaver samostatný, nebo součást WM nebo součást grafické platformy. Ve všem z toho vidím určité výhody.

Ale tvoje argumenty jsou naprosto nepřesvědčivé a děravé.

[stativ]

Tvrdil někdo opak?

Ne, ale byla tu připomínka, že ne všichni chtějí používat kompozitor.

Popravdě si nedovedu moc představit, že by někdo chtěl používat něco ve smyslu xinit xscreensaver.

Argumenty ad absurdum kvalitu diskuze obvykle snižují. Tenhle navíc strhává pozornost k něčemu nepodstatnému, co ti lze sice lehce vyvrátit, ale s tématem to nemá moc společného.

Zmínil jsem to, protože by se určitě našel někdo, kdo by začal řešit, že nepočítám s lidmi, co chtějí používat čistá Xka. Tak jsem si to odbyl rovnou a nebude se to muset řešit později.

Tak tradiční výhody jsou jednoduchost a univerzálnost. Jedna aplikace pro jednu úlohu.

Tuhle výhodu uznávám u systémových utilit, kde je můžu řetězit a tak. U GUI se mi to taková výhra nezdá. Navíc si dovedu docela dobře představit ovládání pomocí D-Bus.

Naposled, když mi spadl WM, tak se spustil znovu. Tedy žádná výhra.

Když mě naposledy padnul Window Manager (WM z Berylu), tak to komplet vytuhlo a nic nešlo dělat. A když už jsou vývojáři schopni udělat WM tak, aby se při pádu restartoval, nebylo by o moc těžší tam přidat podmínku, aby pokud byl obraz uzamčený tak zase naběhl do stavu „zamčeno.“ I když technicky vzato by to šlo udělat i u screensaveru jakožto samostatné aplikace.

Takže bys dal přednot polovičatému, nesystémovému řešení... bezva.

Jsem pragmatik. WM má na rozdíl od grafické aplikace mnohem větší možnosti.

Ale tvoje argumenty jsou naprosto nepřesvědčivé a děravé.

V čem jsou nepřesvědčivé a děravé?

[pavlix]

Ne, ale byla tu připomínka, že ne všichni chtějí používat kompozitor.

Ne v mém komentáři, na který jsi reagoval.

Zmínil jsem to, protože by se určitě našel někdo, kdo by začal řešit, že nepočítám s lidmi, co chtějí používat čistá Xka. Tak jsem si to odbyl rovnou a nebude se to muset řešit později.

Aha, proto jsi napsal xinit screensaver :D.

Tuhle výhodu uznávám u systémových utilit, kde je můžu řetězit a tak. U GUI se mi to taková výhra nezdá. Navíc si dovedu docela dobře představit ovládání pomocí D-Bus.

D-bus je právě ukázkou toho, co ty píšeš, že není až taková výhra. Nechápu, že ti sedí to napsat obojí v jednom odstavci.

Když mě naposledy padnul Window Manager (WM z Berylu), tak to komplet vytuhlo a nic nešlo dělat.

Jiná ves, jiný pes :). Jak sám vidíš, nelze se na to obecně spolehnout.

A když už jsou vývojáři schopni udělat WM tak, aby se při pádu restartoval, nebylo by o moc těžší tam přidat podmínku, aby pokud byl obraz uzamčený tak zase naběhl do stavu „zamčeno.“

Teoreticky ano, ale bude to prasárna typu uložit stav na disk. Jinak... mám za to, že tohle je první konstruktivní věc, kterou jsi v diskuzi napsal, takže blahopřeju.

Jsem pragmatik. WM má na rozdíl od grafické aplikace mnohem větší možnosti.

Pragmatik by to zanechal ve funkčním stavu a jen opravoval chyby a vylepšoval :). Kompletní redesign vyžaduje trošku divočejší přístup.

V čem jsou nepřesvědčivé a děravé?

Vidíš a já měl za to, že jsem ti na otázku odpověděl už v předchozím komentáři.

[stativ]

Ne v mém komentáři, na který jsi reagoval.

V tom případě piš komentáře tak, aby se daly jednoznačně pochopit. Protože já ho pochopil tak, že ti jde o to, jaký je rozdíl mít ho ve Window Manageru. A na to jsem odpověděl – WM budeš mít víceméně všude. Kompozitor ne. Takže implementace ve WM je univerzálnější.

D-bus je právě ukázkou toho, co ty píšeš, že není až taková výhra. Nechápu, že ti sedí to napsat obojí v jednom odstavci.

Nemám s tím nejmenší problém. Na rozdíl od toho mít kupříkladu Amarok rozestrkaný do několika specializovaných aplikací (správce sbírky, přehrávač…) a muset to propojovat ručně. Zároveň ale využiji D-Bus kvůli možnosti dálkového ovládání přes mobil.

Jiná ves, jiný pes :). Jak sám vidíš, nelze se na to obecně spolehnout.

Obecně možná ne, ale stačí, když se půjde spolehnout na WM, který v sobě integruje vlastnosti screensaveru.

Teoreticky ano, ale bude to prasárna typu uložit stav na disk.

Tohle leckteré WM už dávno dělají.

Pragmatik by to zanechal ve funkčním stavu a jen opravoval chyby a vylepšoval :). Kompletní redesign vyžaduje trošku divočejší přístup.

Problém nastává ve chvíli, kdy současný přístup narazí na své limity. Pokud víš, jak zaručeně zamezit WM v překreslení plochy screensaveru tak hurá do toho a oprav alespoň xscreensaver a kscreensaver.

[Martin Mareš]

Pokud víš, jak zaručeně zamezit WM v překreslení plochy screensaveru tak hurá do toho a oprav alespoň xscreensaver a kscreensaver.

Proč si myslíte, že je to bug screen saveru a nikoliv toho WM?

Já xscreensaver už používám odhadem 12 let a ještě se mi nestalo, že by mi ho překreslilo cokoliv mimo XOSD (u kterého prostě není dobře definované, jestli má být nad nebo pod screen saverem).

[stativ]

Proč si myslíte, že je to bug screen saveru a nikoliv toho WM?

Nemusí to být nutně bug. Kde ten bug je je v celku jedno, prostě by to mělo fungovat. I kdyby ten bug byl ve WM, tak by se s tím měl screensaver poprat.

Já xscreensaver už používám odhadem 12 let a ještě se mi nestalo, že by mi ho překreslilo cokoliv mimo XOSD (u kterého prostě není dobře definované, jestli má být nad nebo pod screen saverem).

Mě se to stalo bohužel už několikrát. Ale i XOSD je ukázka toho, že screensaver nemůže stoprocentně ovlivnit, jestli bude úplně na vrchu nebo ne.

[pavlix]

V tom případě piš komentáře tak, aby se daly jednoznačně pochopit. Protože já ho pochopil tak, že ti jde o to, jaký je rozdíl mít ho ve Window Manageru. A na to jsem odpověděl – WM budeš mít víceméně všude. Kompozitor ne. Takže implementace ve WM je univerzálnější.

Ono někdy stačí neplést si komentáře od různých lidí. A když se to stane, tak napsat „pardon, já se přehlédl“. Mně se to občas stává a takhle přesně to řeším.

Nemám s tím nejmenší problém. Na rozdíl od toho mít kupříkladu Amarok rozestrkaný do několika specializovaných aplikací (správce sbírky, přehrávač…) a muset to propojovat ručně. Zároveň ale využiji D-Bus kvůli možnosti dálkového ovládání přes mobil.

Tvoje představa o D-busu je ale z hlediska reálného použití ta minoritní. Neříkám, že špatná, jen minoritní.

Podívej se třeba, jak funguje Empathy a Telepathy. Tam máš různé správce spojení pro různé protokoly, jednoho správce účtů na těch protokolech, a další komponenty, co tvoří backend.

A nad tím máš Empathy, která se na venek tváří jako jeden program, ale ve skutečnosti je seznam kontaktů jeden program, chatovací okno další, prohlížeč historie další, a okno na videohovor taky.

To samé třeba Avahi, které slouží jako backend pro objevování okolních počítačů, tiskáren apod, a k tomu máš konzolové nástroje a GUI nástroje.

Podobně NetworkManager a další.

Init program systemd na D-busu staví velkou část zavádění systému.

API pro přístup ke GUI aplikaci je sice hezká věc, ale z hlediska nasazení ta míň významná aplikace D-busu.

Obecně možná ne, ale stačí, když se půjde spolehnout na WM, který v sobě integruje vlastnosti screensaveru.

Pokud ty máš radši WM, který při pádu bere všechno s sebou, já mám radši WM, který mi nezničí rozdělanou práci.

Tohle leckteré WM už dávno dělají.

Osobně si nemyslím, že by to byl zrovna v tomto případě dobrý přístup, ale třeba někdy změním názor.

Problém nastává ve chvíli, kdy současný přístup narazí na své limity.

Až budu mít pocit, že současný přístup naráží na limity, třeba změním názor. Zatím k tomu nemám sebemenší důvod.

Pokud víš, jak zaručeně zamezit WM v překreslení plochy screensaveru tak hurá do toho a oprav alespoň xscreensaver a kscreensaver.

Jsem sice programátor, ale v této oblasti jsem v první řadě uživatel. Tudíž řeším jen skutečné problémy, se kterými přijdu do styku a v software, který používám (nebo aspoň někdo z mého okolí, kdo mi stojí za trochu práce).

Programy xscreensaver a kscreensaver v tuhle chvíli nepoužívám.

[stativ]

Ono někdy stačí neplést si komentáře od různých lidí. A když se to stane, tak napsat „pardon, já se přehlédl“. Mně se to občas stává a takhle přesně to řeším.

Nepřehlédl jsem se. Evidentně jsem tvůj komentář vůbec nepochopil. A nechápu ho doteď.

Tvoje představa o D-busu je ale z hlediska reálného použití ta minoritní. Neříkám, že špatná, jen minoritní.

Možná. Svého času DCOP, předchůdce D-Bus, se většinou používal takto a přijde mi to i jako nejrozumnější využití. A v KDE se mi tenhle způsob použití až tak minoritní nezdá. Spíš to bude specifikum pro GNOME a programy od lidí okolo.

Podívej se třeba, jak funguje Empathy a Telepathy. Tam máš různé správce spojení pro různé protokoly, jednoho správce účtů na těch protokolech, a další komponenty, co tvoří backend. …

Ne, že by to přímo souviselo s tématem… Ale budiž. Tohle použití se mi zrovna moc nepozdává, ale přežiju ho.. Spousta věci by se dala řešit shared knihovnou. A rozsekávaní aplikací tak, jak popisuješ Empathy mi přijde poněkud… zvláštní.

Pokud ty máš radši WM, který při pádu bere všechno s sebou, já mám radši WM, který mi nezničí rozdělanou práci.

Viz dříve – stačí, když zaručí, že naběhne do uzamčeného stavu.

Osobně si nemyslím, že by to byl zrovna v tomto případě dobrý přístup, ale třeba někdy změním názor.

Myslíš, že to tvé obnovení při pádu je něco jiného? Akorát by se kromě informace kde bylo jaké okno předala i informace, že to má být uzamčeno.

Až budu mít pocit, že současný přístup naráží na limity, třeba změním názor. Zatím k tomu nemám sebemenší důvod.

Šťastný to člověče. Kolikrát já už viděl screensaver, který byl překreslen obsahem nějakého okna….

Programy xscreensaver a kscreensaver v tuhle chvíli nepoužívám.

Asi právě proto jsi se s takovým problémem ještě nesetkal.

[pavlix]

Možná. Svého času DCOP, předchůdce D-Bus, se většinou používal takto a přijde mi to i jako nejrozumnější využití. A v KDE se mi tenhle způsob použití až tak minoritní nezdá. Spíš to bude specifikum pro GNOME a programy od lidí okolo.

DCOP možná, a kde D-bus nahrazoval DCOP, dejme tomu.

NetworkManager a Avahi mi nepřijdou zrovna Gnome-specific. A pokud jde o Telepathy, i pro něj se momentálně tvoří sada KDE aplikací mimojiné proto, že je takový přístup velmi výhodný.

Ne, že by to přímo souviselo s tématem… Ale budiž. Tohle použití se mi zrovna moc nepozdává, ale přežiju ho.. Spousta věci by se dala řešit shared knihovnou.

Právě. Spousta věcí by se dala řešit shared knihovnou a spousta věcí se daleko lépe řeší pomocí IPC. Je to modulárnější, stabilnější a flexibilnější. Jednotlivé aplikace jsou jednodušeji nahraditelné za běhu, což je dobré i pro vývoj.

A rozsekávaní aplikací tak, jak popisuješ Empathy mi přijde poněkud… zvláštní.

Zvláštní možná proto, že ho neznáš, a otázka je, jestli vůbec máš šanci ho poznat. Z hlediska uživatele totiž není vidět nic.

Dobrý na oddělení backendu a frontendu je třeba i to, že backend se použije všude a vytvoří se různé frontendy pro různé typy zařízení. Teoreticky by o to šlo řešit sdílenými knihovnami, ale samostatně běžící proces má spoustu výhod typu že při ladění jdou používat stejné nástroje bez ohledu na frontend.

Viz dříve – stačí, když zaručí, že naběhne do uzamčeného stavu.

To je samozřejmě zajímavá myšlenka, kterou jsi už dříve popsal, jen mi konceptuálně nesedí, aby se o toto staral WM. Pokud není jiná možnost, tak ano, ale jinak k tomu nevidím jediný důvod.

Myslíš, že to tvé obnovení při pádu je něco jiného? Akorát by se kromě informace kde bylo jaké okno předala i informace, že to má být uzamčeno.

A máš nějaký zdroj, podle kterého gnome-shell při každém pohybu okna sahá na disk? Já o tom silně pochybuju, protože na mém ntb je rozjetí disku slyšet a při přesouvání oken je úplně zticha.

Šťastný to člověče. Kolikrát já už viděl screensaver, který byl překreslen obsahem nějakého okna….

Zřejmě jsem bez xscreensaver a kscreensaver, případně bez aplikace, které to způsobuje, šťastný člověk.

[stativ]

NetworkManager a Avahi mi nepřijdou zrovna Gnome-specific. A pokud jde o Telepathy, i pro něj se momentálně tvoří sada KDE aplikací mimojiné proto, že je takový přístup velmi výhodný.

Avahi ne, ale NM vcelku ano. Jak by také ne, když byl od začátku vyvíjen společně s appletem pro GNOME, ale ne pro KDE. Svého času, když vznikal KNetworkManager pro KDE, jsem narazil na nářky vývojářů KDE, že spousta věcí je tam dělaná dělaná tak, aby to sedlo GNOME.

Právě. Spousta věcí by se dala řešit shared knihovnou a spousta věcí se daleko lépe řeší pomocí IPC. Je to modulárnější, stabilnější a flexibilnější. Jednotlivé aplikace jsou jednodušeji nahraditelné za běhu, což je dobré i pro vývoj.

O tom se hádat nehodlám, nemám s tím dost zkušeností. Rád tomu budu i věřit, ale řešení Empathy se mi zdá už přehnané.

To je samozřejmě zajímavá myšlenka, kterou jsi už dříve popsal, jen mi konceptuálně nesedí, aby se o toto staral WM. Pokud není jiná možnost, tak ano, ale jinak k tomu nevidím jediný důvod.

Nejradši bych to viděl přímo v Xkách, aby to každý WM neimplementoval zvlášť. Toho se ale asi nedočkám (až s waylandem), takže jsem rád, že to bude aspoň v KWin.

A máš nějaký zdroj, podle kterého gnome-shell při každém pohybu okna sahá na disk? Já o tom silně pochybuju, protože na mém ntb je rozjetí disku slyšet a při přesouvání oken je úplně zticha.

Kam si ty informace ukládá netuším a vzhledem k tomu, že na gnome shell nepracuji je mi to vcelku jedno. Pro účely diskuse stačí, že se to někde zaznamenává – jedno jestli někde v RAM nebo na disku. Hlavní je, že informace o pozici oken evidentně jdou předávat nově nabíhajícímu WM a tudíž by měla jít i předat informace o tom, že se má spustit WM už uzamčený.

[pavlix]

Avahi ne, ale NM vcelku ano. Jak by také ne, když byl od začátku vyvíjen společně s appletem pro GNOME, ale ne pro KDE. Svého času, když vznikal KNetworkManager pro KDE, jsem narazil na nářky vývojářů KDE, že spousta věcí je tam dělaná dělaná tak, aby to sedlo GNOME.

To je pro mě jako postupného uživatele mnoha různých desktopů včetně KDE příliš nekonkrétní. Pořád mám pocit, že je to tak trochu desktop jako desktop. Network manager potřebuju aby uměl vydat info o sítích, připojit k síti, atd, nedokážu si představit jedinou věc, která by tam mohla být „dělaná aby to sedlo Gnome“.

Obávám se, že to bude nějaký dost neurčitý nářek.

Ale pořád je tu Avahi, které funguje jako typický backend.

O tom se hádat nehodlám, nemám s tím dost zkušeností. Rád tomu budu i věřit, ale řešení Empathy se mi zdá už přehnané.

Tím, že je Empathy frontend, tak je to v podstatě jedno. Jednotlivá grafická okna spolu prakticky nepotřebují spolupracovat jinak než přes Telepathy, a i kdyby, pořád je možnost použít D-bus mezi nimi.

Zajímavé je, že se u kterékoli komponenty dá vybrat, jestli ji implementuje samostatná aplikace nebo třeba gnome-shell (pokud to má teda smysl). V podstatě to dává designerům volné ruce, když něco chtějí přesunout někam jinam :).

Nejradši bych to viděl přímo v Xkách, aby to každý WM neimplementoval zvlášť. Toho se ale asi nedočkám (až s waylandem), takže jsem rád, že to bude aspoň v KWin.

Zamykání pomocí Xek, jo, to mi přijde smysluplnější, nebo alespoň nějaké mezivrstvy či samostatné Xkové aplikace :). Mně to prostě přijde jako krok zpět.

Kam si ty informace ukládá netuším a vzhledem k tomu, že na gnome shell nepracuji je mi to vcelku jedno. Pro účely diskuse stačí, že se to někde zaznamenává – jedno jestli někde v RAM nebo na disku.

Chyba, protože pokud je to v RAM, znamená to, že se o ty informace nestará WM (který v tu chvíli neběží), ale buď aplikace nebo Xka. Podle mě to jsou Xka.

Hlavní je, že informace o pozici oken evidentně jdou předávat nově nabíhajícímu WM a tudíž by měla jít i předat informace o tom, že se má spustit WM už uzamčený.

Ono to celé nemá moc smysl, protože kdyby se podařilo WM ukončit tak, aby se nemohl znovu spustit, tak to zamykání nefunguje. Ty aplikace totiž pořád běží a vykreslují se a reagují na události.

Takže zamykání WM není zamykání desktopu.

[stativ]

To je pro mě jako postupného uživatele mnoha různých desktopů včetně KDE příliš nekonkrétní. Pořád mám pocit, že je to tak trochu desktop jako desktop. Network manager potřebuju aby uměl vydat info o sítích, připojit k síti, atd, nedokážu si představit jedinou věc, která by tam mohla být „dělaná aby to sedlo Gnome“.

Říkám, co jsem četl. Viděl bych to na používání nedokumentovaných rozhraní a podobně.

Tím, že je Empathy frontend, tak je to v podstatě jedno. Jednotlivá grafická okna spolu prakticky nepotřebují spolupracovat jinak než přes Telepathy, a i kdyby, pořád je možnost použít D-bus mezi nimi.

Rozdělení backendu a frontendu mi přijde dobré. Narážel jsem na toto:

A nad tím máš Empathy, která se na venek tváří jako jeden program, ale ve skutečnosti je seznam kontaktů jeden program, chatovací okno další, prohlížeč historie další, a okno na videohovor taky.

To mi přijde jako naprostá kravina.

Podle mě to jsou Xka.

Co to má na svědomí není důležité. Hlavně, že to jde.

Ono to celé nemá moc smysl, protože kdyby se podařilo WM ukončit tak, aby se nemohl znovu spustit, tak to zamykání nefunguje. Ty aplikace totiž pořád běží a vykreslují se a reagují na události.

Nikde neříkám, že zamykání ve WM je perfektní. Jasně, že to má své chyby, jako je tato, ale pořád mi to přijde lepší než současný stav.

[Martin Mareš]

To je opět špatně: znamená to, že screen saver by musel být implementován ve všech window managerech, čili zbytečnou duplikaci kódu.

[Fluttershy, yay!]

Moment, vždyť situace je trošku jiná -- prostě se zruší KScreensaver, resp. se zabuduje do KWinu, z čehož pro ostatní správce oken nebo prostředí neplyne vůbec nic, je rozhodnutí jejich vývojářů, zda budou následovat vzor z KDE, nebo ne.

[Martin Mareš]

Screen saver a window manager jsou dvě naprosto nezávislé věci. Proto dává smysl implementovat je odděleně, aby bylo možné používat každý screen saver s každým window managerem.

Opravdu nechápu naivitu některých autorů, kteří si myslí, že jejich desktopové prostředí je jediné zajímavé na celém světě, a proto se nestarají, jak jejich aplikace spolupracují s aplikacemi, které vyvinul někdo jiný.

[Fluttershy, yay!]

Holt vývoj. Myslím, že něco podobného kdosi tvrdil při nástupu Plasmy... že přece panel (Kicker), widgety (SuperKaramba) a X dalších věcí je naprosto nezávislých. Kdo si dneska vzpomene na Kicker? Leda těch pár jedinců (IMHO zoufalců), kteří se snaží držet Trinity. Má někdo potřebu používat jiný panel v Plasma Workspace? O nikom takovém nevím.

A tohle je ještě v pohodě, už jsem četl návrh na sloučení KWinu a Plasmy.

Opravdu nechápu naivitu některých autorů, kteří si myslí, že jejich desktopové prostředí je jediné zajímavé na celém světě, a proto se nestarají, jak jejich aplikace spolupracují s aplikacemi, které vyvinul někdo jiný.

To by asi neexistovaly snahy jako oxygen-gtk. Jinak ano, jde o desktopové prostředí (ač Plasma Workspace je nejen pro desktop, takže bych se toho adjektiva tam vyvaroval), u nějž je stěžejní integrace a provázanost aplikací atp. Je logické, že když prostředí P používá knihovny K a prostředí R knihovny L, nejspíš součásti P se nebudou integrovat v prostředí R zrovna nejlépe.

[xkucf03]

Viz #11 – mně by se líbilo, kdyby se o zamknutí obrazovky postaral WM a o generování obrazu k promítání se staral jiný program – a bylo by definované nějaké API, aby šlo používat libovolný generátor/spořič v libovolném VM.

[Martin Mareš]

A v čem se to doopravdy liší od současného stavu?

Nebo chcete, aby bylo zamykání integrováno do WM včetně udělátka na zadávání hesla pro odemčení? To mi přijde, že už s window managementem naprosto nesouvisí, takže to ve WM nemá co dělat.

[Fluttershy, yay!]

Já tam souvislost vidím, takové zamknutí znemožní manipulaci s okny.

[Martin Mareš]

Samotné zamknutí (jinými slovy grabnutí všech input-eventů) samozřejmě ano a to mimochodem dělá X server sám. Nějaké zadávání hesla pro odemčení nicméně nemá společného ani zbla.

[Fluttershy, yay!]

Mohlo by to volat nějaký dialog jako kdesu. ^.^

[Bilbo]

Na druhou stranu, funkčnost současného screensaveru by šla oddělit - na vlastní screensaver (tedy tu část co pouští na obrazovku všelijaké obrazce aby to buď hezky vypadalo, šetřilo obrazovku, přáípadně obojí) a zamykání (tedy to co člověka nepustí zpátky do systému pokud nezadá heslo) - jelikož někdo by tam mohl chtít např. ověřování biometrické (obličej před kamerou, otisk prstu...), někdo zase extra tlačítko typu "Nechat tuhle session být jak je, ale pustit si druhou session pod jiným uživatelem", atd ....

[......]

Co to sakra je? M$ asi nasadil patou kolonu i do sveta oss :/

Na jedne strane trend Less features: gnome, kde... Na druhe strane vic zbytecneho bordelu: mono(izace), gnome registry, grub2, *buntu na kterych nekdo z pro me nepochopitelnych duvodu stavi dalsi distra, vsemozne kdovijake spojovani nesouvisejicich veci, dependency hell u sw pro kde a gnome......

Btw schvalne, kolik najdete distribuci,ktere jsou defaultne! bez bordelu a clovek se v nich perfektne vyzna... Vyjdou vam akorat ty, ktere si musite pracne sami od zakladu sestavit... Smutne