Komiks xkcd 797: DEBIAN-MAIN

27. 12. 2010 | Redakce | Různé | 9801×

XKCD česky.

DEBIAN-MAIN

← xkcd 548: Kindle | originál: http://xkcd.com/797/

Překlady xkcd vycházejí se svolením původního autora. © Randall Munroe.
Překlad: Robert Krátký, písmo: Martin Stiborský

Uvedená práce (dílo) podléhá licenci Creative Commons Uveďte autora-Neužívejte dílo komerčně 2.5

       

Komentáře

[Mercuriuz]

No....radši kobylky než mono

[2X4B-523P]

lepší mono než half-stereo

[jnd]

Lepší je joint-stereo ;)

[Petr Tomášek]

lepší je joint

[frEon]

2 jointy (a s 5+1 na me nechodte, to bych po obede nedal)

[heh]

Debian začíná být Monem prolezlý.

[Aleš Kapica]

Fakt? Nepleteš si to tak náhodou s gnome?

[heh]

A co používá Debian v instalačních scénářích typu "desktop" ? Mono. Stejně jako Ubuntu, které už dávno personálně i ideologicky infiltrovalo Debian. Mono v Debianu rozhodně není bezvýznamný projekt a řady podporovatelů. (link)

S gnome si to určitě nepletu. RedHat/Fedora mají v Gnome největší zastoupení ze všech distribucí a mono téměř ignorují. Fedora gnome instalace mono neobsahuje.

[Mrkva]

A co je na tom monu špatného, krom toho, že stereo je lepší?

[M___]

Protože nějak čtyři generace zpátky má za dědečka Microsoft.

[HonzaRez]

Asi proto, že to tak chtěl Bene Geserit. Je to plán v plánech jiných plánů...

[heh]

1) legální stránka věci je přinejmenším dost nejistá

2) mono je klon Microsoft .NET. Není to .NET like technologie, která se volně rozvíjí podle aktuálích potřeb a nejlepších nápadů. Je to kopie, která bude vždy pozadu.

Implementace mono, pominu-li legální část problému, sama o sobě špatná není, stejně jako třeba Wine. Jenže pro Wine nikdo nepíše Linuxové aplikace, protože by vypadal jak idiot. Mono by mělo být .NET frameworkem pro Linux pro provozování .NET aplikací (když už není jiná možnost). Místo toho tady někdo dělá z mono platformu pro vývoj nových aplikací.

[kei.101]

Úplně přesně. A možná proto pro něj programují Ubuntisti - převlečení windowsáci :)

[hroch]

ze pro wine nepisou aplikace ? :D ale to byste se divil. Mnoho propietarniho softwaru je preportovano proste tak, ze se k tomu prilinkuji soucasti wine a nejak to funguje

[Rivon]

Předpokládám, že původní příspěvek byl zamýšlen v tom smyslu, že nikdo neprogramuje čistě linuxové aplikace jako Windowsí aplikace fungující we Wine.

[pavlix]

ředpokládám, že původní příspěvek byl zamýšlen v tom smyslu, že nikdo neprogramuje čistě linuxové aplikace jako Windowsí aplikace fungující we Wine.

Potom se nabízí otázka, proč byl původní příspěvek napsán jinak než byl myšlen.

Já se spíš přikláním k vysvětlení, že původní příspěvek byl pouze výkřikem člověka nesnášejícího cokoli, co má něco vzdáleně společného s Microsoftem.

Chápu, že někdo nemá Microsoft rád. Většina jejich vlastních uživatelů je nemá ráda. Ale samotný nápad vyvíjet multiplatformí aplikaci pro Winapi s použitím winelib nebo aspoň wine, mi nepřijde tak špatný v kontextu firem, které nemají s jinými platformami zkušenosti.

[Honza]

Hm, ja treba ten prispevek pochopil...

[pavlix]

Já taky :).

[Ash]

>> pro Wine nikdo nepíše Linuxové aplikace, protože

>nápad vyvíjet multiplatformí aplikaci pro

Co multiplatformní, jak multiplatformní, kde multiplatformní, řeč byla o linuxových aplikacích, nikde nevidím slovo multiplatformní, tak co sem taháte :) Řeč byla imho o linuxových aplikacích (ne o multiplatformních aplikacích fungující i v linuxu).

[pavlix]

Jsem zvědavý, jak definuješ pojem linuxová aplikace. Jestli aplikace, která nefunguje nikde jinde než na linuxu, kde funguje... tak takových znám opravdu velmi málo a těžko podezřívat heha z toho, že myslel těchto pár čistě linuxových aplikací.

Řeč byla imho o linuxových aplikacích (ne o multiplatformních aplikacích fungující i v linuxu).

Hádal bych, že to v závorce je většinovou podmnožinou toho před závorkou.

[Ash]

Pokud mi někdo dá za úkol napsat linuxovou aplikaci, tak se přenositelností na Windows opravdu netrápím a wine k tomu nepoužiji :) Asi jsou divnej.

Samozřejmě mnoho existujících aplikací které fungují také v linuxu lze s přivřením očí označit za linuxové ve smyslu "fungují i v linuxu", ale imho o těchto hehe nehovořil.

[pavlix]

Já jsem měl podezření, že sám neví, o čem hovoří :). Dejme tomu, že máš v určitym smyslu pravdu. Pokud bude zadáním "aplikace pro linux", asi bude většina z nás volit to nejednodušší řešeší, které známe, a nebude to ani wine, ani mono.

Ale dokážu si představit i lidi, kteří nejlíp znají dotnet, případně nějakou nadstavbu winapi a bude se řídit víc vlastními zkušenostmi než tom, co je na dané platformě opravdu doma. A nemůžu říct, že by mi to přišlo za všech okolností jako špatný nápad. To je v podstatě všechno, co jsem tím chtěl sdělit :).

[pavlix]

Jenže pro Wine nikdo nepíše Linuxové aplikace, protože by vypadal jak idiot.

Autorů aplikací pro wine jako alternativní implementaci windows je myslím víc než dost (minimálně vím o Mikrotiku) a za idioty je rozhodně nepovažuju! Spíš naopak.

Mono by mělo být .NET frameworkem pro Linux pro provozování .NET aplikací (když už není jiná možnost).

Máš snad pocit, že bys o tom měl rozhodovat zrovna ty?

[Ash]

Máš snad pocit, že bys o tom měl rozhodovat zrovna ty?

Proč by o tom měl rozhodovat? Myslím že o tohle tu asi opravdu nejde :)

[heh]

Autorů aplikací pro wine jako alternativní implementaci windows je myslím víc než dost (minimálně vím o Mikrotiku) a za idioty je rozhodně nepovažuju! Spíš naopak.

Já ano. Už jen kvůli WinBoxu jsem si nikdy žádný Routerboard nekoupil.

Máš snad pocit, že bys o tom měl rozhodovat zrovna ty?

Mám pocit, že mám právo udělat si na tuto problematiku vlastní názor. A Zjevně nejsem sám.

[xHire]

Autorů aplikací pro wine jako alternativní implementaci windows je myslím víc než dost (minimálně vím o Mikrotiku) a za idioty je rozhodně nepovažuju! Spíš naopak.

Já ano. Už jen kvůli WinBoxu jsem si nikdy žádný Routerboard nekoupil.

Tak zrovna RB jde spravovat přes SSH, takže to není takový problém (osobně WinBox nepoužívám, protože existuje pouze 32bitová verze, kterou u sebe prostě nerozjedu).

[pavlix]

Já ano. Už jen kvůli WinBoxu jsem si nikdy žádný Routerboard nekoupil.

Mně doma perfektně slouží jedeno Routerboard 150 s OpenWRT, žádný winbox na to potřeba není.

Na síti, kterou spoluspravuju, se používají Routerboardy s RouterOS. Na to se winbox použít dá, ale SSH konzolku mají perfektně zvládnutou.

Jestli mi na RouterOS něco vadí, určitě to nebude možnost použití winboxu.

Mám pocit, že mám právo udělat si na tuto problematiku vlastní názor. A Zjevně nejsem sám.

To zjevně nejsi, i my ostatní máme nějaký vlastní názor.

[pavlix]

Ještě k tomu názoru, ono je hezké mít na věci názor, ale lidi zřejmě i nadále budou používat, co uznají za vhodné, a neřekl bych, že má Mono tak přesně vymezený účel, jak říkáš.

Dokonce na to, na co se podle tebe nehodí, podle mě funguje líp jak na to, na co bys ho použil ty.

[Petr Dlouhý]

Wine se snaží o bug-to-bug kompatibilitu s Windows, proto také jeho vývoj probíhá tak pomalu, a mnoho aplikací stále nefunguje (i když jde často o drobné chybky, nebo často nepřítomnosti chybek).

Nezbývá než doufat, že Mono neskončí stejně.

[kyytaM]

Mna to tiez vytaca, ale staci nahradit Tomboy Gnote a nejaky ten rdp manager Remminou a je po probleme. Praca na cca 2 min?

[heh]

Právě to mě na tom zaráží nejvíce. Zahrnutí mono je zcela zbytečné. K filozofii Debianu, který pro příští vydání vyhazuje i nesvobodný firmware mi to prostě vůbec nesedí.

[Aleš Kapica]

Co furt máš s tím Debianem? Používám všude na všechno jenom Debian unstable a nikde nainstalované žádné mono knihovny nemám, protože aplikace které ho používají prostě neinstaluji. A nemám pocit že by mi zrovna nějaká aplikace chyběla.

[Jakub Lucký]

No, v defaultu (netinst desktop-environment) to Mono nainstaluje... Je to asi 3 týdny, co se mi to takhle stalo...

[Jendа]

To je divné, když řeknu, že bych si přál gnome-desktop-environment, plánuje to nainstalovat hromadu balíčků, ale mono mezi nimi není. A to ani na Lennym, ani na Sidovi. Že by tasksel instaloval při volbě desktopového prostředí ještě něco navíc?

[SPM]

Asi stejně chytré, jako když při volbě základní systém to nainstaluje exim :)

[Jiří J.]

Ten to tam dokonce vrazí i bez "base system". Místo věcí jako ping a less!

Naštěstí (zatím) je debian schopen fungovat bez MTA po odinstalaci eximu.

[Jendа]

Chybějící less mě také udivil. A v Ubuntu zase defaultně není tree. tree! Jak někdo může žít bez tree?!

[Ash]

On někdo používá tree :-O?

[pavlix]

Pravda, já běžně používám find, tree jsem ani nevěděl, že existuje.

[kralyk z abclinuxu]

+1

[Jendа]

No jistě.

[Jakub Lucký]

Já občas... Když chci někomu poslat strukturu složek (třeba kvůli tomu, jakou mám hudbu)

Ale dneska už mi domů vede FTP, tak to není tak potřebné...

[Ash]

Pravda, jednou jsem vlastně tree také použil pro strukturu dvd do diplomky.

[frEon]

Ja bych ho obcas k necemu i pouzil, kdybych nezapomel ze nejakej tree vubec existuje

[imploder]

Jo, to je nevýhoda příkazového řádku: příkazy tiše čekají ve tmě terminálu a nedají o sobě vědět jako u GUI.

[frEon]

nastesti se zase v radce clovek bez neceho takoveho obejde a naskriptuje si to hrave sam. s pouhym gui by byl clovek v pr...

[imploder]

No, to jo, GUI je v možnostech skriptování zaostalé. Výhoda je v tom, že je prostě vidět, dá se používat stylem "kouknu a vidím", protože při pohledu na GUI něco vidím, zatímco při pohledu na terminál vidím kulový a i primitivní věci si musím nastudovat z manuálu

[Gilhad]

apropos dir| grep tree

pokud aspon tusis co hledas ...

[Ash]

Zajímavé, když to má teoreticky fungovat "kouknu a vidim", jak se pak asi rodí všechny ty dotazy "kde/jak nastavím" a "dá se to někde naklikat" a "tady ta volba ve verzi XY byla, ale teď ji nemohu najít" :)

[imploder]

Samozřejmě jenom do určitého stupně složitosti, se složitým GUI je taky potřeba se naučit zacházet a bez dokumentace to nejde. Příkazový řádek ale není v tomhle o nic lepší. Změnit se můžou obě rozhraní.

Kromě toho, že je vidět, nabízí GUI i víceméně standardní ovládací prvky v podobě oken, dialogů, menu, tlačítek a jiných widgetů. Používají se v různých aplikacích velice podobným způsobem a uživatel když je uvidí, tak ví, jak je používat i bez čtení manuálu - prostě je už zná. Co podobného standardního nabízí CLI? Způsob předávání parametrů, přepínače, readline; nic jiného mě nenapadá. Pokud je nějaký konzolový program interaktivní, tak si věci dělá po svém. Textové konfiguráky: každý svou vlastní syntaxi - neefektivní, bordel. Zato GUI dialog se ovládá standardním způsobem, který většinou není potřeba měnit.

V GUI není potřeba se pro každý program učit kompletně nový "jazyk", kterým se ovládá. Stačí naučit se ty části, které jsou speciální konkrétně pro něj, základ je společný. Abstrakce uživatelského rozhraní v moderním GUI je prostě vysokoúrovňovější (používám už předpřipravené vysoce abstraktní prvky rozhraní) než u CLI (mám k dispozici předpřipravené jenom hodně základní prvky jako parametry programu, stdin, stdout a nad tím si bastlím kompletně vlastní abstrakce).

[pavlix]

Jednoduchý shell jde taky ovládat zcela intuitivně, viz v některých funkce otazníku, v jiných tabulátoru.

Hierarchii akcí (menu) sice dneska většina lidí zná z GUI, ale v shellu se dá implementovat úplně stejně dobře. Teď nemám namysli bash a nainstalované příkazy, ale opravdu uživatelsky dobře udělaný shell.

Vtip je v tom, že do uživatelsky přívětivého shellu se dají velmi jednoduše přidat možnosti skriptování.

Kromě toho, že je vidět, nabízí GUI i víceméně standardní ovládací prvky v podobě oken, dialogů, menu, tlačítek a jiných widgetů.

Které se člověk musel naučit používat. Učil jsi někdy někoho pracovat s GUI, kdo to neuměl?

Co podobného standardního nabízí CLI?

V podstatě úplně to samé, viz výše. Stejně jako u GUI, tak u CLI ty standardy nejsou všeobecné. Ale mimo unix shell je například ? (otazník) velmi rozšíření nástroj na používání hierarchického CLI. Menu jako menu :).

Textové konfiguráky: každý svou vlastní syntaxi - neefektivní, bordel.

Odhlédněme od toho, že na efektivitu mám opačný nástroj. Textové soubory se používají v kombinaci s GUI, TUI, CLI i textovými editory. Jmenuj binární formát, který je takhle flexibilní. A jmenuj důvod, proč pleteš formát konfigurace do diskuze GUI vs CLI.

GUI dialog se ovládá standardním způsobem, který většinou není potřeba měnit.

To není tak úplně pravda, UI se mění i standardy ovládání se mění, a to jak u GUI, tak u CLI.

V GUI není potřeba se pro každý program učit kompletně nový "jazyk", kterým se ovládá.

V dobrém CLI zpočátku také ne. Ale pro pokročilou práci se nový "jazyk" musíš naučit jak v GUI, tak v CLI.

Stačí naučit se ty části, které jsou speciální konkrétně pro něj, základ je společný.

Tento předpokad v praxi nefunguje. V teorii by šel stejně dobře aplikovat na CLI.

Abstrakce uživatelského rozhraní v moderním GUI je prostě vysokoúrovňovější (používám už předpřipravené vysoce abstraktní prvky rozhraní) než u CLI (mám k dispozici předpřipravené jenom hodně základní prvky jako parametry programu, stdin, stdout a nad tím si bastlím kompletně vlastní abstrakce).

Unixovský šel není zdaleka příklad nejlépe navrženého či dotaženého CLI. Specializované nástroje jsou na tom obvykle mnohem lépe.

[imploder]

Hierarchii akcí (menu) sice dneska většina lidí zná z GUI, ale v shellu se dá implementovat úplně stejně dobře. Teď nemám namysli bash a nainstalované příkazy, ale opravdu uživatelsky dobře udělaný shell.

Pokud jde o jednoduché věci jako že se vypíše několik možností a otázka kterou vybrat, tak jo. Pokud jde o složitější věci, tak tam CLI nemá takové prostředky - např. posuvník: ano, jde to udělat tak, že se mi dole bude ukazovat, co mám zmáčknout a jak se přepínat mezi posouváním a zadáváním příkazů, ale nebude to okamžitě pochopitelné bez vysvětlování jako posuvník v GUI (ten prostě uvidím a hned vím, jak na to - je to prostě standardní, univerzálně použitelný prvek).

Učil jsi někdy někoho pracovat s GUI, kdo to neuměl?

Jo a souhlasím s tím, že i GUI se samozřejmě musí člověk naučit používat. Rozdíl ale je v tom, jak znovupoužitelné ty znalosti jsou: u GUI si do nové aplikace uživatel přináší minimálně znalost jednotlivých widgetů, v CLI ale nic takového není. U CLI si uživatel do nové aplikace přináší znalosti práce se std vstupem a výstupem, obvyklou syntaxi spouštění (program přepínače soubor) atd. - pokud je to něco interaktivního, tak mu to nepomůže.

Odhlédněme od toho, že na efektivitu mám opačný nástroj. Textové soubory se používají v kombinaci s GUI, TUI, CLI i textovými editory. Jmenuj binární formát, který je takhle flexibilní. A jmenuj důvod, proč pleteš formát konfigurace do diskuze GUI vs CLI.

Mluvím tady o případu a) konfigurace přímou úpravou textových souborů (jak je to tradiční v unixech) vs b) konfigurace pomocí k tomu určeného nástroje (jak je to tradiční v GUI - dialogové okno). Při upravování textových konfiguráků obyčejným editorem je na uživateli zjišťovat, co tam má napsat a hlídat, aby tam nenapsal něco špatného. GUI dialog, pokud je dobře udělaný, mi nabídne ty správné možnosti a nedovolí udělat změnu, která by uvedla konfiguraci do nedefinovaného stavu (minimálně mě odstíní od syntaxe, takže nemůže nastat syntaktická chyba).

Jde mi především o to, jakým způsobem se s konfigurací pracuje, formát samotného konfiguráku v téhle úvaze není až tak důležitý. Ale myslím, že to spolu souvisí, takže tady je, co si o tom myslím:

Co vlastně dělám, když používám na ukládání datových struktur (jiných než prostý text) textový soubor? Je to něco jako když při programování v C místo odpovídajících datových struktur vezmu blok paměti bez typu (void*), i když tam ve skutečnosti je nějaká jasně definovaná datová struktura - to je přece v době typovaných jazyků prasárna, správně by měl mít ten kus dat odpovídající datový typ a ne nicneříkající void. Textový soubor je přesně tohle: netypovaný kus dat. A do toho nacpu nějakou datovou strukturu (u konfiguráku obvykle aspoň tabulku záznamů (název, hodnota)). Každý, kdo chce ty data používat, si musí naprogramovat serializaci (tj. převod z TMujKonfigurak na char[]) a deserializaci (tj. převod z char[] na TMujKonfigurak). Nebezpečná a pracná věc - v principu jak ten void.

Teoreticky by bylo IMHO správné používat na uložení dat struktury k tomu určené (např. hash tabulku, seznam, strom). Ale v praxi je žádoucí, aby si různé programy mezi sebou rozuměly, takže se radši všechno nějak nacpe do jednoho primitivního formátu (prostý text) a ono se to pak dá vždycky nějak slepit tak, že to funguje. Jedině na tomhle nízkoúrovňovém formátu se všichni shodnou. Prostý text je v tomhle smyslu hodně flexibilní, proto se taky používá. Jinak je jeho flexibilnost relativní, pravda je taky, že:

• text nic neříká o tom, co je jeho obsahem, musí na něm být postavený další formát (aneb není flexibilnější formát než ten, který vůbec nic nedefinuje)
• i když se do něj dá nějak nacpat cokoliv, jsou typy dat, pro které je velice nevhodný, např. jakýkoliv větší soubor, do kterého je potřeba vkládat data jinam než na konec

Stačí naučit se ty části, které jsou speciální konkrétně pro něj, základ je společný.

Tento předpokad v praxi nefunguje. V teorii by šel stejně dobře aplikovat na CLI.

Tomu i docela věřím, IMHO hodně z toho, jaké vlastnosti ty rozhraní v praxi mají, je z historických důvodů, že to tak prostě někdo vymyslel, ne proto, že by to tak muselo nutně být. Např. není mi moc jasné, proč by GUI sestávající ze standardních prvků (tlačítka, menu, checkboxy, textové pole, atd.) nemohlo mít stejné možnosti skriptování jako CLI nebo dokonce lepší (akorát by to chtělo objektový shell, ne textový).

Unixovský šel není zdaleka příklad nejlépe navrženého či dotaženého CLI. Specializované nástroje jsou na tom obvykle mnohem lépe.

Nic lepšího než Unixovský shell neznám, může být. Shell v DOSu/Windows je ale ještě o řád horší.

[pavlix]

ale nebude to okamžitě pochopitelné bez vysvětlování jako posuvník v GUI (ten prostě uvidím a hned vím, jak na to

Už jsem se ptal, jestli jsi někdy učil s počítače úplného začátečníka starší generace, který k počítači ještě přístup neměl :).

Mluvím tady o případu a) konfigurace přímou úpravou textových souborů (jak je to tradiční v unixech)

Není dobré příliš měnit téma v průběhu diskuze.

Je to něco jako když při programování v C místo odpovídajících datových struktur vezmu blok paměti bez typu (void*)

Nepovedené přirovnání.

Každý, kdo chce ty data používat, si musí naprogramovat serializaci (tj. převod z TMujKonfigurak na char[]) a deserializaci

Toto tvé tvrzení podle mě zcela odporuje praxi.

Prostý text je v tomhle smyslu hodně flexibilní, proto se taky používá. Jinak je jeho flexibilnost relativní, pravda je taky, že:

Prostý text se taky nepoužívá ani tak kvůli počítači, jako kvůli srozumitelné konfiguraci pro člověka. Konfiguráky v prostém textu se velmi dobře spravují, protože do nich lze velmi pohodlně zasáhnout přímo. Pokud navíc mají šikovný formát, jdou ovládat i programem.

Výhody i nevýhody jsou známé, ani jedny by se neměly ignorovat.

i když se do něj dá nějak nacpat cokoliv, jsou typy dat, pro které je velice nevhodný, např. jakýkoliv větší soubor, do kterého je potřeba vkládat data jinam než na konec

Konfigurační soubory obvykle větší nebývají a pokud by měly být (například databáze tisícovek uživatelů), obvykle se nahrazují něčím jiným (nebo v nejhorším aspoň rozdělují).

Např. není mi moc jasné, proč by GUI sestávající ze standardních prvků (tlačítka, menu, checkboxy, textové pole, atd.) nemohlo mít stejné možnosti skriptování jako CLI nebo dokonce lepší (akorát by to chtělo objektový shell, ne textový)

.

Není mi moc jasné, jak by se takového výsledku mělo dosáhnout. Nahráváním akcí kliknutí myší a jejich opakováním?

Pokud je výsledkem skript, tak ten skript je z principu volání nějakých akcí... tedy pokud se ty akce napíšou po řádcích, vzniká CLI, protože volání akcí jsou příkazy, které se nějak jmenují a dávají se jim nějaké parametry.

Unixovský šel není zdaleka příklad nejlépe navrženého či dotaženého CLI. Specializované nástroje jsou na tom obvykle mnohem lépe.

Neříkám, že není co zlepšovat, ale unixový shell rozhodně není jednotný ani samopopisný. Z těch speciálních se zkus podívat třeba na Mikrotik RouterOS, kde je určitě taky co zlepšovat, ale už je to jiné kafe. Tam když budeš znát všechny základní pojmy, tak se můžeš pohybovat bez pamatování si všech příkazů, které potřebuješ.

Já neříkám, že bych chtěl unixovský shell něčím takovým nahrazovat. Šlo mi jen o to, že existují i daleko ergonomičtější CLI, která s ergonomií GUI srovnání snesou.

[frEon]

ale nebude to okamžitě pochopitelné bez vysvětlování jako posuvník v GUI (ten prostě uvidím a hned vím, jak na to

Už jsem se ptal, jestli jsi někdy učil s počítače úplného začátečníka starší generace, který k počítači ještě přístup neměl :).

imho tim chtel imploder rict, ze posuvnik v kazdem programu vypada a chova se stejne, tudiz znas-li ho jednou, znas ho vsude a vzdy. V cli, standartni posuvnik neni, kazdy program si to resi trochu jinak (pokud ho vubec ma, jako treba vim)

[imploder]

Přesně tak. Jsem rád, že to někdo pochopil.

[pavlix]

imho tim chtel imploder rict, ze posuvnik v kazdem programu vypada a chova se stejne

IMHO netřeba jeho větu interpretovat, je srozumitelná.

V cli, standartni posuvnik neni, kazdy program si to resi trochu jinak (pokud ho vubec ma, jako treba vim)

Standardní posuvník v CLI je page up a page down, případně ještě šipky. Že to nefunguje všude je jiná věc, ani v GUI to není stoprocentní, ale ten běžný standard tu existuje.

[imploder]

Už jsem se ptal, jestli jsi někdy učil s počítače úplného začátečníka starší generace, který k počítači ještě přístup neměl :).

Učil. A problém byl na začátku např. i v obyčejném kliknutí - tj. zmáčknout a pustit tlačítko myši na jednom místě, bez posunutí. Vím, že jsou lidi, kteří mají s chápáním pro nás běžných věcí problémy. Ti se holt musí naučit s počítačem záchazet, i u GUI - to nijak nepopírám. Na co upozorňuju je rozdíl "naučit se jednou a používat všude" (posouvání v GUI) a "učit se pokaždé znovu" (posouvání v CLI). FrEon to pochopil správně [->#].

Změna tématu... pravda, nedržel jsem se striktně diskuze "CLI vs GUI". Nakousl jsem obecnější diskuzi "text vs něco jiného", protože CLI je založené na tom, že se všechno ovládá prostým textem a konkrétně v UNIXu je zvyk všechno, co jde (a veškerou konfiguraci) ukládat jako prostý text a editovat textovým editorem (ne GUI nástrojem). Tohle je IMHO jedna z věcí, která typickou GUI aplikaci a typickou CLI aplikaci odlišuje. Z hlediska uživatele. Máš pravdu, že i pro GUI aplikace se často používají přímo čitelné a editovatelné textové konfiguráky a i CLI aplikace může mít binární konfiguráky (musí ale v tom případě poskytovat nástroj, jak s ním pracovat - např. gconf v GNOME).

Je to něco jako když při programování v C místo odpovídajících datových struktur vezmu blok paměti bez typu (void*)

Nepovedené přirovnání.

Proč? Obojí je netypované, takže interpretaci dat si musím naprogramovat sám a můžu to udělat úplně jakkoliv. Pracovat tímto způsobem s pamětí se považuje za špatný nápad (ve vyšších jazycích; assembler nepočítám, v tom se taky žádný složitější program nemá dělat). Zásadní rozdíl v tom je, to uznávám: v konfiguráku na disku se možná bude potřebovat hrabat uživatel nebo jiný program sám, takže je vhodné se na tuhle "primitivní" úroveň snížit, aby si s tím rozuměl; zatímco struktury v paměti přímo nikdo jiný používat nebude.

Každý, kdo chce ty data používat, si musí naprogramovat serializaci (tj. převod z TMujKonfigurak na char[]) a deserializaci

Toto tvé tvrzení podle mě zcela odporuje praxi.

Narážíš možná na to, že na práci s daty v praxi často jiný program nepotřebuje jim kompletně rozumět a může si tak text rozparsovat nějak jednodušeji. To je pravda. Udělat takové zjednodušené parsování tak, aby fungovalo pro všechny validní vstupy, ale někdy není sranda.

Není mi moc jasné, jak by se takového výsledku mělo dosáhnout. Nahráváním akcí kliknutí myší a jejich opakováním?

Chtěl bych tím dosáhnout toho samého, čeho u CLI dosáhnu psaním skriptů. Prostě aby šlo funkce programu jednoduše využívat automaticky, jiným programem. Jako to jde u CLI.

Pokud je výsledkem skript, tak ten skript je z principu volání nějakých akcí... tedy pokud se ty akce napíšou po řádcích, vzniká CLI, protože volání akcí jsou příkazy, které se nějak jmenují a dávají se jim nějaké parametry.

IMHO v principu není rozdíl mezi zadáním příkazu "proveď" v příkazovém řádku a zmáčknutím tlačítka "proveď" v GUI. Na checkboxy, comboboxy, radiobuttony, textová pole a jiná nastavovátka v dialogovém okně se dá dívat jako na parametry. Atd.. GUI, stejně jako CLI, je rozhraní k volání nějakých akcí.

Na RouterOS se někdy podívám, v něčem tak "systémáckém" by mě kvalitní UI nenapadlo hledat.

[pavlix]

Nakousl jsem obecnější diskuzi "text vs něco jiného", protože CLI je založené na tom, že se všechno ovládá prostým textem a konkrétně v UNIXu je zvyk všechno, co jde (a veškerou konfiguraci) ukládat jako prostý text a editovat textovým editorem (ne GUI nástrojem)

Zajímavé, že v posledních deseti letech je tento zvyk většinou uživatelů porušován. Nehledě na to, že textový konfigurační soubor není obecnější pojem k ovládání pomocí CLI.

Narážíš možná na to, že na práci s daty v praxi často jiný program nepotřebuje jim kompletně rozumět a může si tak text rozparsovat nějak jednodušeji.

Ale vůbec ne.

Chtěl bych tím dosáhnout toho samého, čeho u CLI dosáhnu psaním skriptů. Prostě aby šlo funkce programu jednoduše využívat automaticky, jiným programem. Jako to jde u CLI.

Prosím nepleť si otázku "čeho dosáhnout" s otázkou "jak toho dosáhnout".

IMHO v principu není rozdíl mezi zadáním příkazu "proveď" v příkazovém řádku a zmáčknutím tlačítka "proveď" v GUI. Na checkboxy, comboboxy, radiobuttony, textová pole a jiná nastavovátka v dialogovém okně se dá dívat jako na parametry. Atd.. GUI, stejně jako CLI, je rozhraní k volání nějakých akcí.

S tím plně souhlasím, jen nevidím, jak bys řešil tu automatizaci ekvivalentně CLI. Tedy akce bez přítomnosti uživatele.

Na RouterOS se někdy podívám, v něčem tak "systémáckém" by mě kvalitní UI nenapadlo hledat.

RouterOS nemá dokonalé CLI, to chci předem upozornit, ale určitě se podívej, tuším, že by mělo jít i nějaké testovací po internetu, zkus pohledat po jejich stránkách.

Mezi náma, většina uživatelů (správců) RouterOS dává přednost GUI. Ale i tam se ukazuje, že GUI neumí zdaleka to, co CLI. Dlouhodobí správci potřebují skripty, to bez příkazů neumí ani Mikrotik.

Ale když si odmyslíš myš, tak je CLI v RouterOS i v interaktivním režimu (po SSH) schopnější než Winbox (GUI pro windows nebo linux+x11+wine).

GUI je velice složité na tvorbu a vymezení všech možností použití. Není například problém z jakékoli databáze generovat skripty pro RouterOS (stačí předat pomocí SSH).

Ale generovat z databáze posloupnost pohybů v okně a kliknutí do GUI bych opravdu nechtěl.

Pak jsou tu nedokonalosti GUI (na RouterOS se v GUI špatně pracuje se stovkami záznamů, například přesuny jsou nepohodlné, když je to o několik "obrazovek"). To jsou věci sice řešitelné, ale v CLI to funguje automaticky a problém vůbec nevzniká (do příkazové řádky napíšu "posuň 1035 před 26", zatímco vedle si scrolluju mezi 1035 a 26). Ale uznávám, zde je to hlavně chyba nedotaženého GUI, které nemá žádný nástroj na pohodlný přesun o ~1000 řádků, zatímco CLI má nástroj obecný.

[M___]

S tím plně souhlasím, jen nevidím, jak bys řešil tu automatizaci ekvivalentně CLI. Tedy akce bez přítomnosti uživatele.

Myslím, že snažit se používat GUI ze skriptů je kravina. GUI je prostředí pro člověka, ne pro počítač.

Hafo programů se normálně spustí s GUI, ale dají se používat i ze skriptů (a neskriptují se stylem táámhle klikni na tlačítko a táámhle posuň šoupátkem, ale úplně normálně přes CLI).

[pavlix]

Myslím, že snažit se používat GUI ze skriptů je kravina. GUI je prostředí pro člověka, ne pro počítač.

Zatím to chápu tak, že imploder si myslí opak.

Hafo programů se normálně spustí s GUI, ale dají se používat i ze skriptů (a neskriptují se stylem táámhle klikni na tlačítko a táámhle posuň šoupátkem, ale úplně normálně přes CLI).

Asi bych tu větu řekl trochu jinak, ale v zásadě souhlasím :).

[imploder]

Myslím, že snažit se používat GUI ze skriptů je kravina. GUI je prostředí pro člověka, ne pro počítač.

No a já si myslím, že tohle je jenom pohled na věc, ne prostý fakt. GUI i CLI jsou rozhraní pro ovládání počítače. Nevidím v principu důvod, proč by GUI taky nemohlo být snadno ovladatelné pro člověka i pro počítač, jako je tomu u CLI.

CLI vzniklo jako rozhraní pro programátory, požadavek na automatizaci byl samozřejmý, takže teď máme CLI snadno ovladatelné počítačem (skriptovatelné).

GUI vznikalo jako rozhraní pro lidi a zvlášť pro BFU. Nějaká automatizace a snadnost skriptování byly až na x-tém místě, místo toho se řešily věci jako jestli ikonky mají být malé nebo velké a podobně (ne že by to nebylo taky důležité - nikdo nechce hnusné zmatené UI). Prostě se s tím nepočítalo a tak teď máme GUI, které sice běží na plně automatickém stroji (počítači), ale vyžaduje neustále opici, aby ho ovládala (bez ohledu na to, jestli úloha v tom GUI dělaná se dá jednoduše automatizovat).

Hafo programů se normálně spustí s GUI, ale dají se používat i ze skriptů

To je pravda, je to takový kompromis: nabízet stejné funkce zárověň v GUI i v CLI. Podle mě ale tohle není ideální řešení.

Je potřeba UI dělat dvakrát a udržovat obě verze. Obvykle to vypadá tak, že něco jde jenom v GUI nebo něco jenom v CLI (nevybavuju si teď žádný složitější program, který by měl úplně stejné funkce dostupné v GUI i v CLI; některé ani v tom druhém nedávají smysl). Je potřeba se učit 2 různé způsoby ovládání (a pak si uživatel zvyklý na GUI prostě nic nenaskriptuje, protože by se musel učit CLI způsob ovládání toho samého programu a to mu nestojí za to; taky to, co potřebuje udělat a věděl by, jak to automatizovat v GUI, nemusí v CLI verzi vůbec jít).

Takže jo, zpřístupnit funkcionalitu nějakým způsobem i v CLI je možná cesta a v Linuxu se to tak u GUI aplikací často dělá. Podle mě by ale bylo o hodně lepší, kdyby šlo oba druhy rozhraní skriptovat přímo. Pak by nebyl takový problém zaměřit se jenom na GUI. BFU by si dál klikal, guru by si napsal skript a všichni by byli spokojení

[pavlix]

Takže jo, zpřístupnit funkcionalitu nějakým způsobem i v CLI je možná cesta a v Linuxu se to tak u GUI aplikací často dělá.

Toto považuju za ideální cestu.

Podle mě by ale bylo o hodně lepší, kdyby šlo oba druhy rozhraní skriptovat přímo.

Zkus dohledat etymologii slova skript a poznáš.

[imploder]

Toto považuju za ideální cestu.

Já ne, protože to vede k duplikování rozhraní jenom proto, aby ho šlo automaticky ovládat. Co je špatného na myšlence jednoho rozhraní na jednu aplikaci? Dokud bylo jenom CLI, tak tenhle problém neexistoval.

Zkus dohledat etymologii slova skript a poznáš.

Co z toho mám vyčíst? Že to mimo jiné znamená "písmo" a že když se něco doslova nepíše, tak to není skript? O blbosti se hádat nebudu.

[M___]

Myslím, že takové MS Office na to jde docela dobře. Makro lze naklikat (zvládne kde kdo), nebo nabušit ve VBA přímo (zvládne pokročilejší). Navíc přes OLE a nevím jaké technologie lze Office ovládat i z jiných aplikací.

(Prosím nechme stranou makroviry, případnou zášť vůči MS, kritiku konkrétní implementace a podobně, bavme se věcně a spíše v obecné rovině.)

[imploder]

I když ve VBA vůbec neumím, tak myslím, že je to něco podobného. Je podle mě hodně důležité to "i z jiných aplikací" a aby existovalo nějaké standardní univerzálně použitelné řešení (tak, jako standardně každá CLI aplikace má parametry, vstup a výstup).

[pavlix]

Makro lze naklikat

Jo, pomůcky pro tvorbu maker nejsou zlé.

[imploder]

Zajímavé, že v posledních deseti letech je tento zvyk většinou uživatelů porušován.

Je to tak, v poslední době se to různě míchá, hodně programů je taky multiplatformních atd.. Ale "hardcore" přístup - ten, který je danému systému tradičně nejbližší - jsou pokud vím v unixových systémech textové konfiguráky a úprava editorem, ve Windows pak GUI a specializované úložiště (registry). Tak, jak je to v těch systémech řešené, mi rozhodně připadá lepší unixový přístup s tím, že GUI se dodělá, když je potřeba. Jedna z věcí, co mám rád na Linuxu - průhlednost, široké použití jednoduchých obecných nástrojů (i když je to "jenom" text)

Ale generovat z databáze posloupnost pohybů v okně a kliknutí do GUI bych opravdu nechtěl.

Tady je asi kámen úrazu. Generovat pohyby myší a kliknutí - to je špatná úroveň abstrakce. Na to se dá použít např. xdotool, to jsem opravdu nemyslel a souhlasím s tím, že takový nástroj rozhodně není náhradou skutečného skriptování.

Např. na zadání textu "ahoj" do políčka není potřeba kliknout na nějaké souřadnice ($x, $y) tlačítkem myši $t a zmáčknout postupně klávesy 'a', 'h', 'o', 'j'. To je jenom způsob, jakým to člověk udělá, ale z hlediska logiky té akce je to nadbytečné. Podstatné je jenom to, že se tam zapíše "ahoj", nic víc. Takže jak to udělat: získám referenci na příslušné textové políčko a zavoláním jeho metody nastavím text (pozn.: v dnešní době bývají GUI toolkity objektové a GUI je tvořené hierarchií objektů (widgetů)). Jednoduchá a pohodlná věc. Teda kdyby na to existoval nějaký šikovný shell.

Ideálně by se dalo vytvářet skript přímo z GUI, nemusel bych se tak dívat do manuálu, widgety by samy nabízely své API a jen bych si (přímo v GUI) vybral. Mohlo by to být i lepší a míň záludné než klasické shellové skripty, protože objekty narozdíl od prostého textu (se kterým pracuje klasický shell) mají jasně definovanou strukturu. Typová kontrola je určitě dobrá věc.

[pavlix]

Teda kdyby na to existoval nějaký šikovný shell.

CLI?

Ideálně by se dalo vytvářet skript přímo z GUI, nemusel bych se tak dívat do manuálu, widgety by samy nabízely své API a jen bych si (přímo v GUI) vybral.

Jenže tvůrce skriptů často předvídá určité situace na základě vlastní úvahy. Těžko donutíš stroj tyto situace předvídat za něj a tedy mu těžko nabídneš vše, co potřebuje.

Mohlo by to být i lepší a míň záludné než klasické shellové skripty

Z různých pokusů, které jsem kdy viděl, bych řekl, že to spíše bude daleko záludnější.

protože objekty narozdíl od prostého textu (se kterým pracuje klasický shell)

CLI umí stejně dobře pracovat s objekty textovými jako objekty strukturovanými.

Typová kontrola je určitě dobrá věc.

Opět v CLI velmi dobře funkční.

[imploder]

Tím shellem myslím prostě něco, co přijímá určitý skriptovací jazyk a podle toho spouští/ovládá programy. Tak jako klasický unixový shell umí spouštět programy a propojit jejich std vstupy a výstupy. Jo, aby ten shell šel volat ze stávajícího (CLI) shellu, tak by to asi měl být CLI program, resp. měl by být plně funkční i v CLI. Samozřejmě mohl by ten shell mít jen GUI, ale to by znamenalo nemožnost ho používat z CLI. Tahle otázka se týká jenom interaktivní části shellu (člověk spustí shell a něco v něm dělá); pokud jenom předám shellu skript, aby ho provedl, tak tahle otázka nemá význam - je to prostě normální interpret. Je to asi jako otázka, jestli Python je CLI nebo GUI - interaktivní python je CLI, u obyčejného pythonu to nemá smysl řešit.

Jenže tvůrce skriptů často předvídá určité situace na základě vlastní úvahy. Těžko donutíš stroj tyto situace předvídat za něj a tedy mu těžko nabídneš vše, co potřebuje.

Nemyslel jsem to tak, že počítač bude předvídat, co chci do skriptu napsat. Myslel jsem to jen jako usnadnění práce: místo toho, abych si z man stránek zjišťoval API jednotlivých příkazů a podle toho je používal ve skriptu, tak bych např. v záhlaví okna zmáčkl tlačítko "GUI API" a pak klikal na jednotlivé widgety a ukazovaly by se mi jejich dostupné atributy/metody a kdyby to bylo hodně chytré, tak bych si je mohl přímo v GUI vybírat a nastavovat a podle toho by se tvořil skript. Jen nápad, jak by to mohlo fungovat přívětivě. Stejně tak bych mohl používat k psaní skriptů jen textový editor a klasickou dokumentaci - man stránky apod..

Z různých pokusů, které jsem kdy viděl, bych řekl, že to spíše bude daleko záludnější.

Něco konkrétního? Je to rozhodně složitější věc než CLI. GUI je celkově složitější než CLI - je to pokročilejší technologie, vzniklo později. IMHO by jednoduchost používání hodně záležela na tom, jak by to bylo udělané.

CLI umí stejně dobře pracovat s objekty textovými jako objekty strukturovanými.

To nepopírám. "klasikou" jsem myslel něco jako unixovský nebo dosovský shell, kde se pracuje s textem. Unixový shell nemá prostředky pro práci se strukturovanými objekty - ty musí mít samotné programy. Ale jsou i objektové shelly, takže to chápu, samozřejmě i v CLI jde pracovat se strukturovanými objekty. Srovnával jsem s unixovým shellem.

Typová kontrola je určitě dobrá věc.

Opět v CLI velmi dobře funkční.

A opět ne v unixovém shellu.

Vůbec netvrdím, že v CLI tyhle věci nejdou. Tím "CLI? CLI... CLI" se snažíš říct co? Že v CLI jde udělat všechno, co tady popisuju že by mělo umět GUI, takže vlastně nic z toho není potřeba? To je hezký, ale jak se teda má automatizovat ovládání GUI? To je to, o co mi jde: aby uměl počítač plnohodnotně ovládat nejen CLI, ale i GUI. Aby GUI nebylo z tohoto hlediska méněcenné rozhraní. Protože nevidím důvod, proč by GUI tímto způsobem méněcenné být mělo, jenom proto, že je to GUI.

[pavlix]

Je to asi jako otázka, jestli Python je CLI nebo GUI - interaktivní python je CLI, u obyčejného pythonu to nemá smysl řešit.

Tak tys kritizoval i textové soubory a to pythoní zdrojáky jsou. Interaktivní python je nesmírně užitečný.

a pak klikal na jednotlivé widgety a ukazovaly by se mi jejich dostupné atributy/metody a kdyby to bylo hodně chytré, tak bych si je mohl přímo v GUI vybírat a nastavovat a podle toho by se tvořil skript.

Tenhle způsob právě nepokrývá případy, které nejsou z daného stavu prostředí/databáze/whatever zřejmé. Tam by muselo nastat to předvídání budoucnosti.

To nepopírám. "klasikou" jsem myslel něco jako unixovský nebo dosovský shell, kde se pracuje s textem. Unixový shell nemá prostředky pro práci se strukturovanými objekty - ty musí mít samotné programy.

Kritiku unixového shellu jako celku z hlediska uživatelské přívětivosti podporuju, to jsem říkal od začátku.

Vůbec netvrdím, že v CLI tyhle věci nejdou. Tím "CLI? CLI... CLI" se snažíš říct co? Že v CLI jde udělat všechno, co tady popisuju že by mělo umět GUI, takže vlastně nic z toho není potřeba?

Ale vůbec ne.

Snažím se tím říct to, že všecko, co zde popisuješ má rysy CLI, ať už v podobě interaktivní nebo serializované.

I ten python má řádky příkazů, i když se pustí neinteraktivně.

To je hezký, ale jak se teda má automatizovat ovládání GUI?

To je otázka na tebe, já automatizaci GUI nikdy k ničemu nepotřeboval. Vždycky mi stačila automatizace akcí, které za GUI stojí, která lze vyzkoušet přes interaktivní CLI a pak řádkově psané skripty složené z příkazů.

To je to, o co mi jde: aby uměl počítač plnohodnotně ovládat nejen CLI, ale i GUI. Aby GUI nebylo z tohoto hlediska méněcenné rozhraní. Protože nevidím důvod, proč by GUI tímto způsobem méněcenné být mělo, jenom proto, že je to GUI.

Ono není méněcenné, má prostě jiný účel. Ale zkoušet se na něj naroubovat něco, co se daleko lépe řeší přes CLI mi přijde jako ztráta času.

To už mi přijde lepší vytvořit dostatečně dobrý objektový model, aby nejen, že šel používat, jak v interaktivním GUI, tak v interaktivním CLI, tak i v neinteraktivních skriptech složených z příkazů CLI, ale aby se tyto způsoby co nejvíce potkávaly.

Tzn aby se stejná akce v GUI a v CLI nehledala úplně jinou cestou.

Dělat z GUI něco, co není, jenom proto, že ho chci vyzdvihnout mezi božstva, mi přijde padlé na hlavu.

[imploder]

Tak tys kritizoval i textové soubory a to pythoní zdrojáky jsou.

Jo, když se to vezme do důsledků, tak jsem vlastně vyzdvihoval hnusné binární formáty nad krásné čitelné textové soubory Ne, vážně, jsou systémy (např. Squeak), kde ani není klasický filesystém, ale jenom perzistentní, strukturované objekty. U online aplikací se taky dává většinou přednost nějaké (strukturované) databázi před prostými soubory. Ta myšlenka (neserializovat, ale mít přímo v systému podporu ukládání binárních strukturovaných objektů) IMHO má něco do sebe, ale nevím, jestli to jde udělat tak, aby to nebylo moc omezující pro to, jaké aplikace je v takovém systému možné provozovat a jak můžou spolupracovat. V každém případě pro programátora jedné aplikace je to výhoda, problém nastává, když je potřeba k těm datům přistoupit jinou aplikací, která na to není speciálně uzpůsobená. Tady je textový soubor sázka na jistotu - na úrovni znaků je práce s ním úplně jednoduchá a na spoustu věcí taková úroveň stačí.

Python a jiné běžné programovací jazyky mají samozřejmě zdrojáky jako text. Použít na kód binární formát je zlo (zkoušel jsem napsat generátor kódu pro Baltíka 3 (tuzemský jazyk pro děti s uzavřeným binárním formátem zdrojáků) a brzo jsem toho nechal). IMHO není hlavní problém v tom, že data nejsou uložená jako prostý text (stejně jsou fyzicky soubory fragmentované atd.), ale v tom, že se k nim dostane jenom specializovaný program, ne jakýkoliv program schopný pracovat se souborem ve smysluplné podobě tak, jak ho dostane (textové editory a jiné nástroje na práci s textem).

BTW není pravda, že by jakýkoliv program mohl jednoduše plnohodnotně pracovat s Pythonovským kódem. Na pochopení struktury ho musí umět rozparsovat.

Interaktivní python je nesmírně užitečný.

Souhlas, tohle nepotřebuju, aby mi někdo říkal. Já ho přece nechci zrušit, sám bych toho litoval

Říkal jsem snad někde něco ve smyslu, že CLI je k ničemu? To si rozhodně nemyslím, jenom ho považuju za míň mocné než GUI.

To je otázka na tebe, já automatizaci GUI nikdy k ničemu nepotřeboval.

Asi proto, že to vždycky jistilo CLI Třeba ovládání webového prohlížeče zvenčí je nesmírně užitečná věc (vím, existuje Selenium-RC). Taky třeba: co kdybych mohl používat standardní utilitky jako grep, sed (nebo spíš nějaké blbuvzdornější - nejlíp GUI - ekvivalenty) přímo ve svém mailovém klientovi? GUI aplikace je (kromě kopírování přes schránku) za současného stavu odkázaná sama na sebe - není možné ji jednoduše propojit s jinou jako se to dá udělat na příkazovém řádku. To vede k tomu, že se snaží dělat všechno a nic pořádně. To GUI umí jenom to, s čím se dopředu počítalo. Chybí svoboda propojit cokoliv s čímkoliv jako to jde u CLI. Podle mě by to chtělo v GUI nějaký koncept odpovídající vstupu a výstupu u CLI.

To už mi přijde lepší vytvořit dostatečně dobrý objektový model, aby nejen, že šel používat, jak v interaktivním GUI, tak v interaktivním CLI, tak i v neinteraktivních skriptech složených z příkazů CLI, ale aby se tyto způsoby co nejvíce potkávaly.

Tzn aby se stejná akce v GUI a v CLI nehledala úplně jinou cestou.

Naprosto souhlasím. Však jsem taky kritizoval rozpolcenost GUI a CLI. Dávat je do kontrastu proti sobě jako 2 v pricipu neslučitelné přístupy (včetně výkřiků "klikačka je pro lamy" a "příkazový řádek - fuj!") je IMHO podobná blbost jako stavět takhle proti sobě objektové a procedurální programování. V Linuxu se typicky používá GUI i CLI a lepší integrace by tomu rozhodně prospěla.

[pavlix]

To si rozhodně nemyslím, jenom ho považuju za míň mocné než GUI.

Tak to už se snad dá po té dlouhé debatě považovat za vyvrácené :), snad s výjimkou programů na tvorbu grafiky.

GUI aplikace je (kromě kopírování přes schránku) za současného stavu odkázaná sama na sebe - není možné ji jednoduše propojit s jinou jako se to dá udělat na příkazovém řádku.

Doporučuju prostudovat D-bus. Ale objektové propojení nebude nikdy tak univerzální jako propojení proudové.

V Linuxu se typicky používá GUI i CLI a lepší integrace by tomu rozhodně prospěla.

Kdykoli něco sám tvořím, tak se snažím navrhnout slušné objektové rozhraní a nad tím prvně CLI (lépe se na tom testuje) a pak GUI (obvykle žádané zákazníkem).

[imploder]

V GUI se dá udělat cokoliv, co se dá udělat v CLI. Docela dobře to ukazuje fakt, že používáme CLI uvnitř GUI, ale nejde mít GUI uvnitř CLI (max. nějakou textovou napodobeninu).

D-Bus prostuduju. Asi by to byla nejlepší volba - je to standard a podporuje strukturované objekty, ne jenom proudy.

Ale objektové propojení nebude nikdy tak univerzální jako propojení proudové.

To je stejný problém jako u těch souborů (není text => problém, formátu ostatní nerozumí). Nevím, jestli to má přijatelné řešení, kromě "řešení", že každý strukturovaný objekt bude mít funkci serializace (tj. převod na objekt typu "proud").

Kdykoli něco sám tvořím, tak se snažím navrhnout slušné objektové rozhraní a nad tím prvně CLI (lépe se na tom testuje) a pak GUI (obvykle žádané zákazníkem).

Dělat ke každému GUI odpovídající CLI je ale docela dost práce navíc, ne? Chápu to, CLI se hodí mít.

[imploder]

Teda... spíš objekty typu "bajt", proud by do objektu asi nešlo zabalit.

[pavlix]

V GUI se dá udělat cokoliv, co se dá udělat v CLI. Docela dobře to ukazuje fakt, že používáme CLI uvnitř GUI, ale nejde mít GUI uvnitř CLI (max. nějakou textovou napodobeninu).

Grafické vs textové rozhraní a GUI vs CLI není to samé. GUI/CLI je přístup k práci, způsob vyvolávání akcí. CLI v okně není GUI, ale CLI, takže těžko přisuzovat jeho schopnosti GUI, které s ním pouze zprostředkovává komunikaci.

Ale dostáváme se na trochu tenkou hranici, takže bych to moc neřešil.

To je stejný problém jako u těch souborů (není text => problém, formátu ostatní nerozumí). Nevím, jestli to má přijatelné řešení, kromě "řešení", že každý strukturovaný objekt bude mít funkci serializace (tj. převod na objekt typu "proud").

Řešení je už nějakou dobu známé. Použít textový fomát, tedy formát čitelný člověku/administrátorovi, ale svázat ho nějakými pravidly a vytvořit převodní funkce mezi textovou formou a vnitřní formou pro aplikaci.

Existuje taky spousta metaformátů, které nedefinují přesnou strukturu, jen syntaxi a jdou přímo převádět na vnitřní struktury programu, například JSON.

Dělat ke každému GUI odpovídající CLI je ale docela dost práce navíc, ne?

Taky nedělám plnohodnotné uživatelské CLI, ale jen takové, které je potřeba k základním testům. Procházet cyklem testování čehokoli polofunkčního s opakovaným spouštěním GUI je strašně neefektivní. Navíc v době prvních testů programu či knihovny umě obvykle GUI ještě vůbec neexistuje.

Pro ilustraci, takové testovací rozhraní se obvykle vejde do dvaceti řádků kódu, z nichž většina ošetřuje nějaké parametry. Mívám i delší, to když některý parametr určuje co se vůbec bude dělat.

Takže v tom vidím spíš obrovskou úsporu času a následkem toho vůbec schopnost dodat otestovaný program... často je potřeba projet X možností v cyklu nebo dokonce rekurzivně, aby člověk zjistil, jestli vše funguje.

[imploder]

Řešení je už nějakou dobu známé. Použít textový fomát, tedy formát čitelný člověku/administrátorovi, ale svázat ho nějakými pravidly a vytvořit převodní funkce mezi textovou formou a vnitřní formou pro aplikaci.

To je obvyklý způsob komunikace programů v unixovém shellu. Pro CLI je to výhodné předávat data ve formě textu, protože v CLI jsou příkazy text. Dobře to tam zapadá.

Pro GUI by se IMHO víc hodilo použít jako základní entity ne text, ale objekty, protože GUI by se stejně musely předávat objekty (nestačí 1 proud jako vstup (stdin) a 1-2 proudy jako výstup (stdout, případně ještě stderr) jako u CLI). Pro propojení s programy pracující jen s textem by se objekt dal serializovat třeba do JSONu.

Procházet cyklem testování čehokoli polofunkčního s opakovaným spouštěním GUI je strašně neefektivní.

Jeden z důvodů, proč mít plně skriptovatelné GUI. Aby bylo jasno: podle mojí představy by GUI mělo být opravdu použitelné pro skriptování, nemělo by v tom být o nic horší než CLI. Vůbec by mě nemuselo trápit, že skriptem ovládám GUI aplikaci, výsledek by byl stejně kvalitní. Samozřejmě s tím, že ovládané GUI by během provádění skriptu nebylo vidět; zobrazovalo by se jenom v debug modu (ekvivalent -x v sh). Používání takových analogií s CLI tam, kde to dává smysl, je podle mě dobrá cesta.

[pavlix]

To je obvyklý způsob komunikace programů v unixovém shellu.

Shell v tom nehraje významnou roli.

Pro GUI by se IMHO víc hodilo použít jako základní entity ne text, ale objekty,

Tím se točíme v kruhu, mohl bych začít odkazovat na předchozí komentáře a tok diskuze by se zacyklil.

Strukturované objekty se dle mého názoru do CLI hodí stejně dobře, ne-li lépe než text.

Pro propojení s programy pracující jen s textem by se objekt dal serializovat třeba do JSONu.

JSON je spíše vhodný pro programy pracující s objekty, serializace a deserializace u něj dává daleko větší smysl než jakékoli jiné zpracování (ač už jsem jiné zpracování v praxi použil).

Jeden z důvodů, proč mít plně skriptovatelné GUI.

Jak už jsem psal, nevidím důvod ke skriptování mačkání tlačítek myši apod... lepší je IMO skriptovat na objektovém modelu vycházejícím z logiky aplikace, než nad GUI. Tedy v podstatě jako kdyby GUI neexistovalo.

Aby bylo jasno: podle mojí představy by GUI mělo být opravdu použitelné pro skriptování, nemělo by v tom být o nic horší než CLI.

A přesně tuhle představu považuju za scestnou.

[imploder]

OK, myslím, že jsme si to celkem vyjasnili. Podle mě by mohlo GUI vycházet z logiky aplikace stejně jako CLI a obě rozhraní by mohly jít skriptovat. Nepovažuju to za zcestnou představu, ale za něco možného a potenciálně hodně užitečného. Současný stav, kdy jenom CLI má tuhle výsadu, nepovažuju za ideální. Každý na to máme svůj názor.

[pavlix]

Podle mě by mohlo GUI vycházet z logiky aplikace stejně jako CLI a obě rozhraní by mohly jít skriptovat.

Vidíš, v první části věty se i shodujem :). Ale proč skriptovat dvě rozhraní, to vážně nechápu, naskriptováním GUI v podstatě vznikne druhé CLI (při interaktivním použití se ze skriptovacího jazyku CLI stává) nebo druhý objektový model (vedle toho interního, který se často exportuje D-busem].

Současný stav, kdy jenom CLI má tuhle výsadu, nepovažuju za ideální.

Tak on skript má prakticky vždycky povahu příkazů nebo lze jednoduše na příkazy převést :). Takže ta výsada je principiální, ne přidaná člověkem.

[imploder]

V podstatě je to tak, mělo by to vlastnosti GUI i CLI. Spojovalo by to výhody obou rozhraní.

Tak on skript má prakticky vždycky povahu příkazů nebo lze jednoduše na příkazy převést :).

Veškeré ovládání počítače jsou v podstatě příkazy.

[kralyk z abclinuxu]

Co takhle udělat ovládání hlasem a tvořit skripty ve flacu

[imploder]

To ne, to by právě bylo "mechanické rameno"

[pavlix]

V podstatě je to tak, mělo by to vlastnosti GUI i CLI. Spojovalo by to výhody obou rozhraní.

Jestli to dobře chápu, tak bysme k jednomu dobrému CLI a jednomu dobrému GUI měli jedno špatné CLI navíc.

Veškeré ovládání počítače jsou v podstatě příkazy.

To ano, myší o 3 cm doprava rychlostí 1 m/s, ještě o dva, ale podle funkce xyz, pak šikmo doprava nahoru, 304ms prodleva, stisknout, 251ms prodleva, pustit, .......

To by bylo teprve ovládání :).

[imploder]

Jestli to dobře chápu, tak bysme k jednomu dobrému CLI a jednomu dobrému GUI měli jedno špatné CLI navíc.

Proč špatné?

To ano, myší o 3 cm doprava rychlostí 1 m/s, ještě o dva, ale podle funkce xyz, pak šikmo doprava nahoru, 304ms prodleva, stisknout, 251ms prodleva, pustit, .......

Tyhle věci by musela mechanická ruka ťukající příkazy na klávesnici do terminálu řešit taky. Myslel jsem, že jsme se shodli na tom, že snažit se programovat mechanickou ruku je chyba (nebo jenom zbytečně rozebírám vtip).

[imploder]

viz přirovnání k autům

[M___]

Protože v žádné diskusi nesmí chybět přirovnání k autům, jedno takové nabízím já:

Když budu chtít něco zautomatizovat, jeví se mi lepší to udělat tak, že budu přímo počítači rvát patřičné vstupy a příkazy (analogie CLI, VBA). Samozřejmě lze udělat i automatizaci GUI (volant, palubovka), tím že tam posadím mechanické rameno, je to sice sexy (kdo má mechanické rameno, žejo?), ale není to dobré. Na automatizaci máme jiné prostředky a GUI samo o sobě to není. GUI se dá použít v nějakém záznamovém režimu, ale měly by z toho vypadnout příkazy pro řídící jednotku auta, ne pro to rameno.

Pokud by z toho vylezlo něco typu „do tohohle widgetu napíš XY“ tak pořád programujeme mechanické rameno (i když to tak na první pohled nevypadá). Co když bude ovládání rádia najednou pod volantem (= změní se gui) a ne na palubce? Budeme všechny skripty předělávat?

[imploder]

Výborně, tentokrát to srovnání s autama dává smysl

Pokud by z toho vylezlo něco typu „do tohohle widgetu napíš XY“ tak pořád programujeme mechanické rameno (i když to tak na první pohled nevypadá).

To bych právě netvrdil, zvlášť když srovnáváme s psaním příkazů a ne s přímým voláním fukncí. Textové příkazy se musí rozparsovat a nějak interpretovat, až pak se volají funkce. Takže to vyjde minimálně na stejno, dokonce má GUI výhodu, že do toho políčka dostane text přímo (voláním API widgetu), nemusí kvůli tomu parsovat žádný text.

Co když bude ovládání rádia najednou pod volantem (= změní se gui) a ne na palubce? Budeme všechny skripty předělávat?

A co když se změní CLI? V obou případech je potřeba skripty předělat.

[M___]

Je pravda, že jestli to je docela na hraně, co je ještě programování ramena a co už ne. Ale přijde mi rozumnější vygenerovat příkaz Pocitej(42), než Zadej(mujBoxik, 42); Pocitej(); Raději bych v tom výsledném makru GUI tak nějak vynechal z procesu.

Podle mého názoru je pravděpodobnost, že se změní CLI mnohem menší, než že se změní GUI. Například datum se do CLI bude zadávat pořád jako Y-m-d (například), ale v GUI se mohou rozhodnout, že místo jednoho boxíku tam dají tři boxíky nebo rovnou kalendář - s každým takovým widgetem se pracuje jinak.

Je to na dlouhé diskuse, mno.

[imploder]

přijde mi rozumnější vygenerovat příkaz Pocitej(42), než Zadej(mujBoxik, 42); Pocitej();

To je ale docela nefér srovnání. V tom CLI je příkaz Pocitej, který má jasně definovaný parametr, s kterým pracuje; zatímco v CLI si ten samý příkaz bere "parametr" implicitně z vnějšku (fuj blé není to čistá funkce).

S těma změnama... to je asi hlavně o tom, jaká abstrakce se použije: jestli je to GUI udělané "tak, aby to teď fungovalo", nebo je prezentační část (jak kalendář vypadá a jak se konkrétně ovládá) a logická část striktně oddělená.

[M___]

Jasně, programátor nesmí být líný a musí vytvořit vlastní typ widgetu Kalendar, který by implementoval rozhraní IKalendar a zobrazování by si mohl dělat jak chtěl. Ale programátoři jsou líní, žejo.

[imploder]

S tím se asi nedá udělat nic víc, než dát mu do ruky toolkit, který ho ve správném návrhu bude podporovat. Současné toolkity na skriptování uzpůsobené nejsou, nejspíš by se v nich některé věci musely dost překopat nebo vytvořit pro skriptování nějaká nadstavba.

Podobná nekompatibilní změna může nastat i v CLI: třeba nejdřív zadávám datum pomocí 3 přepínačů -Y -m -d (z pohodlnosti, použiju getopt a nemusím jednotlivé složky datumu parsovat) a pak to změním na jeden řetězec ve formátu "Y-m-d".

Neviděl bych to tak tragicky. Kdyby bylo GUI standardně skriptovatelné, toolkity a programátoři by s tím při návrhu počítali.

[pavlix]

Současné toolkity na skriptování uzpůsobené nejsou, nejspíš by se v nich některé věci musely dost překopat nebo vytvořit pro skriptování nějaká nadstavba.

Tvůrci současných toolkitů (díval jsem se pouze na GTK) totiž skriptovat GUI nechtějí, proto se například nesnaží o těsnou integraci GUI objektů s D-busem. Pardon, nemám v hlavě odkaz, takže máš plné právo považovat toto za pouhý můj dojem. Ale zajímal jsem se o to.

Podobná nekompatibilní změna může nastat i v CLI: třeba nejdřív zadávám datum pomocí 3 přepínačů -Y -m -d (z pohodlnosti, použiju getopt a nemusím jednotlivé složky datumu parsovat) a pak to změním na jeden řetězec ve formátu "Y-m-d".

Nejde o to, jestli může nebo nemůže. Budu teď mluvit jen subjektivně. Kdybych navrhoval CLI a GUI k aplikaci kalendáře... budu CLI tvořit stabilní, s využitím celosvětového (byť lokálně méně užívaného) standardu. Naopak GUI budu tvořit přizpůsobitelné, které se bude řídit nastavením místních zvyklostí, jazykem a podobně.

Tím docílím jednak přenositelnosti skriptů (CLI) mezi prostředími, druhak perfektním vyladěním GUI.

Neviděl bych to tak tragicky. Kdyby bylo GUI standardně skriptovatelné, toolkity a programátoři by s tím při návrhu počítali.

Nemám pocit, že by toto tvrzení bylo opodstatěnené.

[imploder]

Tím docílím jednak přenositelnosti skriptů (CLI) mezi prostředími, druhak perfektním vyladěním GUI.

To znamená, že GUI bude vyladěné pro uživatele a nepoužitelné pro programy, zatímco CLI bude nevyladěné pro uživatele a vyladěné pro programy. Pak uživatelé budou asi upřednostňovat GUI (tj. to, co je pro ně perfektně vyladěné).

Já bych radši viděl GUI přístupné pro uživatele i programy podobně jako to bylo se všemi programy v dobách, kdy programy měly jen CLI. Nebylo by to úplně jednoduché zařídit, ale podle mě je možné problémy s tím spojené vyřešit a stálo by to za to. Takový je můj názor.

[pavlix]

To znamená, že GUI bude vyladěné pro uživatele a nepoužitelné pro programy

Jako tomu bylo vždy a všude.

zatímco CLI bude nevyladěné pro uživatele a vyladěné pro programy

A velmi dobře použitelné pro pokočilé uživatele, samozřejmě :).

Pak uživatelé budou asi upřednostňovat GUI (tj. to, co je pro ně perfektně vyladěné).

Pak se budou uživatelé děli na ty, co používají GUi, ty, co používají CLI a ty, co používají obojí, jako tomu bylo vždy.

Já bych radši viděl GUI přístupné pro uživatele i programy podobně jako to bylo se všemi programy v dobách, kdy programy měly jen CLI.

Což ono bude, pro pokročilé uživatele bude CLI vyladěné jako bývalo nebo lépe. Tenkrát ale byli skoro všichni uživatelné na úrovni dnešních pokročilých uživatelů. Dnes jsou uživatelé líní a hlavně neznalí, tak to nebylo vždycky.

Nebylo by to úplně jednoduché zařídit, ale podle mě je možné problémy s tím spojené vyřešit a stálo by to za to. Takový je můj názor.

Pokud je tvůj názor takový, pak mi nezbývá než ti popřát hodně štěstí a.... jdi do toho!

[imploder]

Což ono bude, pro pokročilé uživatele bude CLI vyladěné jako bývalo nebo lépe.

Pokud představa pokročilých uživatelů o velmi dobře vyladěném programu je program vyladěný pro počítač a ne pro člověka, tak určitě

Pokud je tvůj názor takový, pak mi nezbývá než ti popřát hodně štěstí a.... jdi do toho!

Díky. Příští rok končím bakaláře na FIT VUT, přemýšlím, že bych si to vybral jako téma BP.

[pavlix]

Pokud představa pokročilých uživatelů o velmi dobře vyladěném programu je program vyladěný pro počítač a ne pro člověka, tak určitě

Pokud jsi mě takto pochopil, tak nemám slov.

Díky. Příští rok končím bakaláře na FIT VUT, přemýšlím, že bych si to vybral jako téma BP.

Ačkoliv mi přijdou tvé představy o UI mimo, pokud budeš mít nějaké reálné výsledky, rád se na ně podívám :).

[imploder]

Pochopil jsem to tak, že pokročilým uživatelům minimálně nevadí nedokonalá vyladěnost programu pro člověka a tak můžou používat i CLI, které je vyladěné dobře pro automatizaci, ale už ne tak pro člověka (pohodlnost ovládání, lokalizace atd.); ale lamy by takové rozhraní nepřežily, ty musí dostat perfektně pro člověka vyladěné GUI (ale nevhodné pro automatizaci). Pochopil jsem to nějak špatně?

[Jakub Lucký]

IMHO tasksel instaluje metapakáž gnome, která už tomboye obsahuje...

[Jendа]

No jo, vypadá to tak.

(metapakáž !!!)

[Jakub Lucký]

Že tě potěším tou metapakáží mě napadlo hned jak jsem to psal...

[Jendа]

Normální desktop s Xfce:

~ # dpkg -l | grep mono
~ # 

Jak konkrétně se ta prolezlost projevuje?

[uran]

+1

[egg]

Kobylky vlezly.

[LennyCZ]

+1

...ale jinak překlad SUPER :D

[Kvakor]

Kobylky nejsou nejhorší. Osobně bych dal přednost špíš žábám, ale pořád je to lepší než mouchy, komáři, mor, voda změněná v krev nebo tři dny temnoty

[kralyk z abclinuxu]

nebo tři dny temnoty

Mám takovej dojem, že na tři dny temnoty by většina ajťáků zaregovala slovy "fajn, nemusim řešit záclony"

[Chytrex]

LOL

+1

[Jakub Lucký]

Jo, taky záclony nemám

[#5]

A zbytek by nezareagoval vubec.

[petznaku]

mono, nemono.. než tyhle debaty tak už radši ty kobylky...