Konec pomalého překreslování v Qt 4?

Zaměstnanec Trolltechu ve dvou flashových video srovnáních demonstruje výhodu widgetů bez X oken, které v Qt 4.4 mohou přinést velmi výrazně zlepšené překreslování při změně velikosti (bez nežádoucích artefaktů). Kromě toho prý widgety bez oken přinesou i úsporu systémových prostředků.

10.8.2007 05:09 | J. M. | Zajímavý článek

Komentáře

[Ilfirin]

Nějak jsem nepochopil o co jde jak bez X? To nejde ne?

[Radek Miček]

Ale jde, stačí v X mít jen jedno okno a do něj mohou být ostatní widgety prostě jen nakresleny, tudíž když přijde nějaká událost - třeba klik do okna, tak si okno z nějaké šikovné struktuty - třeba BSP stromu zjistí, jaká widgeta na daném místě - na daných souřadnicích - je a jí zašle událost. Zde není vůbec třeba, aby o widgetách uvnitř okna X server něco vědel - stačí jen mít jedno okno, kterému se zašle událost a to už se nějak postará o její distribuci příslušným widgetům. Jediná podmínka je mít u X serveru zaregistrováno to jedno okno uvnitř, kterého jsou widgety - jinak by totiž X server aplikaci žádnou událost nezaslal.

[JoHnY]

Dava to smysl a selskej rozum rika, ze by mela bejt nizsi pametova rezie

[mrzout]

Asi že nejsem sedlák, tak mi to smysl nedává. Protože ono zjišťování, jestli je na dané souřadnici nějaký widget by mělo být IMHO stejně náročné, jako zjišťování X serveru, zda je tam okno. A je-li to rychlejší, bude to pravděpodobně něčím vykoupeno.

No-flame. Předpokládám, že povětšinou to bude přínosem.

[eee]

jiste, napriklad vzdalene spousteni aplikaci bude nahouby, nebude mozne pouzivat soucasne dva monitory, nebo mit treba dve dialogova okna dvou aplikaci vedle sebe a podobne

[mig]

nemam dostatek informaci zrovna o tomhle projektu, nicmene widget a okno neni totez ne? nemyslim, ze by proto nemelo jit pustit "okno" na dalku, jedna se spis o widgety uvnitr okna

[eee]

to neni ta widget ale ten widget

[Lu-Tze]

No moh taky napsat, jaké to bude mít negativní dopady.

Ve windows je třeba možné zjistit jaký text je pod ukazatelem myši, vypsat si podřízená okna. Lze napsat např. aplikaci, která uživateli bude ukazovat překlady hlášek (popisky na tlačítkách, labely, ...), na které najede myší. Možná by šlo i aplikaci za běhu automaticky strojově lokalizovat. Nebo například ty hlášky číst přes syntézu řeči. Něco takového teda nejspíš minimálně v tom qt nepůjde.

Jestli by třeba nebylo lepší zahodit x server. Hlavní toolkity by se změně určitě přizpůsobily a pro zbytek by se vytvořila nějaká emulační vrstva.

[Radek Miček]

Pokud mezi hlavní toolkity počítáte Qt a Gtk, tak už by to s tím přizpůsobením se absenci X serveru neměl být takový problém, jelikož knihovna Gtk to s trochou snahy již umí - projekt GtkFB a co se týká knihovny Qt, tak ta to zatím neumí, alespoň co já vím, ale knihovna Qtopia to již také umí, proto se domnívám, že by nebyl problém tuto funkcionalitu portovat i do knihovny Qt.

[Luboš Luňák]

Qtopia neni knihovna, ale platforma pouzivajici Qt/Embedded. Jinak na to 'zahodit X' si staci najit Googlem jeden z tech asi milion pripadu, kdyz uz nekdo dostal tenhle napad driv.

[Radek Miček]

Qtopia neni knihovna, ale platforma pouzivajici Qt/Embedded.

Díky za opravu, doteď jsem si totiž myslel, že Qtopia je platforma i knihovna, takže jsem zas o něco chytřejší.

Jinak na to 'zahodit X' si staci najit Googlem jeden z tech asi milion pripadu, kdyz uz nekdo dostal tenhle napad driv.

Ale já X nechtěl zahodit, já jenom chtěl upozornit na ten fakt, že by nebyl velký problém obě knihovny zprovoznit i bez něj.

[cynik]

Zahodit xserver znamena z uzivatelskeho hlediska zbavit se takovych zasadnich vlastnosti jako je napriklad sitova transparetnost, relativni nezavislost na hardware, flexibilita v chovani (xserver nepredepisuje napriklad vzhled oken),...

Dodnes se obdivuju fantastickemu geniu autoru X11, kteri v podstate behem asi 5 let (1984-89) vytvorili system, ktery, jak videt zustava u vetsiny lidi nepochopen dodnes.

Pokud se vam zda Qt pomale, zkuste pouzit aplikace pro plain X nebo treba psane v Athene (coz je vzorova implementace toolkitu pro X).. Ja bych nerekl, ze X server to brzdi. Athena ma dneska uz trochu retro vzhled, i kdyz se s ni pracuje docela dobre, ale kdyz se pouziji wxWidgets pro ciste X tak to mozna ukazuje neco zajimaveho.

[martyone]

+1

[Jiří (BoodOk) Kadeřávek]

Proboha, alespoň si přečtěte o čem ta ukázka vlastně je.

[phero]

Klidne tyhle features obetuji, za rychly a hezky prekreslovani.

Nahradit/vylepsit X server? Ukaz kompletni plan, jak bys to chtel udelat, a klidne ti prispeju par rublu na vyvoj.

[Josef Kufner]

K čemu ti bude krásně rychlé překreslování, když byde na serveru v suterénu a ne u tebe na stole? X server není úzké hrdlo a to co by jsi obětoval a co získal je ve značně nevýhodném poměru... vlastně o nějakém získávání ani nelze mluvit.

[Lu-Tze]

Remote Desktop (Protocol) funguje docela dobře, se mi zdá. Takže tahle námitka asi neplatí.

Chtěl bych ale zdůraznit, že já netvrdím, že chci nahradit x window system. Pouze jsem tu myšlenku nadhodil. A o získání samozřejmě mluvit lze - http://en.wikipedia.org/wiki/X_Window_System#Limitations_and_criticisms_of_X

[petris]

Pokud se nepletu, tak RDP neumí přenášet jednotlivá okna, ale pouze celé sezení (něco jako X -query), takže práce s ním je značně nepohodlná.

[Lu-Tze]

Jak velký by byl asi problém, aby to umělo, když existuje třeba seamlessrdp (viz http://www.abclinuxu.cz/blog/RapMan/2007/7/17/187014). Je ale zřejmé, že takto lze upravit každý protokol, stačí pouze navíc přenášet pozice a tvary oken a sychronizovat práci obou správců oken.

[miso]

To znie fakt zaujimavo.
Tiez si myslim, ze X protokol je prilis tucny, vid NX, kde kopec veci neprenasa, posiela fake odpovede a funguje to.

[Jardík]

WDE to tak má už od začátku ...

[Radek Miček]

Adresa má být asi www.wdesktop.org.

[phero]

ale to je oproti QT naprosto nezajimavy

[brk]

A teď tu o červené Karkulce.

[Deleted [8409]]

Jenze to je moje hobby.

Pokud "sam" implementujete toolkit, ktery je oproti Qt zajimavy, tak vam zatleskam. Co treba srovnani designu treba s fltk? Nerikam, ze je Wde knihovna pripravena pro i ten nejjednodussi projekt, ale urcite obsahuje plno dobrych napadu a optimalizaci, ktere by sly vyuzit i v jinych knihovnach.

Ale kratce sem napisu jak jsem postupoval pri implementaci ja:

Je to 2 roky zpatky, co me napadlo zkusit udelat mini-okenni system pod Xlib, ktery by vyuzival jen top-level okna a vsechen "vnitrek" by si uz spravoval sam. Ted to funguje tak, ze kazde top level okno si vytvori double-buffer a zkusi pouzit XShm rozsireni, pro ziskani primeho pristupu. Pokud se nepodari vytvorit XShm pixmapu, alokuje se obycejna pixmapa a XImage, ze ktereho se kopiruji do pixmapy jen ty kousky, ktere se zmenily. Kazde okno si uchovava stavove bity, ktere popisuji, co se v okne zmenilo atd. Tyto bity jsou precteny, pri "update" procesu, ktery se spousti vetsinou po posledni XEvent. Tento proces prochazi jednotlive okna a kontroluje zminene bity a popripade vykresluje jejich obsah. Je zde ovsem par optimalizaci, ktere zabranuji zbytecnemu prochazeni podoken ktere nepotrebuji nic (jsou validni).

Jsem se rozepsal:) Kdyby nekoho zajimalo vic, muze mi napsat mail, na toto tema velmi rad pohovorim:)

[Petr Tomášek]

Áááá... tak v zatroleným techu objevili něco, co GTK+ používá už dáávno...

[Ctirad Feřtr]

Škoda, že to na to na rychlosti překreslování není vidět.

[Filip Jirsák]

To tady opravdu všichni souhlasí s tím, že vykreslování widgetů bez podpory X je výhoda? Podle mne, pokud to opravdu přinese zrychlení, znamená to pouze že je cosi shnilého v X serveru. Jediný omluvitelný důvod by byly třeba neobdélníkové widgety nebo průhlednost, ale to je potřeba s tím naučit zacházet X server, ne jeho práci emulovat. Knihovna pro widgety totiž stejně musí dělat to samé, co X server – pamatovat si, kde je který widget umístěn, při kliknutí myší poslat zprávu tomu správnému widgetu, při překreslení oblasti překreslit ty správné widgety atd. Nevidím jediný důvod, proč by to knihovna měla dělat lépe než X server.

[Lu-Tze]

To tady opravdu všichni souhlasí s tím, že vykreslování widgetů bez podpory X je výhoda?

Podle toho komentáře se zdá, že s tím souhlasím? Mmm...

[Filip Jirsák]

Jste výjimka potvrzující pravidlo

[Deleted [8409]]

Treba je pomala uz ona komunikaze mezi aplikaci (toolkitem) a X serverem.

[Filip Jirsák]

K takové pomalosti je nějaký principiální důvod? Nebo je ta případná pomalost způsobená jen špatnou implementací? Teda jestli se teď linux zbaví X, a za pár let Windows něco takového s velkou slávou implementují, protože to je a bude nutnost pro implementaci GUI akcelerovaného grafickými kartami a schopného bez problémů pracovat ve virtuálních strojích, bude to opravdu smutné…

[Deleted [8409]]

Ano je, predstavte si, ze mate treba 200 vnitrnich oken.

Kdyz chtece kazde okno namapovat, tak server vygeneruje 200 udalosti, pri prekresleni dostane kazde okno opet dalsi udalost (200), a to nemluvim o tom, ze nekdo bude presouvat jine okno pres vasi aplikaci. Kdyz nekdo zvetsi top-level okno a vy budete chtit prizpusobit layout, tak rozeslete 200 pozadavku, a budete cekat az vam ty "pozadavky" prijdou zpet (jako Configure a Expose udalosti).

Toto vsechno se tim proste eliminuje a knihovna si sama posle udalosti, ale tak, jak je to pro ni vyhodne a pokud mozno si sama optimalizuje urcite useky.

[Filip Jirsák]

Pokud někdo přesouvá jiné okno přes aplikaci, zajímá mne maximálně poloha myši, pokud jde o drag-and-drop. Z pohledu překreslování není potřeba dělat nic, aplikace má překreslovat jedině v případě, že ona sama mění vzhled. Jinak ať si to vyřeší X server a obnoví obraz z cache. Zvětšení layoutu je horší problém, protože tam to tradičně dělá aplikace a knihovna, přestože koncepčně by to také mělo patřit do kompetence X serveru. Jenže layout manažerů je možné si navymýšlet nekonečné množství, tzn. aplikace by musela mít možnost vedle resourců poskytnout X serveru i své layout manažery, což je dnes sci-fi.

Problém v zasílání 200 událostí v rámci knihovny nebo mezi knihovnou a X serverem je problém meziprocesové komunikace, což by asi bylo lépe řešit tam, případně optimalizací X protokolu, než tím, že spolu aplikace, X server a GPU nebudou mluvit a budou se navzájem trumfovat velkými bitmapami.

[Deleted [8409]]

1) Pokud nekdo presouva jine okno pres aplikaci, tak v pripade ze neni double-buffer posila X server Expose udalosti pro kazde subokno zvlast (coz muze zvysit traffic ze?)

2) Layout na strane X serveru je opravdu SCI-FI a blbost. Vzdyt X server vidi jen okna, nic vic, tak jak by je mohl rozlozit? Navic je to specificke pro kazdy toolkit a widget.

3) Nevidim problem v tom, ze bude aplikace mene mluvit s X serverem, je to spis vyhoda, 99.X% uzivatelu pouziva iXa pro desktopove ucely a tady se to zrychleni projevi (rychle prenest bitmapu pomoci XShm neni problem)

4) Definujte pojem "velka bitmapa"

[Filip Jirsák]

Asi nebude náhoda, že jedno z nejčastějších témat v LKML je virtualizace. Rovněž nebude náhoda, že se v poslední době roztrhl pytel s různými technologiemi „aplikací přes web“ – ať už je to AJAX, MS XAML, Adobe FLEX nebo JavaFX. A do třetice nebude náhoda, že se kompozitní manažery (nebo Windows Aqua) objevují právě teď – je to využití schopností akcelerovaných GPU pro desktop.

První dvě věci znamenají, že se opět na scénu dostávají tencí klienti. A tentokrát už to není zajímavý koncept, ale dokážeme to technicky opravdu udělat. První a třetí věc naopak souvisí s tím, že onen tenký klient už není pouze hloupý terminál, který má klávesnici, myš a monitor a nic neumí. On ten tenký klient je ve skutečnosti nadupaný počítač s několikagigahertzovým a postupně vícejádrovým procesorem, dostatkem RAM, velkým harddiskem a akcelerovanou grafickou kartou, která zvládá počítat složité 3D scény v reálném čase. Tzn. výhoda tenkého klienta není v tom, že by se ušetřilo na železe klienta, ale v nižších nákladech na údržbu celého systému – aplikace se instaluje jednou na nějaký server, pokud odejde železo na tenkém klientovi, vezmu jiné a připojím se na stejný server a pokračuji v práci atd.

To dohromady ale znamená, že se vyplatí nechat práci související s GUI na klientovi – a to ne způsobem „tady máš bitmapu a tu kresli do tohohle okna“, ale „tady je tlačítko, které normálně vypadá takhle, zmáčknuté vypadá takhle“. A když uživatel najede nad tlačítko a klikne myší, klient pošle aplikaci zprávu ale zároveň sám překreslí tlačítko do zmáčknutého stavu. Mimochodem, přesně takhle funguje AJAX – tam je tenkým klientem webový browser, a aplikace se vůbec nestará o to, že by měla překreslit tlačítko, když na něj uživatel kliknul – o to se stará právě tenký klient. Jediný problém je v tom, že pro popis GUI se používá HTML místo nějakého jazyka na popis GUI. Přičemž dobrý jazyk na popis GUI nemůže být pouze deklarativní (takže to nesplňuje ani třeba XUL), protože součástí popisu GUI musí být i layout manažer, který musí být procedurální. Jeden univerzální layout manažer (jako má XUL), případně navržený k úplně něčemu jinému (jako je „layout manažer“ HTML) evidentně nestačí.

Takže 99 % uživatelů používá a bude používat X pro desktopové účely, ale to neznamená, že 99 % aplikací běží a bude běžet na stejném fyzickém počítači, kde se pak GUI zobrazuje.

Tohle všechno dnešní X server ani X protokol samozřejmě neumí. Ale jeho koncept grafických primitiv a oken je k tomu rozhodně blíž, než „tady máš bitmapu, a kdyby něco, tak řekni, a já ti jí nakreslím změněnou znovu“.

[Deleted [8409]]

ad prvni odstavec:

Myslim, ze pletete jablka z hruskama. AJAX nema nic spolecneho s X serverem atd (ale verim ze to byl dobre mysleny priklad). Aplikace prece ma pravo si renderovat nejake prvky sama a zamlcet existenci nekterych prvku X serveru.

ad zbytek:

Pokud si budu poustet X server a zpoustet vzdalene aplikace, tak mi prece vubec nemuze vadit, ze cilova aplikace mi posle vzdy bitmapu toho, co se zmenilo. Staci si nastavit lehci tema (mene prechodu a obrazku) a RLE komprese zaruci velmi dobry vysledek.

Obrazky zmacknuteho a nezmacknuteho tlacitka muzete poslat X serveru jako pixmapy a pak je jen pouzit pri vykreslovani. Nevidim v tom problem, pismo se posila podobnym zpusobem (viz Xft).

ad 99%:

Pokud udela Trolltech neco, co temto 99% uzivatelum zvysi rychlost vsech Qt a KDE aplikaci, tak je to podle me uzasna vec. Linux je spojovan s "pomalym GUI" a kazde zrychleji na desktopu je dobre (no flame).

ad "Tohle všechno dnešní X server ani X protokol samozřejmě neumí":

X server vyuziva primitiva k tomu, aby je nakreslil, nevi nic o tom, co ve kterem okne je, atd.

[Filip Jirsák]

Aplikace si samozřejmě může všechno kreslit sama a zamlčet X serveru (ať už dnešnímu, nebo nějakému budoucímu, který bude umět zacházet opravdu s objektu GUI) pravou podstatu těch objektů. Ale pak se nemůže divit, že nemůže využít výhod, které X server nabízí. Třeba uživatel, který špatně vidí, bude chtít všechno zvětšit. Když bude o něčem X server vědět, že je to tlačítko, a bude vědět, jak tlačítko namalovat, namaluje ho zvětšené. Když ale o nějaké aplikace bude mít pouze bitmapu, musí prostě jen zvětšit bitmapu, což samozřejmě nebude moc estetické. To samé při mapování okna na stěnu krychle při přepínání ploch – nakreslit tlačítko v perspektivě jde samozřejmě lépe z vektorové předlohy než pouhou deformací bitmapy. Hlasová čtečka taky asi lépe přečte text, o kterém X server ví, že je to text, než když musí text z bitmapy získat přes OCR. A tak dále. Metoda „aplikace si vše kreslí sama, X serveru do toho nic není“ samozřejmě možná je, ostatně v DOSu si většina aplikací vše kreslila sama. Ale tohle řešení je dočasné nečisté řešení z dob, kdy to jinak nešlo. Ale nemyslím si, že by se vývoj měl k tomuto způsobu vracet.

Staci si nastavit lehci tema (mene prechodu a obrazku) a RLE komprese zaruci velmi dobry vysledek.

To je přesně to, čemu je potřeba se vyhnout. Dneska je uživatel zvyklý na to, že GUI aplikace pěkně vypadají a jsou interaktivní. Omezenost AJAXových aplikací zatím uživatelé tolerují, protože přístup odkudkoli tuto nevýhodu (zatím) vyváží, navíc AJAXové aplikace (nebo obecně tencí klienti) se používají na aplikace s jednoduchým GUI. Takže zatím to uživatelé tolerují. Ale „nastavte si jednoduché hranaté ošklivé téma“ rozhodně není marketingový hit, kterým přesvědčíte uživatele.

[Deleted [8409]]

Mate krasnou predstavu, ale je to nerealne. X server je okenni system, nic vic, nic min. Aplikace ho pouzivaji k vytvareni oken, podoken, ... To znamena, ze i dnes je prakticky jedno, jestli aplikace X server pouziva k vytvareni podoken, nebo si zvoli svuj zpusob a vytvori jen top-level okno a tim se vyhne zbytecne komunikaci.

To s tim lehkym tematem jsem myslel tak, ze pro vzdaleny pristup si nastavite lehke tema (prece nema cenu prenaset nejake slozitejsi pozadi po pomale lince:D ).

PS 1: Doufam ze si nepletete X server a webovy prohlizec PS 2: A jake ty vyhody mi X server nabizi?

[Filip Jirsák]

Doufam ze si nepletete X server a webovy prohlizec

Nepletu. Jenom si jaksi nemůžu nevšimnout, že se webový prohlížeč dnes často používá k tomu, k čemu byl zamýšlen X server. A používá se k tomu mimo jiné právě proto, že umí nakreslit třeba tlačítko a postarat se o něj komplet – na kliknutí zareagovat jeho překreslením ve zmáčknutém stavu, na získání focusu reagovat vykreslením rámečku atd. Webový prohlížeč ale není ten správný nástroj, který by tohle měl dělat – tohle je úloha právě pro X server (nebo nějakého jeho nástupce).

Mimochodem, když jste takový zastánce obrázků – proč se někdo vůbec patlá s nějakými webovými stránkami a webovými aplikacemi v HTML? Vždyť by stačilo na serveru vše vyrenderovat jako obrázek a poslat to do prohlížeče, ne? Odpadly by problémy s různými nekompatibilitami prohlížečů. Aby bylo jasné, kam tím mířím, a abych zase nebyl podezírán ze záměny X serveru a webového prohlížeče – jaký je pro uživatele rozdíl mezi Thunderbirdem a Gmailem? Nechtěl by nakonec uživatel aplikaci, kterou bude mít dostupnou odevšad s nějakým minimálním vybavením (jako je Gmail), ale zároveň interaktivní a s propracovaným GUI, jako je (ehm, skoro) Thunderbird?

[thingie]

Knihovna si svoje widgety musí pamatovat stejně, jinak z nich okna neudělá a nenakreslí. Když se na to podívám opačně. Proč bych měl X serveru zbytečně sdělovat kde co mám a co to je. Pošlu mu pixmapu jak vypadám a to stačí. Pozorovatelný rozdíl na straně uživatele? Není...

[Filip Jirsák]

Protože X server ty informace může použít pro optimalizaci, může je použít při komunikaci s grafickou kartou. S čím si asi poradí grafická karta líp – s pixmapou, kterou může zvětšovat jako bitmapu, nebo kterou musí znova namalovat ve větším toolkit, nebo s grafickými objekty, které může namalovat znovu větší grafická karta sama bez jakékoli účasti CPU, RAM a případně sítě? Podle mne je X protokol (možná s nějakými změnami) ideální pro to, co se dá na desktopu v příštích pár letech očekávat – aplikace běží v nějakém virtuálním počítači, ať už lokálně nebo po síti, zadává příkazy, co se má vykreslit, a GPU u uživatele tyhle příkazy zpracovává a výsledek maluje a monitor.

[Deleted [8409]]

Ja bych rekl, ze bude lepsi a vzdycky rychlejsi renderovat pomoci openGL jedno top-level okno, kde si aplikace nasklada vsechny podokna a popripade vyresi kolize, nez desitky suboken + kazde zvlast (takze kolize bude resit az openGL).

[Filip Jirsák]

OpenGL řeší kolize s procesorem, který je k tomu určený, knihovna v aplikaci to řeší s CPU. Pokud je potřeba překreslit okno, musí aplikace vytvořit bitmapu, kterou (třeba po síti) pošle k zobrazení – to samé opět zvládne GPU. Pokud je potřeba na okno aplikovat nějaký efekt (à la Beryl), musí ten efekt buď umět udělat aplikace (a opět s CPU a přenosem bitmapy), nebo to udělá GPU na bitmapě, kterou má v paměti – se všemi důsledky plynoucími z transformace bitmapového obrázku. A nebo to opět jednoduše GPU spočítá z vektorů. Všimněte si, že GUI se skládá hlavně z vektorů, dokonce už i ikony se dělají vektorové. Drtivá většina problémů s použitelností GUI je dána tím, že je někde něco přesně pixel na pixel (typický příklad je velikost fontu na webové stránce) – což zase plyne z toho, že se ty vektory převádějí na bitmapu zbytečně brzo. Když už tedy konečně GPU mají možnosti zpracovávat vektorové GUI samostatně, když už se to konečně učí aplikace a knihovny používat, bylo by nesmyslné zahazovat princip X serveru, který přesně tenhle způsob práce s GUI předvídal.

[Miloslav Ponkrác]

Já si taky myslím, že X server určitě může optimalizovat daleko lépe, než nějaký toolkit. Určitě v X serveru je větší potenciál pro optimalizaci, než v nějaké Qt knihovně.

[thingie]

No, předvídal. Ono jsou to furt jenom stupidní X okna, bez aplikace se toho zase moc nedokáže.

[Filip Jirsák]

Řešení je ale v tom, že se X server o tom okně dozví víc, ne míň. Pak teprv totiž může lépe optimalizovat. A X server a GPU má rozhodně lepčší předpoklady k optimalizaci, než knihovna nebo aplikace. Asi je zbytečné, aby aplikace počítala antialising, když nic netuší o zobrazovacím zařízení, netuší, zda se vůbec něco zobrazuje, a zda třeba není schovaná za z 95 % neprůhledným oknem, takže je úplně jedno, zda je čára hladká nebo zubatá.

[Deleted [8409]]

Antialiasing si aplikace stejne pocita sama, aspon u pisma.

V dnesni dobe je aplikaci celkem jedno, kolik prostoru prekryva jine okno, protoze si vytvari double-buffer bud klient nebo samotny X server.

[Filip Jirsák]

Antialiasing si aplikace stejne pocita sama, aspon u pisma.

No právě, to je špatně. Co s tím pak má chudák X server dělat, když už to dostane zmršené od aplikace? To pak uživatel klidně může po X serveru chtít zvětšit (lupou) okno, ale když tam X server má jenom černé fleky s duhovými okraji, zpátky z toho nevyčaruje písmo, které by teď mohl vykreslit s daleko prokreslenějšími detaily.

[Miloslav Ponkrác]

Proboha a jak aplikace může vědět, jaké je zobrazovací zařízení? Což je potřeba na kvalitní antialiasing. Ani nemůže vědět nic o měřítku ve kterém X server zobrazuje. Tedy samozřejmě API tyto informace částečně posktytne, ale není to ptákovina? Tohle je vysloveně kontraproduktivní, o antialiasing a další věci se odjakživa staralo grafické jádro, nikdy ne aplikace.

[Deleted [8409]]

Tak si zjistete jak funguji knihovny FontConfig a FreeType a treba se mrknete do zdrojovych kodu Xft, kde jasne uvidite, ze si pismo renderuje klientska cast a posila jiz hotove bitmapy X serveru, ktery je pomoci XRender rozsireni zobrazi.

[Miloslav Ponkrác]

Opravdu?

[Deleted [8409]]

Je to proste nutnost, pokud chcete pouziv vyhlazene pismo, tak to akceptujte.

[thingie]

No nevím. Pokud si pamatuju, tak X protokol byl z dobové konkurence spíš ten hloupější. Rozhodně nic proti interpretru postscriptu, který toho může dokázat opravdu hodně. A vývoj k tomu moc nesměřuje. Což je otázka proč, pokud by to bylo tak přínosné. (což možná asi je)

[Jiří (BoodOk) Kadeřávek]

Konečně rozumná reakce. Viva tenký klient! Proč? Protože X se používá většinové v LAN a tam od něj skutečně očekávám otrockou práci. Pokud někdo chce řešit antialiasing na úrovni plátna ... OK, ale já žádnou elektroniku do plátna nechci. Mimochodem, historie se opakuje, tlustí klienti jsou jaksi ... nepopulární.

[Deleted [8409]]

Tak jinak,

davate zde jako priklad Beryl. Ono tyto kompozitni managery funguji tak, ze si top-level okno aplikace ulozi do pixmapy a pak s nim pracuji jako s obrazkem (takovy double-buffer). Takze kdyz bude mit aplikace jen jedno top-level okno a jeho obsah posle X serveru, tak to bude pro X server (a Beryl) mnohem rychlejsi, nez aby si tuto pixmapu zpetne sestavoval z X dalsich podoken ne?

Uzivatele Qt a KDE se proste dockaji vyborne optimalizace.

[Filip Jirsák]

Ale to, že má kompozitní manažer uložené okno jako jeden velký bitmapový obrázek je jeho největší nevýhoda. A to jedinou příčinu – aplikace mu zatím nedokážou poskytnout informace o svém vzhledu jiným způsobem. Ano, nemůžete se to zastavit u toho, že budou jednotlivé widgety jednotlivá okna, kam aplikace namaluje nějaký obrázek, ale musí to pokračovat dál, tj. aplikace popíše (vektorově) i ten samotný widget. S tím už si pak může třeba Beryl dělat, co s mu zlíbí, a všechno bude fungovat i když aplikace poběží třeba namotaná na spirále.

Jinak s tím nápadem, že si bude aplikace malovat vše sama, přišla už například Mozilla. Přičemž je to jedna z jejich největších slabin. Pak s tím přišla Java ve Swingu, a všichni pak Javovským aplikacím vytýkají, že nezapadnou do systému, případně že mají pomalé GUI (a to je ještě Swing dobře vymyšlený a snaží se různé neduhy plynoucí z toho „já sám“ eliminovat). Další kdo s tím přišel bylo eclipse a SWT, které nepoužívá „nativní“ Javovské widgety ale nativní widgety systému (což je z pohledu Javy opět „já sám“), přičemž mám pocit, že SWT je opět nejslabší článek aplikací, které jej používají.

Pokud je hlavním cílem Qt být nezávislá na platformě i za cenu zpomalení a „nezapadnutí“ do sytému (nejen po stránce „look“, ale i „feel“), pak je to asi správné rozhodnutí – i když podle mne je jenom dočasné. Trochu jsem tím i zklamaný, protože osobně jsem Qt tipoval na toho, kdo by mohl posunout desktop od toho starého zobrazování bod po bodu na VGA k využití možností dnešních grafických karet k vektorovému desktopu. Dá se to očekávat od Applu, Windows s tím budou muset přijít taky, tak by nemusel být Linux ten třetí vzadu, ne? První krok se povedl celkem dobře, ale aby to tím neskončilo…

[Deleted [8409]]

Jenze X Server neni zadny vektorovy graficky server. Stara se o pixely tak mu aplikace musi ty pixely poslat, nebo poslat co se ma kde rasterizovat. Podle me by X server vubec nemelo zajimat, co se v dane aplikaci nachazi, to je ciste vec aplikace a tento obsah se muze menit.

Ja nepouzivam javu, netroufnu si tvrdit co je v jave pomale nebo rychle (mozna je to Java). Ale Qt proste zadne zpomaleni nehrozi, prekreslovani bude rychlejsi a to je duvod celeho pocinu:)

Navic urcite bude existovat v Qt moznost, pouzivat legacy mod vytvareni X oken, takze si ho pak muzete zapnout --- ale troufam si tvrdit, ze to neudelate

[Filip Jirsák]

Jenze X Server neni zadny vektorovy graficky server. Stara se o pixely tak mu aplikace musi ty pixely poslat, nebo poslat co se ma kde rasterizovat. Podle me by X server vubec nemelo zajimat, co se v dane aplikaci nachazi, to je ciste vec aplikace a tento obsah se muze menit.

X Server je právě „podobojí“, část je vektorová (např. právě okna) a část bitmapová. Budoucnost je podle mne ve vektorovém GUI, a cesta „část vektorová, část bitmapová“ k vektorům přes plně bitmapový desktop mi připadá trochu zvláštní

[Deleted [8409]]

No ja programuju pomoci Xlib uz pomerne dlouho a zadnych vektoru jsem si nevsiml. Souradnice a velikost oken je vzdy v pixelech, vsechny primitiva jsou v pixelech tak kde je tavektorova cast :) ?

[Filip Jirsák]

Ta okna a ta primitiva

[Petr Tomášek]

Dá se to očekávat od Applu, Windows s tím budou muset přijít taky, tak by nemusel být Linux ten třetí vzadu, ne? První krok se povedl celkem dobře, ale aby to tím neskončilo…

Naštěstí linux != KDE/Qt... (Vývoj gtk založeného na CAIRu mi v tomto příjde docela slibný...)

[Filip Jirsák]

Naštěstí linux != KDE/Qt... (Vývoj gtk založeného na CAIRu mi v tomto příjde docela slibný...)

To jsem rád, tenhle vývoj jsem nezaznamenal. Tak alespoň něco nadějného…

[thingie]

Jenže pokud máme fakt složitou a nepředvídatelnou věc -- a to budeme mít, se podívejte co dneska lidi píší za zrůdy, tak možná fakt nemá cenu o tom X server zpravovat. Vytváří Doom okno pro každou potvoru, aby ji moh hráč zabít? Ne-e. Bych řek, že to bude stejně i na desktopu, jednou.

Tím nemyslím, že by mě to těšilo.

[Radek Miček]

Já to vidím jinak, knihovna si sice pamatuje informace o svých widgetech, ale když uživatel někde klikne, tak knihovna již nemusí počítat, kde to bylo, a zasílat widgetu událost sama, namísto toho toto může počítat (a také počítá) X server nějakým efektivním algoritmem, který zvládne tisíce widgetů.

[Deleted [8409]]

a co treba list view, tree view nebo dalsi komplexni widgety? Xlib je nizkourovnova vrstva a toolkit bude muset vzdycky pocitat, navic zjistit, pod krerym detskym oknem se momentalne nachazi kurzor mysi je pro toolkit naprosta malickost.

[Radek Miček]

zjistit, pod krerym detskym oknem se momentalne nachazi kurzor mysi je pro toolkit naprosta malickost

to je právě to, co si nemyslím, při větším počtu widgetů už se vyplatí použít nějaký rafinovaný algoritmus, zanedlouho bude také možné použít pro některé výpočty přímo grafickou kartu (ono už to možné je - viz. např. nejnovější počiny NVIDIE), k níž má přístup X server, takže by pak CPU nebylo vůbec zatěžováno, těchto výhod bychom bez X serveru jen těžko mohli v budoucnu využít

a co treba list view, tree view nebo dalsi komplexni widgety?

Tam už musí počítat knihovna, to je pravda.

[Deleted [8409]]

Pri vetsim poctu widgetu bude pro aplikaci vyhodnejsi, kdyz si je bude spravovat sama, protoze si ten algoritmus muze implementovat a optimalizovat pro sve potreby, neni tak?

Kdyby nebyl toolkit schopny urcit pod kterym detskym oknem je mys, tak nevim jak by fungovala treba propagace udalosti ( tu si uz resi toolkit sam, pokud vim:) )

[Filip Jirsák]

Pri vetsim poctu widgetu bude pro aplikaci vyhodnejsi, kdyz si je bude spravovat sama, protoze si ten algoritmus muze implementovat a optimalizovat pro sve potreby, neni tak?

Není Protože pak každá knihovna bude mít svůj algoritmus, který musí počítat naslepo (aniž by cokoli tušil o zobrazovacím zařízení nebo ostatních oknech). Zatímco X server má právě přehled o celém desktopu, takže dokáže daleko lépe určit, co je nutné kreslit a co ne. Navíc způsobu, jak dělat knihovny widgetů, není zas tolik, aby ty knihovní algoritmy byly nějak moc rozdílné. Takže ten optimalizovaný algoritmus by byl ve všech knihovnách plus mínus stejný – no a to může být rovnou v X serveru.

[Deleted [8409]]

Není Protože pak každá knihovna bude mít svůj algoritmus, který musí počítat naslepo (aniž by cokoli tušil o zobrazovacím zařízení nebo ostatních oknech).

- Predstavte si, ze by WWW prohlizec posilal kazdy TAG X serveru.

- Aplikace si prece muze zjistit informace o zobrazovacim zarizeni a pozadovanem vystupu (treba pismo pomoci FontConfig(u), bitova hloubka, rozliseni, DPI, ...)

Zatímco X server má právě přehled o celém desktopu, takže dokáže daleko lépe určit, co je nutné kreslit a co ne. Navíc způsobu, jak dělat knihovny widgetů, není zas tolik, aby ty knihovní algoritmy byly nějak moc rozdílné. Takže ten optimalizovaný algoritmus by byl ve všech knihovnách plus mínus stejný – no a to může být rovnou v X serveru.

V dobe double-bufferu nema smysl urcovat, co je treba prekreslit a co ne, proste se pouzije double-buffer a aplikace o prekresleni ani nemusi vedet (viz nektere jine prispevky)...

[Jiří (BoodOk) Kadeřávek]

Jenže zde je filosofický rozdíl. F. Jirsák si myslí, že X je celé kino (si vybírá co kdy a v jakém formátu bude hrát), zatímco my si myslíme, že X je plátno (hrajeme co na nás promítají). Který pohled je ten správnější? Těžko soudit.

[Miloslav Ponkrác]

(ironie) Já bych to rozšířil - každá apliakce by mohla implementovat svoje vlastní řešení threadů, sama si plánovat procesy, protože to určitě dokáže lépe, než operační systém. Tak by mohla sama spravovat hw prostředky - konekonců kdo to umí lépe, než aplikace, že? (/ironie)

Ne, žádná aplikace určitě nemá ty optimalizační možnosti, jako má daný X server. I když připouštím, že určité kroky na straně aplikace jsou vhodné, rozhodně se to nemá přehánět. X server není žádný blbeček, který by z principu všechno brzdil.

[Deleted [8409]]

(ironie) Co takhle implementovat aplikace primo do iXek? (/ironie)

[Miloslav Ponkrác]

Já stejně nevím, co Vás vede k tomu, že obhajujete práci za specializovaný server, v tomto případě X server.

Dělá snad někdo to, že třeba aplikace dělá práci za databázový server? Nedělá, protože databázový server prostě umí optimalizovat nesrovnatelně lépe (nebo alespoň dobrý db server), než to kdy může dokázat aplikace.

A já nechápu, proč by měla aplikace dělat práci za grafické jádro,když právě ono má nsrovnatelné možnosti optimalizace, o které se aplikaci ani nezdá, včetně využití možnosti grafického hw.

[Jiří (BoodOk) Kadeřávek]

Jenže, máte MySQL, který někteří nazývají databázovým filesystémem, a máte PosgreSQL, který se nikdo nebojí nazvat rdbMs (fanouškům oRacle, mSSql aj. se omlouvám). A kupodivu, své místo mají oba. Takže, kde je ta správná hranice u X aka Db?

[Miloslav Ponkrác]

Nejde o to, kolik db se používá, ale o to, že práci s daty neřeší aplikace. To jsem alespoň svým příspěvkem chtěl sdělit. Mnohým aplikacím stačí třeba nějaká malá embedded databáze, třeba sqlite.

[Radek Miček]

Kdyby nebyl toolkit schopny urcit pod kterym detskym oknem je mys, tak nevim jak by fungovala treba propagace udalosti ( tu si uz resi toolkit sam, pokud vim:) )

Pokud vim, tak nektere udalosti posila widgetum primo X server a toolkit je jen preklada na neco srozumitelnejsiho, pripade na zaklade nich generuje dalsi udalosti.

Tento koncept je pekne videt na knihovne GTK, kde je kazdy objekt window X serveru obalen GdkWindow a u kazde widgety z GTK na pozadi stoji prave jiz zmineny GdkWindow. Je tam take patrne rozliseni udalosti, ktere jdou z X serveru - napr. expose-event a signálů, které už z X serveru nejdou, ale jsou syntetizovány na základě událostí X serveru - např. clicked.

[Deleted [8409]]

No jo, ale ja myslim propagaci udalosti, ktera prisla z X serveru. Prijde mi treba udalost "Zmacknuta klavesa X" a dane okno ji nezpracuje (nechce ji), tak toolkit tuto udalost propaguje urcitym smerem dal do jinych oken (vetsinou asi rodic).

A rozsirit zmineny model, aby se staral i o detske okna nebude pro Qt problem, protoze uz to maji implementovane v Qtopia (QWS)

[Radek Miček]

No jo, ale ja myslim propagaci udalosti, ktera prisla z X serveru. Prijde mi treba udalost "Zmacknuta klavesa X" a dane okno ji nezpracuje (nechce ji), tak toolkit tuto udalost propaguje urcitym smerem dal do jinych oken (vetsinou asi rodic).

Ano, vetsinou jde udalost smerem k rodici, jenze ja reagoval na nasledujici tvrzeni:

Kdyby nebyl toolkit schopny urcit pod kterym detskym oknem je mys, tak nevim jak by fungovala treba propagace udalosti ( tu si uz resi toolkit sam, pokud vim:) )

Toolkit totiz pri "zmacknuti klavesy X" nepotrebuje vedet, nad kterou widgetou je mys, protoze mu staci vedet, ktera widgeta ma focus.

[Deleted [8409]]

Toolkit totiz pri "zmacknuti klavesy X" nepotrebuje vedet, nad kterou widgetou je mys, protoze mu staci vedet, ktera widgeta ma focus.

Mel jsem spis napsat, co kdyz zmacknu tlacitko mysi (treba rolovaci tlacitko), tady uz je to snad vice logicke:)

[Radek Miček]

Mel jsem spis napsat, co kdyz zmacknu tlacitko mysi (treba rolovaci tlacitko), tady uz je to snad vice logicke:)

Jenze, kdyz zmacknete tlacitko mysi nebo hybnete mysi, tak tu udalost te widgete nad kterou je ukazatel mysi posila opet X server. Jmenovite: button-press-event, button-release-event, pripadne motion-notify-event.

[Deleted [8409]]

Ale pokud ji dany widget nezpracuje, tak muze tuto udalost propagovat rodici, a toto uz dela toolkit.

[Radek Miček]

Ano, toolkit propaguje nektere udalosti rodici, ale na to uz nemusi pocitat pozici rodicovske widgety.

[Radek Miček]

Souhlasím s vámi, že by bylo mnohem lepší, aby se případně vylepšil raději kód v X serveru, než aby si vývojáří každé knihovny dělali vlastní implementaci. Nicméně se vývojářům Trolltechu ani moc nedivím, proč by měli vylepšovat X server, když mohou vylepšit svou knihovnu, což jim navíc může přinést zvednutí výkonu nejen pod Linuxem.

[Deleted [8409]]

Pokud jsem cetl spravne tak na vsech platformach. navic to otevira vratka i ostatnim vecem, jako je kompozice a pruhlednost detskych oken, ktera bude platformne nezavisla (o tom tam sice neni zminka, ale verim ze neco takoveho udelaji)

[Miloslav Ponkrác]

Na všech platformách určitě nikoliv. Třeba na Windows leccos vykresluje systém sám bez podpory aplikace, nebo nějaké knihovny toolkitů. Takže pokud si nějaká knihovna bude něco kreslit sama, může se jí velmi snadno stát, že bude vypadat jako pěst na oko odlišně od běžných aplikací. A tipnul bych si na Mac OS X (pokud se nepoužije X server) že bude situace obdobná. Takže leckde bude tento postup kontaproduktivní, sice to bude platformě nezávislé, ale také budou okna vypadat pěkně pitomě, repsektive slušně řečeno jinak, než by v systému měla vypadat.

[Deleted [8409]]

Cetl jste poradne ten blog?

Pise se tam:

"tato technika umozni ve Windows vytvorit mnohem vice podoken nez bylo doted mozne"

Ackoliv se to nezda, tak Qt si ve windows kresli widgety samo. WinAPI ma funkce, pomoci kterych lze ten jednotny vzhled docilit.

[Miloslav Ponkrác]

Pokud si Windows kreslí widgety samo, tak jednou v nějaké další verzi to bude jako pěst na oko. Ne, Win API nemá funkce na docílení jednotného vzhledu, má své vlastní grafické prvky, které se umísťují jako samotnatná grafická podokna. Jinak nevím o nějakém závažném limitu počtu podoken v současných Windows, na které by jakákoli aplikace mohla kdy narazit.

[Deleted [8409]]

Ale Qt tyto specialni podokna nepouziva, pouziva obycejne CHILD a kresli si obsah samo uz dnes. Navic jak jsem psal, WinAPI obsahuje funkce, pomoci kterych lze kreslit temata i do vlastnich oken a bitmap bez vytvareni danych oken.

[Miloslav Ponkrác]

Ale samozřejmě, že kreslit jde všude pomocí Win API. Ale nezapadne to do systému. Protože Qt pak dopadne jako staré Delphi aplikace, které si sem tam něco nakreslí samy (tedy emulují systémový toolkit) a kdysi, když to programovali, tak to zapadalo do systému. Jenže Windows dnes vypadá kapku jinak a tak je to jako pěst na oko. Ne, nenajdete ve Windows způsob, jak vlastním kreslením dokázat, že to bude vypadat stejně jako zbytek Windows a jako jiné nativní aplikace Windows. Jde to hladce jen jediným možným způsobem - bude používat Windows toolkity jako podokna. Protože mi tvrdíte opak, prosím o zdrojový kód aplikace pro Windows, která všechno kreslí do jednoho top level okna a zaručuje, že dnes i kdykoli v budoucnu bude alikace vypadat konzistentně se zbytkem systému. Vím dobře, že to je nemožné.

[Deleted [8409]]

Pokud je pravda, co rikate, tak by Qt nemohlo ve Windows vypadat nativne. Jsem si 100% jist, ze bude vypadat nativne i kdyz bude systemove jen jendo top-level okno.

Toto je z wiki: Qt comes with special styles for Mac OS X and Windows XP that use native APIs (Appeareance Manager on Mac OS X, UxTheme on Windows XP) for drawing standard widget primitives (e.g. scrollbars or buttons) exactly like any native application.

Zatim neznam zadny one-top-level-window toolkit ktery by vypadal nativne pod windows (ani po nem nepatram, protoze stejne vypada kazda aplikace jinak), ale Qt 4 .4 bude mit urcite brzy tu moznost

[Miloslav Ponkrác]

ad 1) Ono to taky nativně bude vypadat jen v určité verzi Windows a jen se standardním skinem, pokud Qt nahrazuje práci grafického jádra Windows. Klidně se Vám podepíšu pod to, že když binárku používající Qt knihovnu (pokud tedy dělá to co píšete) pustíte za několik let na další verzi Windows, že bude grafika jak pěst na oko a rozhodně nebude vypadat nativně.

Jinak to co je ve wiki mě moc nezajímá, sám se živím mnoho let jako programátor pro Windows a mě nikdo pohádkami krmit nebude. Myslím si, že mám dostatek zkušeností abych věděl jaká je pravda a s propagandou ať si jdou do háje.

[Deleted [8409]]

Ano starsi aplikace v Qt nebude vypadat v novych Windows nativne, ale nez vyjdou dalsi Windows tak urcite vyda trolltech dalsi verzi, vzdyt i oni se museli na W_Vista pripravit a upravit ty temata aby to "bylo" nativni.

[Miloslav Ponkrác]

Haha, a co když si někdo ve Windows nastaví jiný skin? Pak bude Qt v prdeli (omlouvám se za hrubý výraz, ale musel jsem to už napsat).

Ne, nechápu proč Qt dělá na Windows tuhle strategii, která způsobí jenom to, že grafická část v Qt knihovně pro Windows bude několikanásobně složitější a s pofiderním výsledkem. Tohle je prostě hovadina.

[Deleted [8409]]

Byla rec o nove verzi windows, podle toho co vim o Qt, tak by jiny skin melo zvladnout.

[Miloslav Ponkrác]

No ono jí "nějak" zvládne. Až na to, že všechny detaily nemá šanci uchodit, protože různé knihovny grafických prvků, které jsou standardem uživatelského rozhraní natvrdo počítají s tím, že je tam budete lepit jako podokna. Ale co bych se snažil vysvětlovat, však na toto téma jsme už zde diskutovali.

[Deleted [8409]]

Mimochodem, tento blogu ukazuje, jak se kresli nativni Windows prvky bez "opravdoveho" okna:

http://blogs.msdn.com/oldnewthing/archive/2005/08/01/445998.aspx

[Miloslav Ponkrác]

Tu funkci DrawFrameControl, která je tam použita jsem si vyhledal v Microsoftí dokumentaci a zjistil, že zvládne nakreslit jen velmi omezený počet prvků. Zato velmi mnoho standardním "Windows widgetů" nezvládne. Takže smolenka pane. Když tvrdím, že ten způsob co tu obhajujete je nemožný pro dosažení nativního vzhledu Windows aplikace, tak vím co povídám. Ne, není možný nativní vzhled, pokud si budete kreslit všechno sám. A ani by to nemělo smysl.

Jinak Windows uživatelé a to už vůbec nemluvím o Mac OS X uživatelích jsou velmi hákliví na to, když jim něco ve Windows nevypadá jak má, nebo to nereaguje.

Já Vám ještě zapomněl říct, že standardní "Windows widgety" jsou poměrně inteligentní a mají řadu různých speciálních chování. Zkušený uživatel Windows pak prská nad jakoukoli napodobeninou nakreslenou v okně, protože to nereaguje na základní povely a akce, které velmi zrychlují práci a na které jsou zkušení uživatelé zvyklí. Takže tohle budou v trolltechu programovat ještě tisíc let.

[xm]

Muhehe, teď jste mě opravdu rozesmál Ve Windows, kde pomalu každá druhá aplikace vypadá naprosto jinak a používá své vlastní skiny a thémata (místo systémových), opravdu musí straaašně záležet na sebemenším detailu

Linux (či FreeBSD) je oproti Windows v tomhle směru na tom přímo výborně.

[Miloslav Ponkrác]

No teď jste mě rozesmál Vy. Jestli hrajete počítačové hry a považujete je za aplikace budiž. Sice pár skinovatelných, veskrze multimediálních aplikací na Windows je, ale jinak mám na svých Windows stovky aplikací a vypadají jedna jako druhá svým uživatelským rozhraním.

A jestli píšete, že Linux je v uživatelském rozhraní jednotnější, tam Vám doporučuji se s Linuxem seznámit - patrně jste ho ještě neviděl.

[xm]

Pletete se, s Linuxem pracuji už přes 6 let a na desktopu ho používám od roku 2002 prakticky výhradně. Uživatelské rozhraní mi skutečně na Linuxu (nebo FreeBSD, to je jedno) připadá z mého pohledu rozhodně jednotnější. Je tu jen GTK+ a Qt (ostatní věci jako Athena, xaw3d, Motif, tk, staré GTK 1.x, atp. jsou dnes už naštěstí prakticky mrtvé, na moderním Linuxovém desktopu se s nimi člověk nesetká), kdežto pod Windows má obrovská spousta aplikací svá vlastní odporná thémátka/skiny, každý druhý si hraje na svém vlastním písečku.

A nemyslím teď hry, ty prakticky nehraju, to beru jako uplně jinou kategorii softwaru. Mám na mysli různé firewally, antiviry, antispywary, vypalovací software (např. i Nero má spouštěcí utilitu používající vlastní skiny, i když naštěstí neznám moc lidí co by to používali), multimediální přehrávače (sakra vždyť ani originální microsoftí Windows Media Player nepoužívá systémový vzhled!), atp. Na počítači běžného uživatele se takového softwaru najde dost (vidím to všude ve svém okolí). Na Linuxu mi oproti tomu přijde situace skutečně lepší.

[Deleted [8409]]

Nejde jen o jednu funkci, tech funkci je cela sada a podobne rozhrani ma i Mac OS X. Slo mi jen o to, vyvratit vase tvrzeni o tom, ze neni mozne kreslit uzivatelske prvky bez "skutecnych" oken.

Verte mi, ze firma trolltech venovala velke usili, aby jejich toolkit vypadal nativne i se tak choval (viz treba skrovolani v X11 a Win, atd), takze to, co podle vas budou programovat tisic let, uz maji davno hotove

Nechci aby to vypadalo, ze se zastavam Qt, ale mnohokrat jsem se dival do jejich zdrojaku a odvedli proste vybornou praci.

[Miloslav Ponkrác]

Slo mi jen o to, vyvratit vase tvrzeni o tom, ze neni mozne kreslit uzivatelske prvky bez "skutecnych" oken.

Ale samozřejmě, že to možné je kreslit prvky. Jen ten výsledek bude polofunkční a nebude zaručen nativní vzhled.

Jinak P.R. řeči (věřte mi, že je taky umím) ve stylu "firma X.Y. věnovala velké úsilí" jsou moc hezké, stejně tak jako "mají dávno hotové" a "odvedli výbornou práci". Nejsem s prominutím pitomec a Win API znám jako vlastní boty. Pokud Trolltech používá nativní "Windows podokna" (abych se tak trochu vyjádřil ve Vašem stylu, pak odvedli dobrou práci a bude to fungovat ke spokojenosti. Pokud si místo toho kreslí ve Windows vše do jednoho okna, pak sorry - vždycky to bude dřít. Můžete mi tu napsat tisíc stránek dalších P.R. řečí na Qt a Trolltech, ale budou to jen plané lži. Oblbujte si prosím jiné lidi.

[Deleted [8409]]

Ale samozřejmě, že to možné je kreslit prvky. Jen ten výsledek bude polofunkční a nebude zaručen nativní vzhled.

Jenže ten výsledek je funkční už dnes, přijde mi, že se se mnou hádáte, aniž by jste Qt pod Windows zkusil (stačí nějaká Qt aplikace)

Jinak P.R. řeči (věřte mi, že je taky umím) ve stylu "firma X.Y. věnovala velké úsilí" jsou moc hezké, stejně tak jako "mají dávno hotové" a "odvedli výbornou práci". Nejsem s prominutím pitomec a Win API znám jako vlastní boty. Pokud Trolltech používá nativní "Windows podokna" (abych se tak trochu vyjádřil ve Vašem stylu, pak odvedli dobrou práci a bude to fungovat ke spokojenosti. Pokud si místo toho kreslí ve Windows vše do jednoho okna, pak sorry - vždycky to bude dřít. Můžete mi tu napsat tisíc stránek dalších P.R. řečí na Qt a Trolltech, ale budou to jen plané lži. Oblbujte si prosím jiné lidi.

AAaaaano, samozrejme mate vzdycky pravdu a neco jako Qt udelate za tyden ze

[Miloslav Ponkrác]

AAaaaano, samozrejme mate vzdycky pravdu a neco jako Qt udelate za tyden ze

Mě docela fascinuje Vaše zatvrzelost v tom, jak obhajujete něco, čemu evidentně nerozumíte. Tvrdíte mi různé skutečnosti o Win API, které evidentně nejsou pravda. Teď už jenom děláte P.R. pro Qt. Nejdřív mi ukažte, kde jsem mluvil o tom, že udělám Qt za týden, nebo mlčte. Podsunout oponentovi něco co netvrdil je docela oblíbená bulvární taktika lidí co ztratili argumenty.

[Deleted [8409]]

To byla ironie vazeny oponente.

Dokud jsem vam nedokazal, ze lze windows prvky kreslit i bez nich, tak byste porad tvrdil ze to nejde. Jak to asi kresli Windows co? Myslite ze nepouziva ty funkce ktere jsem vam napsal a pouziva nejake svoje? Verim ze rozumite WinAPI, taky proc ne, ale neverim ze rozumite skinovanim aplikaci, protoze z vasich reakci to tak ocividne neni.

Nejste schopen dokazat zadne vase tvrzeni o tom, ze Qt nevypada nativne.

[Miloslav Ponkrác]

Kde jste mi dokázal, že lze Windows prvky kreslit i bez nich? Zatím jsem takový důkaz neviděl. A od Vás už vůbec ne.

Já nemám co dokazovat ohledně Qt - nerozumím tomu jak to uvnitř probíhá a aplikace napsané pomocí Qt se na Windows vyskytují tak zřídka, že jsem je prakticky ani neviděl.

O co tady ale běží je fakt, že docílit nativního vzhledu kreslením vlastních uživatelských prvků je ve Windows nemožné. A za tím si stojím. Pokud to nějaká knihovna bude takto dělat, vždycky to bude dřít. A to už ani nemluvím o divném chování takto nakreslených prvků, které nebude mít reakce nativního Windows podokna.

[Deleted [8409]]

Nema cenu se uz vyjadrovat, podivejte se treba na Google Earth, Skype, PSI. Jsou to aplikace pouzivajici Qt, ktere vypadaji nativne i bez nativnich widgetu.

A pokud neverite ze Qt nepouziva nativni widgety, tak se podivejte do zdrojaku.

[Miloslav Ponkrác]

Ne, nemá se vyjadřovat. Odnesl jsem si z diskuse s Vámi, že naprosto všechno víte lépe, než zbytek světa, takže až si s čímkoli nebudu vědět rady, obrátím se na Vás. Jsem rád, že tak chytří lidé jako Vy existují, hned je mi lépe. A prosím, nedejte se, jakmile Vám někdo bude něco tvrdit, ignorujte jakékoli rozumné argumenty a sebevědomě trvejte zase na svém. Vždyť Vy přeci všechno víte nejlíp. Přeji hezký den.

[Deleted [8409]]

Vy se to ale snazite prevratit. Nebyt teto diskuze, tak ani nevite, ze se daji windows prvky renderovat i bez skutecneho HANDLE.

Pokud si stale myslite, ze Qt pouziva nativni prvky tak podivejte na tento priklad:

 #include [QApplication] // zavorky jsou umyslne upravene
    #include [QPushButton]

    int main(int argc, char *argv[])
    {
        QApplication app(argc, argv);

        QPushButton hello("Hello world!");
        hello.resize(100, 30);

        hello.show();
        return app.exec();
    }

Ve Windows pokud vim NENI mozne, aby bylo tlacitko top-level okno, ale v Qt to jde. Pokud program zkompilujete a podivate se na nej pres Spy++, tak uvidite jen jedno HWND a to je vse. Netvrdim, ze vim vsechno, ale v teto konkretni veci jsem si na 100% jist.

[Miloslav Ponkrác]

Ne, prvky grafického rozhraní se ve Windows bez HANDLE skutečně renderovat NEDAJÍ. Protože nějaké okno, tedy HANDLE mít vždycky musíte. Jinak máte smolenku vážený pane.

Mě abych řekl pravdu neustále unavuje neustále vyvracet Vaše z kapsy tahaná tvrzení co jsem tvrdil.

Například jsem nikdy netvrdil (a pokud si myslíte, že ano, citujte mě prosím, kde), že Qt používá, nebo nepoužívá nativní prvky. Jediné, co jsem skutečně tvrdil je, že že bez nativních prvků není možné docílit nativní vzhled na 100%.

Jak říkám, nebudu už dále na Vás zde reagovat. Nemá to smysl.

[Deleted [8409]]

Tak se podivejte jak funguje UxTheme a nerikejte rady kraviny. Prvky se renderovat DAJI.

[Miloslav Ponkrác]

Dejte si už oraz ju? Bez handle si nevyrenderujete ve Windows ani pixel.

[Deleted [8409]]

Unikate od tematu...

Byla rec o tom, ze bude jedno top-level okno a v nem si toolkit uz bude delat okna sam, coz je naprosto mozne. A vy jste tvrdil, ze v takovem pripade nemuze aplikace vypadat nativne, ze to NEJDE protoze nebude pouzivat WinAPI pro vnitrvni prvky. Ja jsem tvrdil, ze WinAPI obsahuje funkce, ktere to umoznuji, ovsem vy si trvate stale na svem.

Viz: http://msdn2.microsoft.com/en-us/library/ms788680.aspx

Jestli vam nestaci ani oficialni dokumentace tak uz opravdu nevim. Popravde je mi celkem jedno, jestli vy trvate na tom ze to nejde, ale co chudaci jini, co si prectou tu diskuzi.

[Miloslav Ponkrác]

A Vy si zase nevidíte do písmenek, když píšete. Psal jste, že je možné renderovat okna ve Windows bez handle a teď se k tomu nehlásíte.

Co se týká Win API pro vnitřní prvky, pokud jste neprogramoval pro Windows ve Win API, rád bych vám sdělil, že ve Windows existují knihovny grafických prvků, které jsou standardem, jako je třeba ctrlcom32, apod.., jejichž kreslení ve Win API nikde nenajdete.

Dále už prosím konečně vezměte v úvahu, že nakreslením těch prvků to nekončí. Musíte taky zajistit, aby se tyto prvky chovaly standardně jak se to ve Windows očekává - a mnohé prvky mají velmi složité chování, které nejde naemulovat, protože Microsoft toho chování neustále rozšiřuje.

Takže kreslení prvků bez nativních podoken se prostě podobá hře na kočku a myš. Kdy Microsoft bude neustále inovovat prvky ve Windows a jejich chování a z druhé strany taková knihovna ho bude neustále dohánět - a to jen omezeně, protože k některým věcem nemá přístup - viz druhý odstavec.

Ano, trvám na tom, že nejde na 100% zajistit nativní vzhled ve Windows bez použití podoken.

[Deleted [8409]]

Ja uz odpovidat nebudu.

Pockame na Qt 4.4 a jestli tam bude implementovane to, co je v tom blogu naznacene, tak se uvidi, jestli mate pravdu. Ono totiz to chovani oken se zase tak moc nemeni, rekl bych ze temer vubec, takze neni problem to naemulovat

Jinak s tim ze se Windows vyviji mate samozrejme pravu. Jenze i to skinovani ve Windows XP musi aplikace nebo toolkit podporovat, pokud si to tema neotevre, tak bude stejne vypadat jako aplikace z roku raz dva...

[Miloslav Ponkrác]

No sláva, že už odpovídat nebudete.

Jinak počkat si můžete, ale leckteré nedomyšlenosti a problémy se projevují časem - asi tak jako problém roku 2000. Ono se chování oken mění, ale omlouvá Vás to, že jednak intenzívně neprogramujete pro Windows, ani nejste zkušený uživatel Windows, který by tyto změny registroval.

Prosím Vás, jak aplikace musí téma podporovat? Aplikace pro to nemusí ani hnout prstem!!! Jí stačí když používá standardní grafické prvky, které jsou součástí Windows a to je vše!!! To je totiž naprosto opačný princip proti tomu co tu podporujete, operační systém a specializované grafické jádro je od toho aby se staralo, ne aplikace!!!

Vy jste tu ochotný tvrdit lecjaké lži, ale sebevědomí Vám rozhodně nechybí.

[Deleted [8409]]

Bohuzel pro vas, mam zkusenosti s programovanim pod Windows i tento system vyuzivam k programovani, takze vim, co si muzu dovolit rict, a co ne. Vas omlouva jen to, ze pouzivate nejaky toolkit, ktery tyto veci dela za vas, takze o nich nemusite vedet prakticky nic.

alespon jedna vec: neni automaticke, ze aplikace pouziva WinXP tema, zkuste si spustit velmi starou aplikaci, ktera pouziva WinAPI (nemyslim aplikaci delanou napr. ve VCL) a uvidite, ze nebude pouzivat WinXP tema!

Mam pocit ze mate velke sebevedomi vy, protoze jste v teto diskuzi rekl pomerne dost kravin (coz je vase neznalost o WinAPI a X serveru).

[Miloslav Ponkrác]

No zatím se programováním ve Windows živím a lepím okna ve Win API poměrně často - ono to totiž není složité a máte nad tím plnou kontrolu.

Jak říkám, až si nebudu vědět rady, obrátím se na Vás. Mějte se krásně a loučím se s Vámi.

[Deleted [8409]]

Treba se nekdy obratim ja na vas, ale jen bych nechtel aby jste mi rekl, ze neco nejde, kdyz to jde take se loucim v teto diskuzi:_)

[Filip Jirsák]

Pokud je pravda, co rikate, tak by Qt nemohlo ve Windows vypadat nativne. Jsem si 100% jist, ze bude vypadat nativne i kdyz bude systemove jen jendo top-level okno.

Nebude. Javovský Swing řeší to samé – už existují témata, která emulují vzhled Windows nebo GTK. Jenže pořád, když se upraví téma nativních Windows nebo GTK, musí se upravit i to emulované téma. A hlavně – to že aplikace zapadne do nějaké platformy neznamená jen to, jak bude vypadat, ale i jak se bude chovat – tedy to feel z look-and-feel. Na Linuxu to nebude takový problém, tam je feel dáno použitým toolkitem, takže se liší aplikaci od aplikace, ale na Windows nebo MacOS je feel jednotné v celém systému. A obávám se, že konkrétně ve Windows některé specialitky nepůjde ani emulovat, protože jsou zadrátovány někde v systému a není k nim k dispozici veřejné API.

[Deleted [8409]]

Jeste jsem neslysel, ze by se Qt pod Windows nechovalo nativne a pritom si kresli veskere prvky samo a veskere chovani widgetu resi pouzi toolkit (krome nekterych dialogu, ale to ted neni dulezite)

[Miloslav Ponkrác]

Ono moc aplikací používající Qt pod Windows není. Znám jenom Audacity a Skype. A hlavně na Audacity je docela poznat, že je trochu jiná.

Ale ona je otázka, jak to Qt vnitřně vůbec dělá na Windows - třeba to dělá jnak, než uvádíte.

[Radek Miček]

Audacity pouziva knihovnu wxWidgets a ta zas pouziva nativni widgety - pokud to jde.

[Miloslav Ponkrác]

Tak jsem to špatně odhadl, děkuji za opravu.

[Deleted [8409]]

To je strasne zajimave, ze rikate, ze audacity se chova ve Windows podivne a pritom pouziva ciste WinAPI prvky :)

Vase reakce jasne dokazuje to, ze ani poradne nevite co je nativni

[Miloslav Ponkrác]

Jasan a moje reakce ještě dokazuje, že jsem pedofil, nekrofil a černoch.

[Deleted [8409]]

To rikate vy

[Filip Jirsák]

A jak dlouho už se Qt pod Windows testuje? Kolik uživatelů používajících cizojazyčné verze Windows nebo verze s psaním zprava doleva už to testovalo? Kolik zrakově postižených? Kolik tělesně postižených, kteří nemohou používat myš, používají klávesnici „jedním prstem“? Tohle všechno platforma Windows nějak řeší, zvládne Qt tohle všechno správně emulovat?

[Deleted [8409]]

Podivejte se radeji do dokumentace a do zdrojovych kodu a uvidite, ze minimalne psani z prava Qt zvlada. Jak je to s ostatnima vecma nevim, ale Qt Accessibility by melo nektere veci resit:

http://doc.trolltech.com/4.3/qt4-accessibility.html

Ono mi ani neni jasne, proc tady resime, jaky to bude mit dopad na windows, kdyz se tato zmena dotkne hlavne rychlosti Qt v linuxu.