V čom spočíva príťažlivosť klikacích nástrojov (diskuse)

[TomV]

Ještě bych dodal, že klikací nástroje umožňují přidat k jednotlivým položkám bublinovou nápovědu, kde se člověk dozví, k čemu ta která volba slouží - no a na rozdíl od editování souborů člověk neudělá překlep v názvu či hodnotě položky. No a složité věci zůstanou složité, ať už je nastavujete klikáním nebo editováním.

[klassik]

A hlavne si nemusim pamatovat prikazy syntaxi a podobne veci. Coz pri delsim nepouzivani se z hlavy dost vytraci

[next]

Z hlavy sice syntax Xorg.conf vysvetlit nedokazem, ale akonahle ho otvorim, je mi jasna. A tak aj pre ostatne konfiguracne subory, snad s vynimkou sendmail.cf :). A ked este niekto doda highlighting konfiguraciu pre vim, tak to uz ozaj nie je problem.

[klassik]

co treba samba, zvuk, sit a kdo vi co jeste... fakt me neba porad hledat co a jak jnastavit kdyz bybylo lepsi to naklikat a dojit k tomu z nejake nabidky intuitivne

[next]

Vacsina konfiguracnych suborov ma v sebe vysvetlujuce komentare a/alebo manualovu stranku (v sekcii 5).

[Davule]

Když už najdu potřebný konfigurační soubor, mám z toho většinou radost do té doby, než ho otevřu

Teď vážně :

Když v konfiguráku chci změnit něco, aby to jinak zobrazovalo, můžu si ho přečíst stokrát tam i zpět. Když nevím, že mám zapnout třeba directfb (jednak nevím co to je a jednak mně to uráží), je mi celý konfigurák na nic

Problém konfiguráků (nebo spíš začátečníků, kteří ho chtějí upravit) je ten, že člověk ví jenom to, co chce úpravou dosáhnout (výhoda klikátek), mnohdy ví kde toho dosáhne (výhoda struktury adresářů systému), ale neví to nejdůležitější -> CO MÁ OVLIVNOVAT, aby došel k cíli!!

To je můj problém. Nedávno mi jeden plugin házel chybu "error VIDIX". Nainstaloval jsem všechny kodeky, které můj gentoo linuxek našel a nakonec jsem zjistil, že používám pouze výstup přes XV, takže stačilo zakomentovat řádek VIDIX_SUPPORT=1

[next]

Klikacie nastroje su ako mestska doprava. Pohodlne, netreba vediet soferovat, ale stoji iba tam, kde to niekto navrhol - ide z nich nastavit iba to, na co autori mysleli. Naproti tomu rucne editovanie je ako auto. Treba vediet soferovat, ale mozete ist a zastavit, kde vas cesty pustia - ide nastavit vsetko. Ano, momentalne asi z Yast ide nastavit v Xorg.conf vsetko. Ale co ak zajtra vyjde Xorg 7.1 s dalsimi moznostami? Rucne si ich nakonfigurujem hned, z Yastu nie...

A okrem toho, z vt420 sa zle klika :). Z egde/gprs spojenia rovnako. Pripadne skuste nastavit rovnaku konfiguraciu na 2000 serveroch. To su sice veci, co domaci uzivatelia nezvyknu robit, ale nerad by som sa dozil toho, ze kvoli ich pohodlnosti a lenivosti jedneho dna pojde konfiguracia _iba_ naklikat (a'la Windows).

Okrem toho, ze textovych konfigurakov sa lahsie robi copy-paste ako z klikacich zariadeni.

[zde]

Ale co ak zajtra vyjde Xorg 7.1 s dalsimi moznostami?

Základní chyba je, že "klikátko" a "aplikace" jsou dvě oddělené aplikace, které je třeba mít synchronizované. Kdyby klikátko bylo součástí aplikace, svět by byl hned o trochu jednodušší. Xorg je trochu výjimka, protože konfigurovat jej klikátkem bez toho aby už byl nakonfigurovaný je obtížné, ale klidně může být Xorg pro bootstrap alternativní menu v konzole.

Pripadne skuste nastavit rovnaku konfiguraciu na 2000 serveroch... Okrem toho, ze textovych konfigurakov sa lahsie robi copy-paste ako z klikacich zariadeni.

I naklikaná konfigurace se obvykle ukládá do (zhusta textových) souborů, takže uvedené věci "klikátka" nijak nevylučují.

[next]

X.org bol priklad, prvy co mi napadol.

Prepojenie klikatka a aplikacie ma vyznam, u aplikacii, ktore su z principu klikacie (desktopove prostredie, graficky browser, mail, atd).

Pri aplikaciach, ktore z principu klikacie nie su (X.org, CUPS, firewall, MTA, Samba,...) by to bolo zle. Priam az Windowsoidne. Napriklad tu Sambu mozem mat nainstalovanu v nejakom embedded zariadeni. Nutnost davat tam aj klikatko by bola dost tragicka.

[zde]

Proc by samba nemohla byt klikaci? Neforkovala by do pozadi, ale otevrela normalni okno. Tam byste mohlo browsit po filesystemu, pridava a ubirat shares, menit access listy, kliknout 'restart' apod.

Pro embedded zarizeni by se cely tento front-end jednoduse #ifdefy vyhodil.

[next]

Takze kazdy samba server by mal mat graficku konzolu? A admini by chodili k nemu? Pripadne by si blokovali lokalne siet, ze by samba 24x7 posielala cez X na ich desktop okno, v ktorom by bolo zobrazene nejake veci? A po zavreti okna by sa samba server vypol? Ci ako si to predstavujete?

[zde]

Jo, popisujete to správně. Ty problémy co zmiňujete nesouvisí s tím jaký model pro "samba server" použiju, ale jde o systémové chyby v návrhu a implementaci XWS.

To že dnes se typický GUI front-end k daemonům realizuje jako oddělené klikátko s TCP socketem do daemona je v podstatě jen obcházením limitací současného Unixovského GUI (a tedy jejich faktickým potvrzením).

[next]

One man's bug is another man's feature.

Ja som rad, ze Samba pracuje potichu, bez "kecov" do konzoly ci nebodaj grafickeho okna. A som rad, ze si mozem 3 hodiny editovat /etc/samba/smb.conf, 10x ho ulozit, skontrolovat jeho syntax (smbd ma na to specialny switch) a potom naraz naaplikovat.

[Dalibor Smolík]

Swat není dostatečně klikací?

[mrzout]

Me se hodne libi Mandriva, kde drakconf v okne vypisuje, co provadi. Takze zjistuje HW, tak clovek vidi ty prikazy.

Cemu rozumim, to delam rucne. A cemu ne, to si naklikam. Takze logicky vic klikam ;) Ne, neni to tak, s cim delam denne, to znam.

[Jakub Hájek]

Zrovna v MDK mi prislo, ze cokoliv naklikas, to ti konfigurak neskutecne "zprasi" a dost zneprijemni dalsi rucni editaci..

[petryk]

gratulujem , objavil si vesmir :)

[tired joe]

Uvedomiť si tie najelementárnejšie veci dá niekedy najviac námahy :))

[D-Evil]

Podle mě maj klikací nástroje ještě jednu výhodu. Rychlost v případě, že člověk nemá čas číst dokumentaci a potřebuje, aby něco nějak fungovalo, aspoň základním způsobem. Myslim že např. na noteboocích to může bejt v určitejch chvílích neocenitelnej pomocník.

[zde]

Pokud se bavíme o dlouhodobých procesech (daemonech), tak klikací nástroje mají další ohromnou výhodu: výrazně jednodušší meziprocesovou komunikaci (resp není vůbec potřeba). Příklady:

MOCP vs XMMS: XMMS jednoduše běží jako jeden proces (když pominu realtime thread který dekóduje mp3), a každé kliknutí na ovládací prvek jde přímo do aplikace bez zbytečných mezivrstev. Naopak MOCP neumí minimalizaci, proto se musí rozdělit na "server" a "clinet" část, která zbytečně definuje nějaký (relativně složitý) protokol pro jejich vzájemnou komunikaci. Jistě, výhodou je možnost spustit server a client na různých strojích, ale proč to proboha dělat, když si už stejně mohu jednoduše zobrazit okno vzdálené aplikace na svém desktopu?

To samé platí pro libovolný daemon- uvažujme např. FTP nebo WWW server. Zatímco na Windowsech běží aplikace v pohodě v systrayi, a když ji otevřu tak z GUI jdou příkazy přímo do ní, na Linuxu je to uděláno naprosto blbě- veškeré nastavení je pouze v konfiguraci, a já mohu akorát daemonu poslat SIGHUP, aby se ji obtěžoval znovu načíst.

Chápete to? Posílat signál, že se něco změnilo. To je naprosto pomýlený model, ten daemon má jednoduše ve své select() smyčce přijímat příkazy od uživatele, a ne zpracovávat takovou obsoletní záležitost jako jsou signály. Ono totiž těch věcí které mohu chtít po typickém daemonu je podstatně víc, než jen "konfigurace se změnila". A zavádět pro každou činnost samostatný signál? A co když mají mít ty činnosti nějaké číselné nebo textové argumenty?

Nakonec to stejně vede k nějakým FIFO nebo socketům, a zbytečnému IPC, přestože jde o jednu aplikaci, a to IPC je *interní*. PRostě myslím že Unix má tohle vyřešeno velmi špatně.

[pzad]

Ste mimo. Kazdy os ma deamonov (u windows su to service). Spustite si wo windows Task manager a dajte si zobrazit procesy od vsetkych uzivatelov. Tie co tam maju v stlpci "user name" SYSTEM su vsetko services a nemaju ziadne okna a ani nie su v systray.

[Heron]

Procesů je tam málo, doporučuju sledovat počty threadů. Po bootu Windows je jich kolem 500. (Po bootu mojí fedory mám celkem cca 150 procesů (vlákna počítám mezi procesy.))

Tím neříkám co je lepší. Být to na mě, tak pro každou akci (okénko atd) vytvořím nový thread a nechť si to process scheduler vyřeší sám.

Rozdělení na server a klient je velmi dobrý nápad.

1) z hlediska bezpečnosti jste omezeni pouze na to, co nabízí komunikační protokol

2) lze to snadno rozdělit na více strojů.

3) nejste omezeni na určitou versi klienta. Server necháte být a klienty si měníte podle potřeby (příklady si každý najde sám).

A lze jít ještě dál. Třeba rozdělit i ten server. Proč by se měl starat o vše sám? On si dělá svoji práci a o jeho data se může postarat DB server. Atd.

[zde]

1) naopak- z hlediska bezpečnosti přibylo další místo, kde musíte provádět verifikaci (client-server protokol). Složitý kód (s duplikovanými bezpečnostními kontrolami) je vždy potenciálně nebezpečný kód. Nehledě na to že protokolový parser (na obou stranách) může být vždy zranitelný (buffer overflow).

2) Ano, pokud budu chtít jedním rozhraním kontrolovat webovou farmu, zcela jistě by to distribuované být mělo. Ale pro běžné daemony na desktopu by model "jeden proces na popředí s kompletním managementem v GUI" byl často lepší než typický Unixovský model "initscript, fork, načti konfigurák, bindni porty, osluhuj klienty a čekej na sighup nebo sigterm".

3) Nesoulad verzí je potenciální komplikace, nikoliv výhoda.

[Heron]

"jeden proces na popředí s kompletním managementem v GUI" byl často lepší

Takže vy chcete mít ftp, web, mail, print atd server jako GUI aplikaci? Co když se budete potřebovat odhlásit? To se všechno vypne? Nebo jak si to představujete?

3) Nesoulad verzí je potenciální komplikace, nikoliv výhoda.

JJ, to vidíme třeba u webu, že jo? Ten kdo se snaží dodržovat RFC a W3C je na tom většinou nejhůř

[next]

MOCP nepoznam, takzee s/MOCP/MPD/.

MPD je daemon, ktory hra hudbu. Ta musi byt na lokalnom adresari, klienti cez TCP posielaju prikazy, co hrat. Vyhody oproti XMMS:

1. Hudba sa hra priamo z domaceho "file" serveru, ktory ma vacsiu kapacitu ako notebook.

2. ked vypnem/rebootnem notebook, alebo len zhodim X, hudba hra dalej.

3. jeden zdroj hudby mozem zaroven ovladat z viacerych zdrojov zaroven.

Nic z tohto XMMS nevie. Aspon nevedelo, ked som ho naposledy pouzival (cca. v roku 2002-2003). Bod 1. by samozrejme siel riesit cez vzdialene X, ale to by vyzadovalo XMMS instalovane na serveri, vratane gtk+ a podobnych veci -> fuj. A body 2. a 3. by to aj tak neporiesilo. A uz vobec neviem, ako to suvisi s (ne)klikacim sposobom konfiguracie.

Daemon so selectom na konfiguracny subor? Fuj! Co ak to editujem v editore s autosave a konfigurak sa ulozi v syntakticky nespravnom medzi-stave? Co ak vyeditujem konfigurak o 18:00, ale aplikovat ho chcem az o 03:00, automaticky, bez mojho "manualneho" pricinenia? Myslim, ze nerozumiete semantike tohto vyuzitia SIGHUP. Ten SIGHUP neznamena "nieco sa zmenilo". Ten SIGHUP znamena "precitaj si novy konfigurak a zariad sa podla toho". Daemony bezne select() vyuzivaju, tam, kde je to vhodne. Napr. na sietovych socketoch.

[zde]

1. Ano, GTK+ by muselo byt na serveru. Jenze to je dusledek blbeho navrhu XWS, ktere widgety potrebuje nainstalovane u klienta, misto aby behaly na serveru, kam logicky patri.

2. Dtto. Okno forwardovane na X server pres DISPLAY= sice pri restartu sice chcipne, ovsem jsou reseni (nezavisla na aplikaci) ktera umoznuji restart X serveru bez ukonceni vzdalenych aplikaci (LTS?).

3. Ano, pokud vice lidi kolaborativne tvori playlist, tak je distribuovane reseni, rozdelene na server a (nekolik) klientu nejlepsi reseni. Ale to uz je dosti specialni pripad; typicky bude uzivatel jen jeden.

[next]

1. X mozno nie je dokonale, ale nic lepsie zatial nepoznam. Takze sa pri vybere a instalacii SW riadim tym, co je momentalne platne a dostupne, nie tym, "co keby". Pokusy nahradit X tu boli. Naposledy to skusal jeden clovek "otocit" v projekte Y-Window(s), akurat, ze ostalo ticho a nikde nic. Rovnako tak ciste frame-bufferove riesenia (GGI?).

2. Take nieco vie zatial iba Sun so svojimim Sunraymi a do urcitej miery Remote Desktop na MS Windows, pripadne VNC, mozno aj Citrix. Ak to vie niekto nad "cistymi" X, poprosim odkaz.

3. Ale houby. Ziaden specialny pripad. Ja mam doma 2 pocitace, ktore hraju hudbu a zas 2, za ktorymi zvyknem sediet (a pracovat). A mozem z kazdej workstation ovladat kazdy zdroj hudby. A hudba hra, aj ked su vsetky workstation vypnute. To proste s oknom forwardovanym na desktop fungovat nebude.

[zde]

Souhlas, to co jsem psal jsou jenom "co kdyby" žvásty. Ale to tvrdím od začátku. Kdybych dostal za úkol něco takového vytvořit, použiju model klasický daemon + oddělené klikátko pro editaci konfigurace (nebo vzdálenou správu).

BTW Četl jsi ten white paper k Y Window systemu? Moc pěkné počtení. Se mi hrozně líbilo jak byl autor velmi korektní a uctivý k autorům XWS (to jak jsou XWS skvělé je tam v různém kontextu řečeno asi 3x), ovšem mezi řádky šlo poměrně jasně číst co všechno ho na nich se*e. :)))

[Josef Kufner]

3. Ano, pokud vice lidi kolaborativne tvori playlist, tak je distribuovane reseni, rozdelene na server a (nekolik) klientu nejlepsi reseni. Ale to uz je dosti specialni pripad; typicky bude uzivatel jen jeden.

Neni to specialni pripad. Napoak. Je to naprosto bezna vec. Spousta lidi ma doma nekolik pocitacu, spousta jich ma jeden vyhrazeny jako fileserver. Kdyz ma jeden vyhrazeny jako fileserver, tak se rovnou hodi i jako brana do Internetu a pusti se tam par dlasich sluzeb. A vzhledem k tomu, ze ten pocitac vetsinu casu nic nedela, tak se vytahne kabel s repakama z komory vedle a pusti se tam mp3. Taky se tam nahodi nejaky zvukovy demon dostupny po siti a ejhle, mame tu prehravac internetovych radii, mp3 a jeste k tomu bezdratove bedynky k notebooku pripojene po wifi. No neni to krasa? Jenom to chce uvolnit prostor fantazii a neomezovat se kecama typu "obycejny uzivatel by...".

ps: tohle neni vymysl, doma mi to naprosto bez problemu uz par mesicu funguje.

[zde]

To co popisujete ale není kolaborativní editace playlistu, jde o případ jednoho uživatele, který se stejnou aplikací pracuje z více desktopů. Na to stačí ten model "vzdálený daemon s gui + vnc".

U sebe to mám jinak- na desktopu běží mocp, soubory si tahá ze serveru přes SMB. Protože server je v jiné místnosti, je blbost aby se přehrávalo tam, nebo se síť plnila dekomprimovaným audiem.

[next]

Ja som porovnal MPD s XMMS. MOCP je v tomto pripade velmi podobe MPD, takze by sa to dalo nazvat aj porovnanim MOCP s XMMS. "kolaborativni editaci playlistu" ste to nazval az vy. Tak preco z toho teraz robite protiargument?

O GUI na serveri som sa uz vyjadroval. Daemon bez gui + klient cez TCP mi osobne pripada lepsie riesenie, ako na server, ktory ma hrat hudbu instalovat GUI klient + X + vncserver...

[zde]

Za současného stavu GUI na *nixech nemá smysl daemony s GUI propojovat. Ovšem pokud by GUI (myšleno obecné vysokoúrovňové API pro GUI, nikoliv vše od xlib nahoru) bylo standardní součástí kernelu, vzdálená okna šla uživatelem volně mapovat/odmapovat/migrovat mezi desktopy, atd, měly by servery s GUI smysl, a dokonce by byly výrazně jednodušší než typické současné daemony. Ale souhlas, kdyby-chyby.

[next]

GUI v kerneli? S tym pomaly prestava uz aj MS :). Nevymenitelne, prilis vela veci beziacich v kernel mode... Skoda sa v tom zacat vrtat.

Osobne som vzdy povazoval za _vyhodu_ daemonov to, ze pracuju a nevypisuju nikam po obrazovkach zbytocne kecy. Dokonca ani services vo Windows to nerobia (to som vybral ako najvacsi kontrast, ktory mi napadol, k unixovemu stavu veci).

[zde]

Myslel jsem GUI ve smyslu nějakého defaultního message portu pro každou spuštěnou aplikaci, kam by se posílaly eventy od usera z GUI, plus nějaké API v opačném směru, kterým by aplikace vytvářela a prezentovala widgety.. Trochu jako byl rexx scripting na Amize.. To kam (a jestli vůbec) to bude forwardováno a jak to bude renderováno v GUI by bylo na kernelu nezávislé.

Samozřejmě že by to šlo řešit socketem (tak to fakticky dělají X), nebo přes stdin/stdout (jak to dělají console GUI aplikace), jenže v případě X je ten protokol příliš nízkoůrovňový, v druhém případě zase příliš vázán na konzolu.

[zde]

Sorry, MPD vůbec neznám. Tvrdil jste že pro MPD běžně *potřebujete* současný uživatelský (zřejmě interaktivní) přístup z více desktopů. Nic lepšího než editace playlistu mne nenapadlo. Pokud jde o něco jiného, tak o to?

[next]

MPD = music playing daemon. Ma adresar, skade berie hudbu. Ma TCP port, na ktorom prijima prikazy od klientov, co ma hrat. Ja som tvrdil, ze vyuzivam viacnasobny pristup (z roznych workstation) k jednemu daemonu na jednom serveri. Ten daemon je, samozrejme, spokojny aj s jednym jedinym klientom..

[trocha pravdy]

Proc jsou klikaci nastroje jen pro BFU? Ja se za BFU nepovazuju a presto jsem dost casto (vlastne skoro porad) v nejakem klikacim prostredi a vubec mi to nevadi.

[rastos]

neznalého užívateľa dovedú vetviacou sa štruktúrou relatívne jednoduchou cestou k cieľu.

Asi hej. Ale tá filozofia má jeden zádrhel. Čo keď chceš porovnať dve konfigurácie? Čo keď chceš konfiguráciu preniesť od užívateľa A k užívateľovi B. Zo stroja X na stroj Y.

To sa samozrejme rieši tým, že klikátko je len GUI nad texťákom. Problém je, že napísať klikátko, ktoré zachová poradie, zachová komentáre, prípadne pridá vlastné rozsiahle komentáre, nie je zrovna triviálne.

[Josef Kufner]

Kdysi jsem si napsal takové klikátko na přepínání audiovýstupu mplayeru. Mám to jako několik položek v root menu window manageru. Každá ta položka vypadá nějak takto:

sed '/^ao=/s/=.*$/=alsa/' -i ~/.mplayer/config

prostě to jen nahradi hodnotu v jednom paramteru a na zbytek to nesaha. Ale to neznamena ze bych nesouhlasil