Portál AbcLinuxu, 7. května 2025 00:38
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ů.
Tiskni
Sdílej:
10.8.2007 17:55
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
jak bez X? To nejde ne?
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.
10.8.2007 21:01
Josef Kufner | skóre: 70
10.8.2007 19:45
Jardík | skóre: 40
| blog: jarda_bloguje
11.8.2007 10:11
brk | skóre: 29
| blog: broukoviny
11.8.2007 14:42
Petr Tomášek | skóre: 39
| blog: Vejšplechty
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...
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.
PS 2: A jake ty vyhody mi X server nabizi?
Doufam ze si nepletete X server a webovy prohlizecNepletu. 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?
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.
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í
11.8.2007 22:51
Petr Tomášek | skóre: 39
| blog: Vejšplechty
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ý...)
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…
zjistit, pod krerym detskym oknem se momentalne nachazi kurzor mysi je pro toolkit naprosta malickostto 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.
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.
Není
- 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)...
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.
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.
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:)
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.
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ě.
Nechci aby to vypadalo, ze se zastavam Qt, ale mnohokrat jsem se dival do jejich zdrojaku a odvedli proste vybornou praci.
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
#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.
take se loucim v teto diskuzi:_)
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.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.