Antico 0.1 - jednoduchý desktop v Qt 4

Antico 0.1 je jednoduchý správce oken a desktopu připravený v Qt 4. Řídí se pravidlem KISS - vše musí být nastavitelné přes několik souborů a výsledek by měl být svižný. Antico byl zatím vyvíjen jen pár měsíců a hledá další programátory.

27.1.2009 10:55 | Luboš Doležel (Doli) | Zajímavý software

Komentáře

[zoul]

Přijde mi legrační, že chtějí udělat něco jednoduchého, a ve verzi 0.1 mají implementované stylování a výběr pixmap pro odhlašovací tlačítko…?

[Aleš Kapica]

No jestli ono to nebude přímo vlastnostmi Qt4.

[zoul]

Ty dialogy na screenshotu patří spíš Anticu, ne?

[YYY]

Nevypada to spatne. Zajimalo by mne, jak je to rychle. Musim si to [sz]kompilovat.

[hankey]

Tak to škompiluj a dej vědět

[YYY]

Škompiluju a dam vedet

[mirec]

Ide veľmi rýchlo, ale zatiaľ to nie je ešte ktovie čo. V každom prípade veľmi zaujímavý projektík. Pre gentoo uživateľov:

layman -a qting-edge
emerge antico

[J. M.]

To zní jak něco, po čem lidé volají už 10 let. Kolikrát už jsme za ty roky četli ty povzdechy „kéž by byl nějaký alternativní, odlehčený desktop pod Qt...“ To už všichni dávno přestali doufat...

[wire_64]

To víš. teď když to bude LGPL tak se všichni přetrhnou

[xkucf03]

Nevím, proč by se měli přetrhnout -- většina projektů beztak používá GPL.

[wire64]

Jenže u GUI je to docela problém.

[Drom]

To zalezi na uhlu pohledu...

[Amarok]

Hura, odlehcene KDE!
Jen nevim, jestli to ma sanci, kdyz uz je tolik dobrych alternativ k preplacanemu KDE/GNOME. Taky mi neprijde jako vhodne mit jeden .cfg soubor pro konfiguraci celeho window manageru, to je silenost a la 'registry ve woknech' - predstavte si jen prenaset zdlouhave nastavenou konfiguraci do nove verze, ktera najednou bude mit urcite zmeny (coz zarucene postupne mit bude), takze pak nezbyde asi nic jineho nez prochazet radek po radku a prekopirovat si to "svoje" nastaveni do toho noveho "defaultniho" cfg souboru. Napr. ve fluxboxu je konfiguracnich souboru nekolik, takze tam to takovy problem neni, jeste k tomu se daji pridat dalsi uzivatelske konfiguracni soubory.

[miso]

 

Hura, odlehcene KDE!

Od KDE to ma teda dost daleko ...

 

[Josef Kufner]

Odlehčené KDE? Hm, a nestačí prostě jen z kde vyházet všechen bordel a nechat si jen kwin a nějaké ty základy?

[Amarok]

Da se KDE konfigurovat jednoduse v textovych souborech? (To neni ironicka otazka, o konfiguraci jinak nez pres ty klikatka v KDE nevim, nevim jak je to vse ulozeno na disku.)

[frEon]

konfiguraky jsou v .kde/share/...

[Pev]

KDE <= 3: ~/.kde/share/

KDE == 4: ~/.kde4/share/

[frEon]

pravda, na kde4 jsem uplne zapomel

[xkucf03]

Takhle to bylo při souběhu obou verzí -- teď už mám ale zase jen ~/.kde/ (Kubuntu 8.10)

[Josef Kufner]

Nutno dodat, že ty konfiguráky jsou klasické INI, tedy žádné hnusné a nepřehledné XML, ale jednoduché:

[sekce]
klíč = hodnota

[Amarok]

Tak to je jednoznacne +, XML mi prijde na editaci taky silene (proto me treba odradil Openbox).

[Jardík]

No mě na openbox úplně stačí obconf (až na to menu), nejsem náročný.

[xkucf03]

A stromovou strukturu nebo validaci hodnot tam uděláš jak?

[thingie]

A jak často to je třeba?

[xkucf03]

Např. u stromové nabídky programů:

<složka>
   <název>Programy</název>
   <ikona>programy.png</ikona>
   <složka>
      <název>Video</název>
      <ikona>video.png</ikona>
      <program>
         <název>Kaffeine</název>
         <ikona>kaffeine.png</ikona>
         <příkaz>kaffeine</příkaz>
      </program>
   </složka>
   <program>
      <název>Gimp</název>
      <ikona>gimp.png</ikona>
      <příkaz>gimp</příkaz>
   </program>
</složka>


Zkus tohle nacpat do INI souboru… nakonec z toho vyleze nějaká prasárna se specifickou syntaxí, kterou nikdo nezná → musí se ji učit. Zatímco XML má syntaxi velmi jednoduchou (základ – dvě závorky a jedno lomítko) a stojí na jednoduchých pravidlech (značky se nesmí křížit).

Když udělám úpravy v konfiguráku, ocením, pokud si ty změny mohu zkontrolovat – k tomu se skvěle hodí validace XML. Nestandardní textové konfiguráky jde taky validovat – programem, ale to je právě rozdíl: u XML jednou deklarujeme formát (DTD, Schéma…) a validátor použijeme už hotový, zatímco při validaci programem ten validátor píšeme pokaždé znova, používají se různé formáty atd.

A kdo by naříkal, že XML editory jsou jen pro GUI, může klidně použít VIM jako XML editor.

Sice existují i nějaké jednoduché úkoly, kde si člověk s dvojicemi klíč=hodnota vystačí, ale pro konfiguraci desktopového prostředí bych určitě volil XML.

[mirec]

A kde je problém v používaní XML? Je akože program zmeniť 1 riadok v programe alebo konfiguráciu Qt? (pre tých ktorí nechápu ini súbory číta cez QSettings, ktoré zvláda okrem iného aj xml).

[Amarok]

Problem v pouzivani XML vubec neni, XML je v podstate velmi dobry "format", ale ne na rucni konfiguraci. Kod musi byt prehledny na prvni pohled, a to XML urcite neni (to co napisu ve Fluxboxu na 1 radek, by mi v Openboxu v XML zabiralo minimalne 3, je to ale urcite i trochu o vlastnim vkusu, stejne jako volba programovaciho jazyku).

[xkucf03]

 

to co napisu ve Fluxboxu na 1 radek, by mi v Openboxu v XML zabiralo minimalne 3.

Z hlediska diskových kapacit i přenosů po síti je dneska celkem jendno, jestli má konfigurák jeden nebo tři řádky. Klávesnici si taky neošoupeš, protože dobrý editor ti značky doplňuje, takže stačí napsat tu první. Navíc ti editor radí použitelné značky ze schématu, takže ani moc nemusíš studovat manuály, abys napsal správný konfigurák -- taková online nápověda .

 

[Amarok]

O to psani mi ani tak nejde a o velikost na disku uz vubec ne, klidne natukam i vic kodu. Ale jde mi o prehlednost. Proste kdyz mam 1kb cfg s 1radkovymi prikazy, tak se v tom (aspon teda ja) daleko lip orientuju nez v 5kb xml, me to prijde dost neprehledne.

[thingie]

Ano. Tak to je naprostá blbost. Z prostého pohledu na současné konfiguráky KDE je zřejmé, že takový případ se vyskytuje tak hrozně zřídka, že kvůli tomu použít XML by bylo absurdní. Nějaké malé místní rozšíření poslouží mnohem lépe.

Spíše se v konfigurácích objevují kontextové závislosti, které XML taky nespraví. Jediné co získáme, je strašně moc smetí, a když už použijeme XML, tak musíme zřejmě umět celé, a tím získáme zhovadile složitý a ošklivý systém, který nám neposlouží ani o píď lépe než prostý klíč=hodnota formát. Protože většinu dat takovým seznamem dvojic popíšeme, a když potřebujeme něco víc, je dobrá šance, že nám stejně nebude stačit ani XML.

Já bych lidi co přijdou a jen tak z fleku navrhnou pro konfiguráky (nebo vlastně jakákoliv data) XML, aniž by přesně věděli jak to bude vypadat, řezal hlava nehlava.

[thingie]

Zpracování celého konfiguráku včetně všeho pak pokryjeme prostými regulárními výrazy.

[Ladicek]

Hele, tohle mě docela dostává, nejdřív přijdeš s kontextovými závislostmi, a v zápětí navrhuješ pro zpracování regulární výrazy, to je trochu mimo, ne? Podobný přístup ostatně používají i lidi z úplně opačného konce spektra: tvrdí, že XML je vlastně text.

Jo a většinou stejně všechno skončí jako nějaký ten strom, tak co…

[thingie]

To je ale logické. Co s tím chce dělat a jak vlastně skutečně ten formát vypadá a co všechno tam je, to musí vědět aplikace. Vzhledem k tomu, že XML mi nakonec nebude asi stačit, tak nemá smysl se tvářit že kdovíco, a prostě společný formát zredukuju na ten jednoduchý seznam. Ta aplikace si to stejně musí udělat sama, nebo by ten formát už byl pro drtivou většinu použití zbytečně složitý. Přijde mi to určitě lepší než mít složitý a ošklivý formát (XML) se zbytečně složitým parsováním, nad který by stejně aplikace musela udělat spoustu práce. Aspoň jednu věc mám jednoduchou, narozdíl od žádné, jako by to bylo v případě XML.

O tom dost pochybuju, strom mi skutečně nepřijde jako typická struktura v konfiguráku (z mého dosavadního pozorování tedy plyne, že to rozhodně nebývá struktura v XML popisovaná). Musel jsem se poslední dobou patlat se spoustou XML, a v drtivé většině případů se na celé to XML mohl člověk zvysoka a napsat si prostě regexy. Proklikejte si možnosti nastavení vašich oblíbených aplikací, tam nebudou stromy, spíše volby typu kresli to nalevo nebo napravo.

[Ladicek]

Skutečně, konfiguráky KDE aplikací jsou ini soubory. No, a uložte do toho nějakou strukturovanou informaci, třeba o klávesové zkratce pro spuštění programu. Jistě, jde to, ale za jakou cenu? Já nehoruju pro XML konfiguráky, protože takové jsou dost blbě editovatelné člověkem, ale vezměte si takové konfiguráky, jako od apache (je to XML, není to XML…) nebo vimu (když odhlédneme od toho, že to vlastně není konfigurák, nýbrž skript ve speciálním programovacím jazyce). Kdyby se všechno (co nepotřebuje podmínku a rekurzi) narvalo do XML, máte aspoň analýzu struktury zadarmo, a že je strukturování potřeba častěji, než se může zdát z používaných formátů.

[thingie]

I v tom XML to musím nějak pochopit a zpracovat, a to co musím udělat u ini souboru navíc mi nepřijde drahé. Vlastně to někdy může být i výhoda, že si tam mohu snadno nacpat něco vlastního, co zvládnu pak jednodušeji než patlat se s ošklivým DOMem či něco takového. Ani u XML není výskyt různě neformálně strukturovaných prvků uvnitř úplně tak řídký, jak by si člověk mohl přát. Občas je to výhodnější. A může mne to jako autora vést k tomu lépe si tu strukturu rozmyslet, než všechno cpát na XML.

No, to sice narvalo, jenže když si prohlídnu svoje konfiguráky apache nebo vimu, tak je tam těch struktur prostě strašně málo, a kdybych to měl psát ručně (což zase budu, má cenu na apache dělat klikátko?), tak se z toho picnu. A spíš mi v tom XML zůstane spoustu vlastních dalších struktur. Asi jenom naprosto zvrácený úchyl bude rozepisovat regex do XML, ale ono jich tam je...

Já v tom XML pro konfiguráky prostě výhodu nevidím.

[Ladicek]

No proto říkám, že XML je na konfiguráky docela hrůza, protože je tady ten lidský faktor Ovšem regulární výraz v XML je správně úchylná myšlenka:

<regexp id="těžká pornografie">
  <alternation>
    <iteration>a</iteration>
    <iteration>b</iteration>
  </alternation>
</regexp>

To žeru! Vážně: kdyby do toho neměli hrabat lidi, mohl bych klidně serializovat celou runtime reprezentaci konfigurace do podobného formátu. Včetně těch regexpů – i když tam bych serializoval samozřejmě ten automat. Ne že by XML bylo na podobné hrátky to nejlepší, ale přinejmenším bych mohl použít hotové a spolehlivé knihovny. Je to už trochu extrémismus, ale co už.

Na druhou stranu mám poslední dobou čím dál radši přístup, kdy kód je konfigurace. Jako u toho vimu.

[thingie]

Zrovna příklad jak strukturovat klávesové zkratky do XML bych si ukázat nechal, myslím

[Ladicek]

Tak viz konfiguráky Xfce

[Ladicek]

Ačkoliv to je zrovna příklad, kdy je XML brutální overkill. Naopak v KDE jsem ten formát na první pohled prostě nepochopil.

[thingie]

Bohové. Vždyť to je naprosto dokonale příklad toho co jsem kritizoval, to co tam hlavně má být strukturované je prostě vepsané do atributu keys

[Ladicek]

No. Taky jsem netušil, proč to udělali zrovna tak, když jsem to musel editovat ručně, protože klikátko nefungovalo. Ale jako autor programu dám určitě přednost tomuhle

<shortcuts>
  <shortcut name="KWrite" cmdline="/usr/bin/kwrite" keys="Super_L+E" />
</shortcuts>

před tímhle

[shortcuts]
shortcut.1.name=KWrite
shortcut.1.cmdline=/usr/bin/kwrite
shortcut.2.keys=Super_L+E

Což je pravda dané tím, že jediné API pro práci s ini soubory, které znám, je to z Borland Delphi, a to bylo dost děsivé. XPath nad DOMem je pohodlné velmi. Jistě, vůbec nejlepší by bylo

configure_shortcuts do |shortcuts|
  shortcuts.add :name => "KWrite", :cmdline => "/usr/bin/kwrite", keys => "Super_L+E"
end

[Ladicek]

Hle, a hned jsem dal najevo, proč bych dal prvému přednost před druhým. Dvojka na posledním řádku má být samozřejmě jednička.

[thingie]

Tak to není jediná možnost jak to udělat, zcela jistě. Jakože na tohle začíná být zbytečně moc snad i ten ini soubor. Tohle nikdy nebude víc než trojice řetězců, stačilo by natáhnout CSV soubor.

[xkucf03]

Tohle nikdy nebude víc než trojice řetězců

Vtip je v tom, že XML má standardní syntaxi – koukneš a vidíš – ale jinde musíš zkoumat syntaxi, kterou si každý autor udělá trochu jinak, zkoumat, co je oddělovač, jaké jsou escapovací znaky (jsou-li vůbec), když chceš použít znak vyhrazený pro oddělovač v textu atd. atd.

stačilo by natáhnout CSV soubor

CSV je fajn, ale dokáže popsat jen tabulku a maximálně záhlaví sloupců, nacpeš do něj jen homogenní strukturu (záznamy mají stejné sloupce – atributy), takže bys musel mít spoustu souborů, pro každý typ dat jiný. A pak můžeš mít nějaké vnořené struktury: např. adresář, kde máš X osob a každá osoba má Y e-mailů a Z adres… to už do CSV nedostaneš.

BTW: taky už jsem viděl spoustu mizerných použití XML, někdy to byly jen struktury klíč=hodnota zaobalené do <závorek>, jindy nevhodné použití atributů nebo např. nabastlení více hodnot oddělených středníkem do jedné značky/atributu, místo aby to bylo několik značek/atributů… a jiné sra*ky… dobré DTD/Schéma prostě neumí navrhnout každý, ne každé využití XML je užitečné, ale tyhle smutné případy dokládají neschopnost autorů, nikoli nevhodnost XML. Tak se tím nenechte strhnout.

[thingie]

Syntaxi na úrovni toho kde se píšou zobáky, ale co do toho konfiguráku napsat si stejně musím nastudovat...

Ne, nemůžu, jsou to klávesové zkratky. Ty budou furt nejspíš stejné. Co bych spíš chtěl vymyslet je jak zapsat hezky tu samotnou zkratku. Třeba tenhle krám nebude umět emacs-like dlouhé zkratky typu C-x C-c. Které jsou fajn, a bylo by hezké je umět. V XML to bude celé vypadat naprosto příšerně.

Ano, tak třeba navrhovat použít pro konfiguraci KDE aplikací XML je neužitečné a špatné využití XML. O to tu jde. Příliš mnoho využití XML je špatných. Už se ani neobtěžuju si dělat statistiku, ale ta špatná nad těmi přijatelnými rozhodně vedou.

[Ladicek]

Tohle nikdy nebude víc než trojice řetězců

Tak to právě není pravda, třeba KDE umožňuje mít globální zkratky dvě, a naopak nespouští přímo daný příkaz, ale příkaz, který obsahuje položka menu, na kterou se klávesová zkratka odkazuje. A tak.

Všechny tři formáty, které jsem uvedl jako příklad, umožňují rozšiřování (i když v případě toho ini souboru je to rozšiřování ve směru pravé nohy za levým uchem). CSV? Ani boha.

[thingie]

No, rozšiřování, to je pěkné, ale takový konfigurák bude používat pár kusů kódu a možná tak jeden nebo dva vlastní skripty, a pokud by se nějak změnilo to co se do něj dá ukládat, stejně se to všechno asi bude muset předělat, takže zase s tím rozšiřováním to v určitých případech je samozřejmě pravda, ale zrovna v případě...

[mirec]

Qt 4 aplikácie používajú .ini súbory v linuxe. V Mac OS používajú xml a vo windowse registre.

[petr_p]

Praví můži si napíšou gramatiku a pak pomocí flexu a yacca a trochu nativního kódu vyrobí parser. Jak jinak chcete načítat konfiguráky typu bind?

[thingie]

Nejlíp nijak, proč taky...

[Ladicek]

Ručně psaným parserem, protože to, co blejou LALR generátory, nikdy nebude mít rozumné zpracování chyb?

Ale pravda, chybové hlášky, které dávají smysl, to není unixový styl.

[xkucf03]

 

Praví můži si napíšou gramatiku a pak pomocí flexu a yacca a trochu nativního kódu vyrobí parser.

To jsou zbytečnosti -- stačí si uvědomit, že nastavení načtené v paměti je nějaká struktura objektů. A objektům velmi dobře odpovídá XML -- stačí je serializovat na disk.   Ta serializace se dá udělat více či méně sofistikovaně -- buď se použijí standardní funkce jazyka (tím ztrácíme některé výhody XML) nebo si napíšeme vlastní serializátor objektů do XML -- tam výhody XML formátu plně využijeme, ale zároveň je to méně pracné a standardnější, než si psát vlastní gramatiku. Navíc uživatel, který chce náš konfigurák editovat, se nemusí novou gramatiku učit a nemusí si pořizovat zvlášní* editor pro náš formát, prostě použije nějaký standardní XML editor.

 

*) jasně, může použít obyčejný textový editor, ale to znamená nulovou podporu pro specifický formát, nulové usnadnění práce.

[petr_p]

Přiznejme si, že takto to funguje, jen když konfigurace v souboru a datové struktury uvnitř programu si přesně odpovídají, což nepovažuji za zrovna častý případ (např. v konfiguráku je čitelnější seznam, v paměti je rychlejší třeba halda). Jediné, co tím vyřešíme, je syntaxe na fyzické úrovni. Vyšší logiku stejně musíme při nahrávání vstupu validovat. Váš přístup ad absurdum představují registry na Windows, kde se to binárními hodnotami a magickými klíči jen hemží.

[JS]

Vy byste si vazne mel precist http://www.defmacro.org/ramblings/lisp.html, pak by vas to XML rychle preslo.

[xm]

Místo zobáčkového pekla závorkové peklo? Děkuji, nechci, jedno horší než druhé :-P

[xm]

A abych nebyl jen negativní - než XML nebo S-výrazy (na zápis datových struktur, konfiguráků, etc.), to už mnohem radši YAML.

[JS]

Jeste pred mesicem jsem si myslel totez. Ale pak me prednaska a knizka Practical Common Lisp otevrela oci. "Zavorkove peklo" je jenom povrchni pohled.

[xkucf03]

Přijde mi to jen, nebo tam opravdu srovnávají jablka s hruškami?

int add(int arg1, int arg2)
{
    return arg1 + arg2;
}

vs.

<define-function return-type="int" name="add">
    <arguments>
        <argument type="int">arg1</argument>
        <argument type="int">arg2</argument>
    </arguments>
    <body>
        <return>
            <add value1="arg1" value2="arg2" />
        </return>
    </body>
</define>

Programovací jazyk (definice funkce/metody) je přece něco zcela jiného než dokument (objekty).

[JS]

Ne, oni jen ukazuji, jak by  vypadal programovaci jazyk zapsany v XML. A dokonce davaji priklad takoveho jazyka - Ant.

Smichanim programovaciho jazyka (maker) a dokumentu dostanete daleko lepsi nastroje na validaci, nez poskytuje XML. To je cesta Lispu. Inu, nekdo to pochopi, a osviti ho, a nekdo ne, a neosviti ho. Vas asi neosviti.

[xkucf03]

Programovat v XML je nepraktické, to bych ani já nechtěl (zlatá Java) Ant není jediný, podobně je na tom JSPX, ale to je v první řadě dokument, proto se hodí XML a programování je tam minimum (pár IFů, jednoduchý cyklus…), protože aplikační logika se odehrává v beanách a JSP jen prezentuje výsledek (kdo si stěžuje, že se mu v JSP špatně programuje, tak ho většinou špatně pochopil).

Míchat data a programování (zpracování těch dat) do jednoho se mi nelíbí a většinou to považuji i za chybu. Dávám přednost čistým datům, která může zpracovat kdokoli, nezávisle na platformě nebo programovacím jazyku. Na ty nejjednodušší případy se dá použít CSV nebo texťák klíč=hodnota, na cokoli složitějšího je pak celkem logickou volbou XML.

Co jsou ty daleko lepší nástroje na validaci? Ty si přece musím napsat sám – pochybuji, že by existoval nějaký standardní validátor, který by pochopil změť dat a kódu a věděl, které operace s daty jsou správné a které datové struktury platné – tohle totiž má v hlavě programátor, u XML to může vyjádřit pomocí DTD nebo Schématu, ale jak to vyjádří u Lispu? Jak tam deklaruji, jak má vstup (dokument, konfigurák) vypadat?

[petr_p]

Odstrašujícím případem budiž XSLT.

[xkucf03]

Nikdo ti ho nenutí Uznávám, že XSLT už je trochu složitější na zvládnutí. Ale naštěstí máme možnost volby: XML buď zpracuješ pomocí XSLT nebo si ten převodník napíšeš v nějakém vlastním jazyce. XSLT může (ale nemusí) být pracnější, ale zase má výhodu v přenositelnosti – převodník napíšeš jednou a pak se dá používat různých jazycích, kdežto když si napíšeš převodník třeba v pythonu*, musí na cílové platformě python být nebo to musíš celé přepisovat.

Podobně je to s XML – je to standard použitelný na různých platformách a v různých programovacích jazycích, narozdíl od nějakého proprietárního textového konfiguráku, který se používá jen v jedné aplikaci a jeho syntaxe nebývá nikde deklarovaná – zná ji ten programátor a je zadrátovaná do kódu programu.

*) v javě, céčku… v čemkoli.

[Ladicek]

Programovat v XML je nepraktické, to bych ani já nechtěl (zlatá Java) Ant není jediný, podobně je na tom JSPX, ale to je v první řadě dokument, proto se hodí XML a programování je tam minimum (pár IFů, jednoduchý cyklus…)

JSP je turingovsky úplné, i bez skriptletů, přes dispatcher by se měla dát udělat rekurze Ano, programovat v XML je nepraktické, proto taky uživatele výše zmíněného XSLT považuju za masochisty, kterým se v mozku odehrál nějaký těžký zkrat. Mimochodem, znáte Relax NG? To je takový Lisp přiohnutý pro XMListy

Míchat data a programování (zpracování těch dat) do jednoho se mi nelíbí a většinou to považuji i za chybu.

Tak to já už jsem na dalším levelu, už si uvědomuju, jak užitečné to je a jakou flexibilitu to přináší Ono, kód jako data, data jako kód… vždyť na tom jsou postavené všechny překladače. Možná k vám ještě nedorazila módní vlna oborových jazyků (DSL)? No, tak Lispaři je znají a používají už desítky let

Hm, to skoro vypadá, jako bych právě obrátil o 180 stupňů a ještě se postavil na hlavu. Ve skutečnosti v práci XML na konfiguraci normálně používám. Prostě proto, že to je hotová technologie, která do Javy pěkně zapadá. A po večerech a o víkendech si čtu knížky jako SICP a snažím se vyrovnat s tím, že nic podobného nejspíš nikdy nebudu používat v praxi

[xkucf03]

Příloha:

• xml-latex.7z (117966 bytů)

Na JSP se předně není dobré dívat jako na programování porogramování by se mělo odehrávat jinde a JSP má jen prezentovat, dělá minimum práce.

XSLT taky nepovažuji za programování, je to jen transformace z jedněch značek na jiné, já jsem v tom např. napsal převodník mezi XML a LaTeXem (viz příloha).

Jak už jsem tu někde psal, použití XSLT má výhody (přenositelnost) i nevýhody (nejde v tom napsat všechno, něco je pracné), je to o volbě, někdy XSLT použiji, jindy to napíšu do kódu třeba v Javě nebo jiném jazyce, ale to nijak nezpochybňuje vhodnost XML pro uložení dat – dokumentů.

Relax NG znám, asi myslíš jeho kompaktní syntaxi. Tady je rozdíl mezi dokumentem (data) a jeho popisem (schéma) – na popis nám stačí relativně omezené prostředky, které by na vlastní data nestačily (tam potřebujeme víceřádkový text, různá kódování, escapování znaků, mezery, tabulátory…)

už si uvědomuju, jak užitečné to je a jakou flexibilitu to přináší

Flexibilitu to na jedné straně přináší a na druhé bere – když přimíchám k datům kód, jsem závislý na nějakém jazyce, potřebuji jeho interpret, kdežto když mám čistá data, můžu si je zpracovat kdekoli a přenášet je mezi programy, jazyky, platformami… Taky je otázka, jestli se na data dívat jako na něco statického (sama od sebe nic nedělají, veškeré zpracování a změny jsou iniciované zvenku, nebo jako na nějaké živé objekty, které se nějak chovají, nejsou to jen hloupé přepravky (get/set), ale mají vlastní logiku – což je sice hezké, ale pak nastává problém, když tuhle logiku potřebuji změnit, když s daty chci dělat něco jiného, než zamýšlel jejich autor. Proto mi přijde lepší data a kód oddělit a mít např. DTOčka a k nim různé třídy, které s nimi pracují, což znamená, že se stejnými daty mohu pracovat různými způsoby – což je, alespoň pro mě, flexibilnější, než když mám data a kód neoddělitelně spojená.

nic podobného nejspíš nikdy nebudu používat v praxi

 čím to asi bude?

[Ladicek]

XSLT je taky turingovsky úplné A pročpak má asi tu podobu, jakou má. Co takhle možnost transformovat XSLT předpis jiným XSLT předpisem…

Jo, anemický doménový model, to známe

[Ladicek]

Jo, ještě:

čím to asi bude?

To bude tím, že zdaleka nejsem takový guru jako Paul Graham a podobní , ale normální průměrnej prgač.

[petr_p]

Proti datům jako kódu bych ještě přidal jeho nebezpečnost.

V okamžiku, kdy mám turingovsky úplný datový formát, tak problémem se stává už jen jeho zpracování, protože z principu nelze zjistit, jestli se mi data nezacyklí (pro příklad stačí poslat vhodný soubor postscriptové tiskárně).

[Ladicek]

Dejte mi všechna přirozená čísla v konečném prostoru

Pokud máte velké požadavky na bezpečnost, určitě namísto Lispu sáhnete po Adě. Ta je taky super.

[petr_p]

Poznamenávám si: překladač Ady umí rozhodnout problém zastavení ;)

Jistě že lze nastavit časový limit a po jeho překročení vstupní data odmítnout. Jenže to jaksi postrádá jednoznačnost, kdy poznám, jestli mám jen pomalý počítač nebo ta data jsou chybná.

[Ladicek]

Jestli chcete zabíhat do perverzit, tak bych začal tím, že skutečný počítač je pouze konečný automat a zastaví vždy :-P Ačkoliv ve Windows se takové zastavení nepříjemně často projevuje jinak, než bychom si přáli

Totiž když řeknu, že na extra bezpečné programy je vhodná Ada, tak nemyslím jenom jazyk, ale i paradigma.

Ale když jsme u bezpečnosti: jak často máte problém s nekonečným regresem v datové struktuře, když použijete třeba Lisp, a jak často máte problém s buffer overflow, když použijete třeba Céčko?

[thingie]

Nojo. Aby se ale dřív nezastavil sám uživatel.

[thingie]

No, u konfiguráků patrně není třeba se bát, že by někdo podstrčil cyklící data schválně, a legitimní uživatel si to holt nějak zdebuguje, takže tady bych to asi aji zanedbal (předpokládám, že řeč je stále primárně o konfiguraci*). Jinak jo, no, problém to je.

*Ale zase konfigurace, pokud má něco fakt konfigurovat, často prostě stejně hodně silná být musí.

[xkucf03]

Podlé mého by konfigurace měla být statická, jak ji napíšeš, takové je, a ne aby se měnila -- skript. Protože když je konfigurace skriptem a potřebuješ, aby se nějak měnila, nebyla statická, supluješ tím nějakou chybějící funkcionalitu toho programu. A od čeho máme open source? Abychom si tam ty funkce mohli dopsat :-)
(tedy do programu, ne abychom museli vymýšlet workaroundy v podobě dybamických konfiguráků)

[Ladicek]

Prosím vás, pošlete tenhle vtip na mailing list Emacsu

[xkucf03]

sorry, emacs nepoužívám

[Ladicek]

To máte jedno, tak třeba Ruby on Rails, Rake nebo nevím jaké programy v Ruby. Tam to dělají taky.

[thingie]

No třeba xmonad. Tam je to velmi výhodné.

[thingie]

Eh, cože?

[xkucf03]

Zrovna dneska jsem si na tuhle diskusi vzpomněl Při upgradu jsem teď musel pracně dávat dohromady (slučovat) změny provedené na datech (uživateli, v produkčním prostředí) a změny provedené v kódu (programátorem). Tohle jsem si mohl odpustit, kdybychom důsledněji oddělili data a programový kód.

[thingie]

Programovací jazyk (definice funkce/metody) je přece něco zcela jiného než dokument (objekty).

To právě pro konfiguraci neplatí. (Ono to teda neplatí pro nic, ale tady to neplatí ještě víc.)

[mirec]

[názov] položka\podpoložka=hodnota

[miso]

Za predpokladu, ze niekde sedi tlupa programatorov, ktori nemaju do coho pichnut to staci

[Ladislav Nešněra]

a existuje nějaký návod, či ještě lépe udělátko , jak ponechat nezbytné minimum?

[miso]

Kedysi existoval projekt KDElight, ktory ako vznikol, tak aj zanikol (casty pripad takychto one-man forkov)

[Ladislav Nešněra]

škoda. Já měl představu nějaké škály od KDEmini po KDEmax, ale už vidím, jak vzniká na toto téma nějaký konsensus.. Každopádně budu rád, když se někdo svou mini verzí pochlubí

[Václav Kramář]

Až bude pro Qt Gimp, tak o tom možná začnu uvažovat. Do té doby...
Navíc závislost značné části QT aplikací na půlce KDE (K3b, K9Copy,...) značně snižuje význam této lehkotonážní alternativy...

[Amarok]

No ja uz postupne zacinam pouzivat "lehci" alternativy. Misto amaroKu zkusim MPD + nejakou nastavbu apod., misto k3b se urcite taky najde plno alternativ (stejne vic nez vypalovani audio/data cd/dvd vetsina lidi snad nepouziva, takze se da teoreticky i ze shellu).

[kavol]

Misto amaroKu zkusim MPD + nejakou nastavbu apod.

a co Qmmp? - tisíce spokojených uživatelů, stovky děkovných dopisů!

[Amarok]

To bych spis zkusil MOC, hledam totiz prehravac v textmodu, prijde mi to proste nejak "vzdusnejsi" :)

[Neel]

ncmpcpp

[xkucf03]

Příloha:

• gimp.png (262734 bytů)

Až bude pro Qt Gimp, tak o tom možná začnu uvažovat.

A nestačí, když vypadá, jako by byl?

[Nicky726]

Co to je za GTK styl, že je tolik podobný Oxygenu?

[vlastikroot]

IMHO gtk-qt-engine

[xkucf03]

Příloha:

• qt-gtk.png (68993 bytů)

A ani není potřeba nic nastavovat. Jen to ještě není úplně dokonalé -- u toho Gimpu je vidět, že některé ikonky vylézají z tlačítek/záložek. Nicméně lepší než dřív -- to jsem radši měl jiný vzhled, protože ta integrace vypadala opravdu hnusně.

[Xgamer]

Tak tento desktop sa mi inak páči;) a to qt4 look zrovna nemilujem ale toto je krásne;)

[mirec]

No tak ja som na tom zhruba opačne ;) Qt 4 look mám rád ale toto je fakt krásne ;) Skulpture je fakt krásna téma a snáď jediná nerozťahaná téma pre KDE 4 / Qt 4 ktorú poznám

[xkucf03]

Dá se, ale stejně zůstávám u Oxygenu (ve 4.2 vypadá líp), ale chybí mi nějaké hezčí okraje oken -- oxygen/ozone se mi okoukal a nic lepšího jsem zatím nenašel.

[Drom]

Skulpture? Hm, to mi pripomina kombinaci Cillop a Smooth pro Gtk+... Hm a jeste neceho...

[mirec]

Mne to pripomína skôr bluecurve. V každom prípade konečne téma ktorá po pár sekundách nastavovania nie je vôbec rozťahaná a zmestí sa aj na menšie monitory (napr. 1280x1024).

[Drom]

Jo jo, takovy ty "velkoformatovy" temata jsou des, nejveselejsi je, kdyz si clovek treba kvuli sirce okraje okna nemuze dat vedle sebe poradne ani dve okna...

[Pietro]

Skulpture je super. Výborné sú aj farebné schémy, ktoré sa s tým nainštalujú, vždy sú perfektne čitateľné.

[JS]

Jednoduche a rychle bylo KDE 1 take. A to je ten trik.

[Riddick]

Wau.. prave bezim na Antico.. je to daco uzasnee... co povedat.. super... inac idem prave skompilovat Antico Deluxe.. ktory vyzera ako macosx

[freshmouse]

To lidem nevysvětlíš, že čím je prostředí rychlejší, tím méně toho zpravidla umí... Oni prostě chtějí nekonečno funkcí v nulové rychlosti. A to je ten trik.

[kavol]

Oni prostě chtějí nekonečno funkcí v nulové rychlosti.

já chci nekonečno funkcí v nekonečné rychlosti - jsem vadnej?

[freshmouse]

Nejsi... Myslel jsem samozřejmě v nulovém čase.

[JS]

Nejde jenom o tohle. Take jde o to, ze Antico muze byt klidne pomalejsi nez KDE, pokud bychom porovnavali porovnatelne.