HTML5 backend pro GTK+ 3

GTK+ 3 kromě nesčetného množství jiných funkcí nabídne i HTML5 backend. Programy používající GTK+ 3 tak budou mít webové rozhraní "zdarma" - aplikace v něm vypadá jako desktopová.

26.11.2010 22:22 | Luboš Doležel (Doli) | Zajímavý software

Komentáře

[chrono]

Je otázne, koľko ľudí ma tak rýchle internetové pripojenie, aby mohli niečo také používať.

[Zopper]

Proč internetové připojení? teoretických 100 mbps máte na intranetu všude, kolikrát dnes i 1Gbps - a tohle bude využitelné spíše na intranetu.

[Luboš Doležel (Doli)]

A kolik potřebujete na Gmail?

[Conscript89]

Nejak moc nechapu smysl.

Na prohlizeni dokumentace co mam na disku a je psana v HTML potrebuji internetove pripojeni?

Ano, GTK 2 umoznuje takto zobrazeni HTML4, zpravicka ma z meho pohledu ten vyznam, ze se v GTK 3 rozsiri podpora na HTML5.

[vlastikroot]

To neni GTK zobrazujici HTML, ale HTML5 (canvas, websockets) zobrazujici GTK

[Conscript89]

Aha, dekuju za upozorneni, po opetovnym (a pozornym) precteni to uz vidim :)

[sivlk]

Možno tie GTK aplikácie pobežia cez HTML5 rýchlejšie...

[xkucf03]

Zvlášť když ty tlačítka a posuvníky a obecně formuláře bude vykreslovat prohlížeč zase do GTK

BTW: Qt tohle mělo už před rokem.

[Jan]

vykresluje jen přenášený obraz, nikoliv jednotlivé prvky jako posuvníky nebo formuláře

[alblaho]

Hm, vypadá to fakt impresivně.

[imploder]

Na intranetové aplikace určitě užitečná věc, po internetu by byl asi problém s rychlostí - pomalé min. jak Xka po síti. Některé věci jinak než nízkoúrovňově kreslením na canvas udělat nejdou, ale aspoň základní formulářové prvky by mohli zkusit udělat přímo pomocí HTML prvků na to určených. Sice se to pak nebude chovat a vypadat úplně stejně, ale když se zachová logika ovládání, tak to nebude vadit Např. není tak důležité, že obyčejný < select > se rozbaluje podle zvyklostí prohlížeče a ne jako odpovídající widget v GTK. Bylo by to pak mnohem rychlejší, protože by se přenášelo jenom trochu HTML a vykreslení by prohlížeč zařídil sám.

[Grunt]

pomalé min. jak Xka po síti

Čistě pro zajímavost: Co je rychlejšího než Xka po síti?

[imploder]

Třeba webové aplikace. Přenáší se jenom jakási abstrakce (HTML, CSS, javascript) rozhraní, ne hotové bitmapy, takže se nemusí přenášet tolik dat. Taky odezva je rychlejší, protože část funkcionality, na kterou není potřeba server, může být naprogramovaná v javascriptu na klientovi. Nevýhodou je menší univerzálnost.

Nevím, jak je to udělané, možná GTK bude využívat možnosti HTML, co nejvíc chování GUI přeloží do javascriptu - to by podle mě byla správná implementace webového GUI. Aby se to implementací podobalo rozhraní kvalitní webové aplikace a ne aby se znásilňoval jeden prvek (canvas), aby to nějak jelo i za cenu mizerného výkonu. Nic proti tomu v takové podobě nemám, někde to třeba najde využití i tak, jenom říkám, že by se to (teoreticky) dalo udělat mnohem líp. Dalo by to nepochybně hodně práce, ale kdyby se to povedlo, tak to IMHO bude jednoznačně killer feature GTK. Setřel by se tím rozdíl mezi desktopovýma aplikacema a webovýma - vytvořil bych jednu aplikaci a ta by fungovala jako desktopová i jako webová - opravdová webová aplikace, jako by ji napsal webový programátor (žádné prasení s canvasem, když to není potřeba).

[Grunt]

ne hotové bitmapy

No a to bude možná ta chyba. Pokud není nastavený SW Render tak se přenášejí grafické entity podobné spíš SVG grafice (čtverce a kolečka) a žádné pixmapy jak si většina lidí myslí (o jediném leču, které je toho ještě schopno a o kterém vim je Microsoftí RDP). Kdyby se přenášeli hotové pixmapy, tak by to po té síti jelo trochu jinak..

Třeba webové aplikace

Webová aplikace je jako ždárat se levou rukou v řiti kolem pravé řitní půlky. Ne že by to snad nešlo.

[imploder]

Tak s těma bitmapama jsem to asi úplně netrefil - text, čáry aj. "primitiva" se X protokol podporuje, takže pokud X klient není blbec (a to snad u dnešních grafických toolkitů není), tak je využije. HTML je i tak efektivnější, protože se přenášejí přímo ovládací prvky - formulářové widgety, odkazy, atd.. Taky s odezvou je na tom moderní webová aplikace líp, protože některé věci prostě může dělat na klientovi javascriptem, narozdíl od aplikace přes X.org, která dělá úplně všechno na serveru (i věci jako posouvání dokumentu, vykreslení hover efektu - u webové aplikace zrovna na tohle ani není potřeba javascript, stačí CSS). Jsou to prostě různé technologie, každá má svoje výhody a nevýhody (souhlasím s okbobem níže).

Webová aplikace je jako ždárat se levou rukou v řiti kolem pravé řitní půlky. Ne že by to snad nešlo.

V čem konkrétně? Jasně, jsou věci, na které se webová aplikace nehodí, něco prostě nejde rozumně udělat (i když možnosti se příchodem HTML5 a WebGL rozšíří), taky jsou věci, na které je webová aplikace velice vhodná. Podobně jako příkazový řádek, web jako rozhraní k aplikacím má svoje specifika a na něco se hodí a na něco ne. Pokud nějaká aplikace má být ovládaná vzdáleně, tak bývá dobrá (a častá) volba udělat ji jako webovou. Webové aplikace mají budoucnost, může se dál rozvíjet klientská část (jak se o to snaží HTML5). Prostě mají některé užitečné vlastnosti, které jinde nejsou.

[okbob]

Znám takové aplikace, které mají jednu definici formuláře, která se použije jak pro web tak pro desktop. Já ale mám raději oddělený vývoj, každé prostředí má svoje a co tak mám zkušenost, tak mi přijde, že vývoj dvou oddělených aplikací s jedním backendem přijde levněji a je snažší než jedné superaplikace.

[Tomáš Bžatek]

Chjo, Alex zverejni technologicke demo, hack, na kterem dela, kdyz ma chvilu casu a hned se strhne lavina spekulaci a fam.

Takze poporadku: zdrojaky nejsou pripravene pro zacleneni, je tam spousta veci, ktere nefunguji. Je to zkratka jen jednoduche presmerovani kresleni pres Cairo do WebSockets. Podobna vec, se kterou se experimentovalo v ramci Spice. Musi se vyresit input handling, hlavne graby, dale pak dialogy nemaji dekorace, spatne se pracuje s focusem.

Jestli tohle bude soucasti gtk-3.0 neni vubec jiste, pravdepodobne se to nestihne. Je spousta jinych prioritnich veci, ktere se musi dodelat. Dale pak nemame jeste pluggable backends, cili gtk aplikace se musi v soucasne dobe prekompilovat, chce-li vyuzivat jiny backend. Nicmene tohle se chysta v dohledne dobe, pro Wayland backend (mozna bude ale az v gtk-3.2).