Qt WebKit Demo Browser

Benjamin Meyer, jeden z vývojářů Qt, píše o vylepšeních v novém webovém prohlížeči Qt Demo Browser (který je součástí Qt 4.4 jako ukázka schopností Qt WebKitu). Prohlížeč nově podporuje záložky, obsahuje vylepšený adresní řádek (integrovaný progress bar a indikace HTTPS spojení), private browsing, spoustu nových nastavení (otvírání stránek v novém tabu, vypnutí JavaScriptu a pluginů, uživatelské CSS, atp.), ukládání a tisk stránek, atd. Mezi zajímavosti patří extrémně rychlý (téměř okamžitý) start aplikace, Qt pluginy a plně fungující session management. Ze základních funkcí schází už jen Netscape pluginy a disková cache.

6.4.2008 10:59 | xm | Zajímavý software

Komentáře

[saly]

Už se nemůžu dočkat na WebKit v Konqueroru ...

[xm]

Jojo, já taky Pravidelně sleduju v KDE Subversion repozitáři modul webkitkde (kde se vyvíjí QtWebKit KPart). Už to funguje, ale pořád to ještě není źuplně vychytaný (a stále je to taky ještě v playground).

Nicméně tenhle Qt Demo Browser má také něco do sebe (díky tomu jak je jednoduchý a rychlý). Po vydání finálního Qt 4.4.0 se dost možná oddělí, přejmenuje (zatím padl návrh na jméno QuesT) a stane se z něj samostatný projekt (kam už bude moct přispívat kdokoliv, nejen vývojáři Qt).

[David Jaša]

Já se těšil, že je to něco nového a on je to ten blog z počátku března. Proběhly od té doby nějaké změny, jako třeba zbavení se závislosti na RE MSVC++ na Windows?

[David Jaša]

Beru zpět, podíval jsem se jen na jeden odkaz. :-/

PS pro autora zprávičky: příště přidej soft, o kterém píšeš, do místní databáze!

[xm]

Zatím to není samostatná aplikace ale jen demo příklad z Qt 4.4. Až se to po vydání finálního Qt 4.4.0 osamostatní (což je dost pravděpodobné, viz diskuze pod tím starším článkem), tak ho do databáze na Ábíčku přidám

[David Watzke]

WTF?

Proběhly od té doby nějaké změny

Vždyť o tom je ta zprávička... RTFA.

[Rezza]

A nema byt demo spis jednoduche nez plnohodnotny browser?

[xm]

Viz jak jsem psal výše - je dost pravděpodobné, že po vydání finálního Qt 4.4.0 se z toho stane samostatný projekt.

[Rezza]

A nekdo bude muset napsat zase dalsi jednoduchy demo projektik pro Qt, z toho zase vznikne samostatny projekt a historie se bude porad donekonecna tocit!

[xm]

Pokud jde o úplně jednoduchý Qt browser, tak takový je už přímo ve WebKitu pěkně dlouho (dávno předtím než vznikl tenhle nový demonstrační Qt Demo Browser od Trolltechu) - jmenuje se QtLauncher. Tenhle Qt Demo Browser má ukazovat mnohem víc schopností nového Qt (ale přitom je stále jednoduchý - to právě ukazuje sílu Qt ).

[kavol]

A nekdo bude muset napsat zase dalsi jednoduchy demo projektik pro Qt, z toho zase vznikne samostatny projekt a historie se bude porad donekonecna tocit!

zapomněl jsi na jednu věc, a to že poté, co se z toho stane "samostatný" projekt, se kolem toho začne motat pár bývalých vývojářů Konqueroru, několik z nich bude mít blbé hlášky na aktivní vývojáře Konqueroru, ti si to nenechají líbit, komunitní týpci "aktivní blbec" je dík tomu totálně zdiskreditují poukazováním na uraženou ješitnost a podobné hlody, načež frontman_KDE_v_té_době hodí Konqueror přes palubu a podpoří plíživou snahu jej nahradit Qt_Demo_Browserem, čemuž bude typ "aktivní blbec" zuřivě tleskat a pod každou zmínkou o Qt/KDE/jiném browseru nezapomene připsat, jak je Qt_Demo_Browser super a že je dobře že vytlačil Konqueror, přičemž z každého, kdo si dovolí říct, že se mu takový vývoje nelíbí, bude do roztrhání dělat idiota ... aby bylo to opakování historie kompletní

[xm]

Shrňme to: trolli, troll

Vám asi někdo šlápl na kuří oko

[kavol]

hm, jestli ono to nebude spíš naopak, nevidím jediný rozumný protiargument, nic než plivnutí - jak je to o té potrefené ...? :-p

[NaiL]

+1 :)

[David Jaša]

Ještě ti tam chybí vynoření se fungl nového a ještě mnohem lepšího browseru, který vytlačí DemoBrowser stejným způsobem jako ten předtím vytlačil Konqueror.

Teď vážně: Konqueror (prohlížeč) se podle mě o svou budoucnost obávat nemusí. Je postaven na KDE a využívá skrz na skrz jeho technologie, zatímco DemoBrowser je odlehčená multiplatformní hračka nad čistým Qt, která už z principu nemůže být do KDE (tolik) integrovaná. Každý přístup má jiné vlastnosti a dva takové browsery mohou v klidu žít vedle sebe aniž by si konkurovaly (jako např. Firefox a Epiphany v Gtk/Gnome). Něco jiného by bylo, kdyby někdo začal vyvíjet nový superhyperprohlížeč čistě pro KDE - pak by se s Konquerorem časem požraly jako Epiphany s Galleonem.

Trochu jiné je to s vlastním vykreslovacím jádrem: s tímto přístupem případnému mergi v podstatě nic nebrání.

[kavol]

Ještě ti tam chybí vynoření se fungl nového a ještě mnohem lepšího browseru, který vytlačí DemoBrowser stejným způsobem jako ten předtím vytlačil Konqueror.

no však to tam má kolega

Teď vážně: Konqueror (prohlížeč) se podle mě o svou budoucnost obávat nemusí. Je postaven na KDE a využívá skrz na skrz jeho technologie, zatímco DemoBrowser je odlehčená multiplatformní hračka nad čistým Qt, která už z principu nemůže být do KDE (tolik) integrovaná.

neřekl bys něco velmi podobného před pěti lety o KHTML?

Trochu jiné je to s vlastním vykreslovacím jádrem: s tímto přístupem případnému mergi v podstatě nic nebrání.

no, "v podstatě" ... z "proti" považuju body 2 a 4 za celkem podstatný problém, bohužel :-/

[David Jaša]

neřekl bys něco velmi podobného před pěti lety o KHTML?

Nevím. U samotného vykreslovacího jádra podle mě stačí, že kreslí přes tytéž knihovny, jako program (= Qt v případě KDE), a závislost na vyšších věcech (kdelibs a vyšší) je spíš na škodu. Applové to pochopili dřív než kucí od KHTML, a proto se teď všude možně začíná cpát právě WebKit (což má za následek více vývojářů WK

no, "v podstatě" ... z "proti" považuju body 2 a 4 za celkem podstatný problém, bohužel :-/

Obojí to jsou především organizační věci - bude-li zájem, tak si je dotyční domluví rychle.

[kavol]

U samotného vykreslovacího jádra podle mě stačí, že kreslí přes tytéž knihovny, jako program (= Qt v případě KDE), a závislost na vyšších věcech (kdelibs a vyšší) je spíš na škodu.

potíž této úvahy je v tom, že to nelze brát jakou jednorozměrný problém - bod na přímce od lowlevel věcí (abstrakce hardware) přes grafický toolkit po highlevel věci (kompletní desktopové prostředí)

Qt se snaží dělat věci, které v klasickém pojetí řešil (a pravděpodobně dosti často lépe) Xserver na straně jedné, na straně druhé dělá věci, které jsou daleko za rámcem toho, co bych očekával od grafického toolkitu ... a tudíž vázat se čistě na prostředky Qt je IMHO zbytečně omezující

no, "v podstatě" ... z "proti" považuju body 2 a 4 za celkem podstatný problém, bohužel :-/

Obojí to jsou především organizační věci - bude-li zájem, tak si je dotyční domluví rychle.

obávám se, že z druhé strany zájem prostě není - co jim to přinese?

[David Jaša]

U samotného vykreslovacího jádra podle mě stačí, že kreslí přes tytéž knihovny, jako program (= Qt v případě KDE), a závislost na vyšších věcech (kdelibs a vyšší) je spíš na škodu.

potíž této úvahy je v tom, že to nelze brát jakou jednorozměrný problém - bod na přímce od lowlevel věcí (abstrakce hardware) přes grafický toolkit po highlevel věci (kompletní desktopové prostředí)

Qt se snaží dělat věci, které v klasickém pojetí řešil (a pravděpodobně dosti často lépe) Xserver na straně jedné, na straně druhé dělá věci, které jsou daleko za rámcem toho, co bych očekával od grafického toolkitu ... a tudíž vázat se čistě na prostředky Qt je IMHO zbytečně omezující

Však jo, nemám nic proti jádru, které využívá kdelibs (nebo jinou knihovnu/platformu). Pouze mi připadá nevhodné, když se omezí pouze na tuto platformu - je pak dostupné pro omezenou skupinu uživatelů a ubývají mu tak potenciální vývojáři, testeři a jádru se ve výsledku dostává méně pozornosti, než by zasloužilo. To všechno ale neplatí o prohlížeči, který může být výrazně jednodušší (špinavou práci dělá především jádro) a integrací s platformou u něj dává větší smysl, protože je s uživatelem v přímém kontaktu.

Ve vztahu WK a KDE stojí za zmínku ještě jedna okolnost: podobně složité věci z Qt KDE běžně používá (namátkou třeba Arthur) a nikdo nebrble, že nad tím nemá kontrolu atd. U KHTML/WK je to ale kvůli jejich historii nemyslitelné...

obávám se, že z druhé strany zájem prostě není - co jim to přinese?

Kde jsem říkal, že se v dohledné době (za současné situace) spojí? Jen jsem psal, že pokud se situace změní a bude o spojení zájem, budou největší překážky organizačního rázu...

[kavol]

Však jo, nemám nic proti jádru, které využívá kdelibs (nebo jinou knihovnu/platformu). Pouze mi připadá nevhodné, když se omezí pouze na tuto platformu - je pak dostupné pro omezenou skupinu uživatelů a ubývají mu tak potenciální vývojáři, testeři a jádru se ve výsledku dostává méně pozornosti, než by zasloužilo.

otázka je, zda tento "(ne)dostatek pozornosti" je či není dostatečně vyvážen ústupky, které se (ne)musí udělat v zájmu nezávislosti na platformě

řekl bych, že psí hrob je v tom, že jádro prohlížeče je docela monolit - určitě by se dalo rozsekat na menší kusy, některé navázané na určitou platformu (a třeba vyměnitelné pro jinou) a některé zcela platformově nezávislé

ostatně pokusy na toto téma byly (minimálně GTK port)

To všechno ale neplatí o prohlížeči, který může být výrazně jednodušší (špinavou práci dělá především jádro) a integrací s platformou u něj dává větší smysl, protože je s uživatelem v přímém kontaktu.

Ve vztahu WK a KDE stojí za zmínku ještě jedna okolnost: podobně složité věci z Qt KDE běžně používá (namátkou třeba Arthur)

tímto ses ovšem dotknul takové implicitní myšlenky v mém původním příspěvku, že Qt absorbovalo spoustu věcí, které by logicky patřily do kdelibs ... ostatně o tom již výše, že Qt je dnes všechno možné, jenom ne jednoduchý x-window toolkit

takže za těch pět let může být "integrace s platformou, přímý kontakt s uživatelem" v případě browseru otázkou integrace s Qt, nikoliv s kdelibs

a nikdo nebrble, že nad tím nemá kontrolu atd. U KHTML/WK je to ale kvůli jejich historii nemyslitelné...

nejen kvůli historii, ale i kvůli budoucnosti ...

připadá mi, že stávající vývojáři KHTML jsou ti poslední mohykáni, kteří bojují bitvu, aby KDE využívalo to nejlepší, co mu může Qt nabídnout, ale stálo si za svými zájmy, zatímco zbytek se vydal pseudopragmatickou cestou přizpůsobit KDE tomu, co nabízí Qt - ale Qt tu není kvůli KDE, nýbrž kvůli komerčním zájmům, které ne vždy vedou k věcem, které jsou uživatelům KDE ku prospěchu

... tedy alespoň KDE v klasickém pojetí coby "nejlepšího un*xového desktopového prostředí" (které už ovšem asi vzalo zasvé )

(což zase zavdává podnět k úvaze na téma jiného opakování historie, a to zda nové KDE podobně jako Firefox přitáhne windowsovské vývojáře, kteří posléze začnou převládat, a KDE začne řešit problémy špatného chodu na un*xech )

obávám se, že z druhé strany zájem prostě není - co jim to přinese?

Kde jsem říkal, že se v dohledné době (za současné situace) spojí? Jen jsem psal, že pokud se situace změní a bude o spojení zájem, budou největší překážky organizačního rázu...

a kde jsem říkal, že ty jsi říkal? - jenom poznamenávám, že tyto překážky, byť organizační, považuju právě za ty největší ...

[David Jaša]

otázka je, zda tento "(ne)dostatek pozornosti" je či není dostatečně vyvážen ústupky, které se (ne)musí udělat v zájmu nezávislosti na platformě

řekl bych, že psí hrob je v tom, že jádro prohlížeče je docela monolit - určitě by se dalo rozsekat na menší kusy, některé navázané na určitou platformu (a třeba vyměnitelné pro jinou) a některé zcela platformově nezávislé

Chce se mi říct, že porty WebKitu ukazují, že to možné je a docela dobře. Ale radši budu opatrnější a postavím to tak: do roka a do dne se nejpozději ukáže, jestli je to opravdu správný přístup.

tímto ses ovšem dotknul takové implicitní myšlenky v mém původním příspěvku, že Qt absorbovalo spoustu věcí, které by logicky patřily do kdelibs ... ostatně o tom již výše, že Qt je dnes všechno možné, jenom ne jednoduchý x-window toolkit takže za těch pět let může být "integrace s platformou, přímý kontakt s uživatelem" v případě browseru otázkou integrace s Qt, nikoliv s kdelibs

Je fakt, že se postupně zmenšuje volnost desktopových prostředí - z jedné strany přibývá standardizovaných rozhraní, konfigurací, úložišť atd. a z druhé strany toho umí základní knihovny čím dál více.

připadá mi, že stávající vývojáři KHTML jsou ti poslední mohykáni, kteří bojují bitvu, aby KDE využívalo to nejlepší, co mu může Qt nabídnout, ale stálo si za svými zájmy, zatímco zbytek se vydal pseudopragmatickou cestou přizpůsobit KDE tomu, co nabízí Qt

Tak tady zase ukáže až za čas, která cesta se víc přiblíží k "nejlepšímu un*xovému prostředí".

(což zase zavdává podnět k úvaze na téma jiného opakování historie, a to zda nové KDE podobně jako Firefox přitáhne windowsovské vývojáře, kteří posléze začnou převládat, a KDE začne řešit problémy špatného chodu na un*xech )

Sobecky bych jakékoliv un*xové DE na windows přivítal, abych se zbavil debilního explorera, ale přesně z tohoto důvodu bych byl nerad, kdyby vzniklo.

[kavol]

...

Tak tady zase ukáže až za čas, která cesta se víc přiblíží k "nejlepšímu un*xovému prostředí".

obávám se, že čas toho příliš neukáže, protože nebude s čím srovnávat - alternativy patrně zajdou na úbytě ... budeme vědět, jestli máme věci dobré, ale nikdy se nedozvíme, jestli bychom neměli lepší, kdyby část vývojářů dala přednost té druhé cestě

(což zase zavdává podnět k úvaze na téma jiného opakování historie, a to zda nové KDE podobně jako Firefox přitáhne windowsovské vývojáře, kteří posléze začnou převládat, a KDE začne řešit problémy špatného chodu na un*xech )

Sobecky bych jakékoliv un*xové DE na windows přivítal, abych se zbavil debilního explorera, ale přesně z tohoto důvodu bych byl nerad, kdyby vzniklo.

mno, mě je silně proti srsti už jenom to, že KDE se hodně vydalo cestou kopírování Applu (a z toho především věcí, které stejně dělá i Microsoft) ... dodnes mě nadzvedává ze židle problém adresář vs. složka - když si někdo pustí KDE nad Macovským filesystémem, ať si tomu klidně říká složky, ale jestliže mi KDE běží nad ReiserFS, a na příkazové řádce mám rmdir, tak ať jdou do háje s "remove folder" - jasně, blbina, ale tohle je jen špička ledovce, která je viditelná a dobře se to na ní ilustruje

takže natažení windowsovských programátorů (které už se zlehka děje) se opravdu děsím

ale už bych nechal tuto diskusi spát, pokračování v hospodě

[David Jaša]

mno, mě je silně proti srsti už jenom to, že KDE se hodně vydalo cestou kopírování Applu (a z toho především věcí, které stejně dělá i Microsoft) ... dodnes mě nadzvedává ze židle problém adresář vs. složka - když si někdo pustí KDE nad Macovským filesystémem, ať si tomu klidně říká složky, ale jestliže mi KDE běží nad ReiserFS, a na příkazové řádce mám rmdir, tak ať jdou do háje s "remove folder" - jasně, blbina, ale tohle je jen špička ledovce, která je viditelná a dobře se to na ní ilustruje

takže natažení windowsovských programátorů (které už se zlehka děje) se opravdu děsím

ale už bych nechal tuto diskusi spát, pokračování v hospodě

Ve všem +1