[KDE] Gecko-based browsen in native QT/KDE

[pelleke]

Omdat mijn vorige topic dichtgegooid is zal ik het eens proberen met een andere approach.

Ik kan me niet voorstellen dat ik de enige ben die dit wil (en dat er nog geen oplossing bestaat). Ik zoek gewoon een manier waarop ik gecko-based kan browsen in een nette native qt-based browser, zoals bijvoorbeeld konqueror. Ik heb met de devvers gemailed, en al die KParts draaien heel erg beta, en ik kreeg het niet zo gauw aan de praat.

Is er iemand die in KDE een nette Gecko-browser heeft draaien, die niet over GTK oid werkt, maar netjes met QT/KDE zelf? Het hoeft niet perse een Konqueror-part te zijn, ik vin gewoon KHTML af en toe wat te slordig...

[Niek]

Ik heb mozilla-nightly een week of wat geleden gecompiled met Qt als toolkit, en het resultaat was indrukwekkend
Screenies:




Mijn ervaring:
• Gruwelijk snel in vergelijking met Gecko/GTK2 (opzich niet zo vreemd, als je ziet dat bijv Gecko/Win32 en Gecko/GTK vele malen sneller renderen dan eerstegenoemde, GTK2 is gewoon oertraag in painting/resizing)
• In tegenstelling tot Gecko/GTK(2) zijn alle widgets geimplementeerd, dus bijvoorbeeld textfields en drop down boxes zien er gewoon mooi Qt-alike uit en niet zoals bij GTK(2) een lelijke 'custom' widget (Gecko/Win32 doet dit overigens ook goed, ook met XP widgets).
• Veel dingen zijn compleet fscked up, toolbar helemaal borked, debug teksten overal, repaints die missen, sommige images showden niet, menu's verschijnen op verkeerde X/Y coordinaten.

Conslusie: Gecko/Qt gaat erg vet worden, maar het is nu in pre-alpha stadium. Het kan zijn dat de situatie inmiddels een stuk verbeterd is, mijn geteste versie was van de dag dat de Qt port voor het eerst in CVS zat. Wellicht is er in de tussentijd een hoop veranderd zodat puntje 3 wegvalt
In ieder geval een erg interessante ontwikkeling om in de gaten te houden. Grote kans dat distro's als SuSE, Mandrake, Lindows en Xandros straks Firefox/Qt als default browser gaan leveren.

[Wilke]

The_Surfer schreef op 29 oktober 2004 @ 12:26:
Ik heb mozilla-nightly een week of wat geleden gecompiled met Qt als toolkit, en het resultaat was indrukwekkend

Heeeee, kun je misschien vertellen waar je dat download/hoe je dat doet?

• Gruwelijk snel in vergelijking met Gecko/GTK2 (opzich niet zo vreemd, als je ziet dat bijv Gecko/Win32 en Gecko/GTK vele malen sneller renderen dan eerstegenoemde, GTK2 is gewoon oertraag in painting/resizing)

Dit is mijn indruk dus ook al jaren. Firefox in Windows is veel sneller dan in Linux op dezelfde machine. Nu zou dat aan van alles kunnen liggen natuurlijk, maar: Konqueror is in Linux wel weer veel meer 'responsive' en voelt sneller aan (ik zeg niet dat het sneller rendert, dat durf ik zo niet te zeggen, wel dat het gewoon 'snel' reageert net als Firefox in Windows). Dus zou ik denken dat het dan haast wel aan GTK moet liggen. Of natuurlijk aan een zuigende samenwerking tussen GTK en Firefox, dus dat Firefox de GTK-widgets niet op de meest optimale manier gebruikt. Who knows...ik weet in ieder geval wel dat het mij al vaak is opgevallen.

Wat dat betreft zou ik ook graag zien dat Mozilla/Firefox en ook projecten als OpenOffice de QT-toolkit kunnen gebruiken om de widgets te tekenen.

• Veel dingen zijn compleet fscked up, toolbar helemaal borked, debug teksten overal, repaints die missen, sommige images showden niet, menu's verschijnen op verkeerde X/Y coordinaten.

LOL, da's dan wel weer minder

Maar goed, er is vast ergens een pagina waar uitgelegd staat hoe je dit uit CVS trekt en compileert (wat je nodig hebt enzo), heb je daar een linkje naar toe? Of kun jij het ons uitleggen...

[Niek]

Wilke schreef op 29 oktober 2004 @ 12:42:
(...)

Maar goed, er is vast ergens een pagina waar uitgelegd staat hoe je dit uit CVS trekt en compileert (wat je nodig hebt enzo), heb je daar een linkje naar toe? Of kun jij het ons uitleggen...

Ik heb geen page gevonden waar het op staat, maar het zou ongeveer zo moeten (dit werkte bij mij op Gentoo/AMD64/GCC 3.4):

code:

wget http://ftp.scarlet.be/pub/mozilla.org/mozilla/nightly/latest/mozilla-source.tar.bz2
tar xvfj mozilla-source.tar.bz2
cd mozilla
cvs -z3 update -PA client.mk
make -f client.mk checkout MOZ_CO_FLAGS=-PA
./configure --disable-composer --with-x --with-system-jpeg --with-system-zlib \
--with-system-png --with-system-mng --disable-mailnews --disable-calendar \
--disable-pedantic --enable-mathml --without-system-nspr --enable-nspr-autoconf \
--enable-xsl --enable-crypto --enable-xinerama=no --with-java-supplement \
--with-pthreads --disable-jsd --disable-accessibility --disable-tests --disable-debug \
--disable-dtd-debug --enable-reorder --enable-strip --enable-strip-libs \
--enable-cpp-rtti --enable-xterm-updates --disable-ldap --enable-toolkit-qt \
--enable-default-toolkit=qt --disable-toolkit-xlib --disable-toolkit-gtk \
--disable-toolkit-gtk2 --enable-optimize=-O1 --disable-activex \
--disable-activex-scripting
make
cd dist/bin
./mozilla

Twee opmerkingen:
• Ik heb geen flauw idee of de configure flags kloppen, als ie niet goed compiled moet je even spelen met http://webtools.mozilla.org/build/config.cgi
• Toen ik hem uitcheckte zat er een bugje in de configure tools (hij detect de oude libIDL ipv libIDL-2), ik heb een patch opgestuurd maar ik weet niet of tie gecommit is in CVS, dus hier komt ie nog een keer:

code:

--- ../mozilla.clean/configure  2004-10-11 12:13:31.000000000 +0200
+++ ./configure 2004-10-11 15:12:41.230819888 +0200
@@ -15462,7 +15462,7 @@
       unset NEXT_ROOT
     fi

-    if test "$MOZ_ENABLE_GTK2"; then
+    if test "$MOZ_ENABLE_GTK2" || test "$MOZ_ENABLE_QT"; then

   succeeded=no

Hiermee zou je in princiepe Mozilla/Qt kunnen compilen (geen flauw idee of Firefox (export MOZ_PHOENIX =1) nu ook al werkt).
Laat ff weten of het wel/niet gelukt is

[mOrPhie]

Wilke schreef op 29 oktober 2004 @ 12:42:

Wat dat betreft zou ik ook graag zien dat Mozilla/Firefox en ook projecten als OpenOffice de QT-toolkit kunnen gebruiken om de widgets te tekenen.

Ik weet van de mailinglists uit (kan nu niet zo snel een linkje vinden) dat KDE in overleg is geweest me OpenOffice om een abstractie in te bouwen in OpenOffice, zodat andere toolkits, dan die van OpenOffice zelf, ook ondersteund worden.

[Niek]

mOrPhie schreef op 29 oktober 2004 @ 13:21:
[...]


Ik weet van de mailinglists uit (kan nu niet zo snel een linkje vinden) dat KDE in overleg is geweest me OpenOffice om een abstractie in te bouwen in OpenOffice, zodat andere toolkits, dan die van OpenOffice zelf, ook ondersteund worden.

Daar zijn ze inderdaad al maanden mee bezig SuSE heeft een werknemer ingehuurd die 100% van zijn tijd aan de KDE integratie van OOo werkt. Zie http://kde.openoffice.org/ en deze interessante presentatie: http://artax.karlin.mff.c...USE_Labs_Conference-2004/

[pelleke]

Tnx, The_Surfer....

Kan me herinneren dat ik exact dezelfde screenshot al eerder heb gezien. Gentoo user? (Lees: Is er een e-build van?)

Kan je die config-flags niet aan firefox meegeven? (Of met USE="-gtk -gtk2 qt kde")

[ Voor 24% gewijzigd door pelleke op 29-10-2004 16:52 ]

[blouweKip]

mm, ik heb hem net gebouwd (zonder gtk2 idd, en met qt) maar als ik het mozilla script in dist/bin start dan start mozilla op (v 1.7.3 terwijl de nightly volgens mij een hoger build nummer moet hebben) met een gtk2 interface (ik gok dat hij een al bestaande mozilla install pakt op mijn gentoo systeem)

misschien moet ik dat mozilla script aanpassen? (neem ik iig aan)

//edit

na ff het script doorgelezen te hebben heb ik "run-mozilla" maar gewoon uitgevoerd, dit start idd de juiste versie op met qt support, alleen is deze versie verre van functioneel (allelei widget problemen, verkeerder fonts, crashes en vooral: veel trager dan met gtk2)

Mja, toch maar eens wachten op die gecko kpart (al is firefox/mozilla bij mij op mn pc al iig even snel/sneller dan konqueror)

[ Voor 36% gewijzigd door blouweKip op 29-10-2004 18:11 ]

[irondog]

Wilke schreef op 29 oktober 2004 @ 12:42:

Heeeee, kun je misschien vertellen waar je dat download/hoe je dat doet?

Screenshots maken is helemaal niet zo moeilijk en screenshots (van anderen?) crossposten al helemaal niet. De bovestaande shots zijn rechstreeks gejat van de gentoo forums of ik heb een mede Gentoo forumer gevonden

Maar om ook even iets nuttigs te vertellen: ik denk dat er nog niet echt te browsen is met de test code om mozilla de Qt toolkit te laten gebruiken.

Dit is mijn indruk dus ook al jaren. Firefox in Windows is veel sneller dan in Linux op dezelfde machine.

Ik denk dat Firefox echt een middel is om te concureren tegen MSIE op het win32 platform. Firefox is in Linux gewoon amper sneller dan Mozilla, zo niet trager. Ach ja, Gnomers hebben het op het gebied van browsers gewoon echt beter dan KDE'ers. Al is er met Epiphany (wat een schamel overblijfsel is van wat Galeon in de CVS van ruim twee jaar geleden was) niet echt bijster veel in te halen, Mozilla en Firefox zijn gewoon te bouwen met GTK als toolkit en daar ís dus wat in te halen.

[...] Dus zou ik denken dat het dan haast wel aan GTK moet liggen. Of natuurlijk aan een zuigende samenwerking tussen GTK en Firefox, dus dat Firefox de GTK-widgets niet op de meest optimale manier gebruikt.

GTK voelt altijd traag aan vind ik. Maar de bottleneck in deze gelaagde samenwerking is waarschijnlijk gewoon X11. We moeten gewoon wachten op een goede implementatie hiervan.

Monkey test:
open 11 tabs met verschillende sites en houd ctrl + tab ingedrukt zodat de browser als een gek door de geopende tabs heen gaat. Vergelijk de resultaten met Windows en Linux of tussen Mozilla GTK en puur X11.

[Skinkie]

irondog schreef op 29 oktober 2004 @ 20:23:
Monkey test:
open 11 tabs met verschillende sites en houd ctrl + tab ingedrukt zodat de browser als een gek door de geopende tabs heen gaat. Vergelijk de resultaten met Windows en Linux of tussen Mozilla GTK en puur X11.

Waar denk je dat de Font redendering vandaan komt? Alles kost tijd...

En ik ben (persoonlijk) helemaal niet te spreken over Qt... qua looks en compile tijd, ik weet niet wat het is maar ik vind XFCE4/GTK2 gewoon mooier dan KDE/QT. En ja ik heb het allebei gedraaid.

[Remenic]

irondog schreef op 29 oktober 2004 @ 20:23:
[...]
GTK voelt altijd traag aan vind ik. Maar de bottleneck in deze gelaagde samenwerking is waarschijnlijk gewoon X11. We moeten gewoon wachten op een goede implementatie hiervan.

Nee, X11 is best wel heel erg snel. Kijk maar eens naar Qt, FOX, GTK+1 en Tk. Alleen doen die toolkits niet aan doublebuffering, hetgeen waarschijnlijk de oorzaak is van GTK 2's gevoelsmatige traagheid.

[Niek]

irondog schreef op 29 oktober 2004 @ 20:23:
[...]
Screenshots maken is helemaal niet zo moeilijk en screenshots (van anderen?) crossposten al helemaal niet. De bovestaande shots zijn rechstreeks gejat van de gentoo forums of ik heb een mede Gentoo forumer gevonden

Err... misschien is het handig dat je wat research doet voor je zulke belachelijke beschuldigingen post? Als je even de profiles had vergeleken (of alleen maar m'n sig had bekeken) dan had je gezien dat ik een die-hard oldskool Gentoo user ben, * Niek en Niek zijn dus een-en-dezelfde

(...)
GTK voelt altijd traag aan vind ik. Maar de bottleneck in deze gelaagde samenwerking is waarschijnlijk gewoon X11. We moeten gewoon wachten op een goede implementatie hiervan.
(...)

BS. Het is niet de fout van X11 of XFree86 of XOrg. GTK2 voelt gewoon oertraag aan (om over Pango niet te spreken), toolkits als Qt, FLTK en GTK1 zijn daarbij vergeleken bliksemsnel. Open eens /. in Konqi, Opera en FF en resize het window: in Konqi en Opera gaat dat redelijk vloeiend terwijl in FF (gecompiled met GTK2 uiteraard) het schokt as hell en je CPU usage ~100% zit. In de Win32 en GTK1 port van FF is dit probleem niet of in mindere mate aanwezig.

[Wilke]

irondog schreef op 29 oktober 2004 @ 20:23:
Firefox is in Linux gewoon amper sneller dan Mozilla, zo niet trager.

Dat is zeker niet waar, en dat beweer ik ook nergens.

Ach ja, Gnomers hebben het op het gebied van browsers gewoon echt beter dan KDE'ers.

Huh? Juist niet. Ik zeg juist dat Konqueror veel sneller aanvoelt, en ik zou hopen dat Firefox onder Linux ook een keer dat soort performance haalt. Sowieso is Firefox geen 'Gnome' programma, dus ik mis even wat de link is tussen Gnome en Firefox.

GTK voelt altijd traag aan vind ik. Maar de bottleneck in deze gelaagde samenwerking is waarschijnlijk gewoon X11.

Dat geloof ik dus niet, want dan had KDE/Konqueror er ook last van gehad, en dat is dus niet zo. De bottleneck moet haast wel bij GTK zitten denk ik; maar ik heb geen benchmarks gedraaid ofzo die deze vermoedens zouden kunnen bevestigen.

Ik weet iig dat Qt/X11 er geen last van heeft, dus...trek zelf je conclusies

[ Voor 5% gewijzigd door Wilke op 30-10-2004 03:43 ]

[mOrPhie]

irondog schreef op 29 oktober 2004 @ 20:23:
GTK voelt altijd traag aan vind ik. Maar de bottleneck in deze gelaagde samenwerking is waarschijnlijk gewoon X11.

Da's onzin. Het X11-protocol heeft heel weinig met de snelheid te maken. Neem de Tiny-X server. Een X11-implementatie op PDA's. Aan X11 ligt het dus niet. En als het al aan X zou liggen, dan ligt het aan de implementatie; XFree86 of X.Org dus. Maar ook daar ben ik niet van overtuigd. X is sneller dan veel mensen denken. Denk alleen al aan de nieuwe Composite-extentie welke nu in X.Org is geimplementeerd.

Ik ben voordat ik KDE overstapte altijd gnome-user geweest. Totdat KDE 3.2 uitkwam en ik de voordelen van QT en KDE ging ondervinden. Onder andere de gevoelsmatige snelheid gaf de doorslag. GTK voelt gewoon net even een tikkeltje stroperiger aan. Maar laten we wel zijn. Dit snelheidsverschil is minimaal en GTK kent weer het voordeel ten opzichte van QT minder te "flikkeren". Maar ook dit is weer in QT4 ruim opgelost en verbeterd. Mijn ervaring is dan ook, dat het puur subjectief is welke toolkit je het beste vind. Ik ben op dit moment voor QT, maar dat betekend niet dat ik GTK slecht vind of dat GTK slecht is.

Het punt is echter dat we hier niet louter over de toolkit praten. Je moet wel eerlijk vergelijken!

Firefox (en mozilla ook) is namelijk geen native GTK applicatie en al helemaal geen gnome-applicatie. Het is een binding tussen de toolkit van Mozilla (XUL) en een aantal GTK-libraries. Te vergelijken met bijvoorbeeld Java/GTK-bindings zoals in Azureus. Een java-applicatie die eruit ziet als een gtk-applicatie. Zoals men weet, zijn java-applicaties niet de snelste als het om GUI gaat. De snelheid van die GUI is dan ook nog steeds vrij stroperig, wanneer de GTK-bindings gebruikt worden. De snelheid hangt in deze dus absoluut niet alleen af van GTK alleen... maar meer van de combi -lokale toolkit + snelheid abstractielaag met GTK-. Ofwel, epiphany (ongeacht of je het een slechte browser vind of niet) zou sneller aan moeten voelen. En in mijn ervaring is dat ook zo.

Persoonlijk ben ik meer voor een goeie stabiele Gecko KPart, dan voor een QT-Enabled Mozilla. Konqueror integreert mijns inziens mooi met het systeem (splitten van de konqueror-presentatie bijvoorbeeld, kio-slaves, enz) en dat zou gebruikt moeten worden. Het aanbieden van een Gecko-kpart geeft dan de vrijheid om van engine te wisselen, zonder de browser-integratie van konqueror te verliezen. KParts is juist 1 van die dingen die mij op KDE deed overstappen.

[smokalot]

ik vind het bestaan van een universele filemanager/browser/ftpclient/sftpclient/officeviewer/texteditor/sambaclient/enz ook een belangrijke reden om KDE te blijven gebruiken. Dat is trouwens ook hetgene wat ik een beetje mis in OSX.

wel is het zo dat veel implementaties in de KParts net niet helemaal netjes zijn, ik vind het heel erg jammer dat je niet vanuit konqueror direct dingen transparant kunt openen vanuit samba/ftp/sftp servers, hij kopieert alles eerst naar /tmp.

[irondog]

Dat is zeker niet waar, en dat beweer ik ook nergens.

JA, maar ik wel.

Huh? Juist niet. Ik zeg juist dat Konqueror veel sneller aanvoelt, en ik zou hopen dat Firefox onder Linux ook een keer dat soort performance haalt. Sowieso is Firefox geen 'Gnome' programma, dus ik mis even wat de link is tussen Gnome en Firefox.

Gnome gebruikers hebben Gecko browsers, KDE'ers niet.

Ik weet iig dat Qt/X11 er geen last van heeft, dus...trek zelf je conclusies

Open een zeer grote textfile in Kate, open de KDE system guard en ga dan door de text heen scrollen met page down (20 seconden lang ingedrukt houden). Kijk naar het CPU verbruik in KDE system guard en probeer dit ooit maar eens te halen in Windows met notepad.

De X11 implementatie's XFree en Xorg zijn traag.

[b][message=22004525,noline]Het punt is echter dat we hier niet louter over de toolkit praten. Je moet wel eerlijk vergelijken!

Waar en ik ik weet dat ik de term X11 beter had kunnen vervangen door de huidige implementaties ervan.

Firefox (en mozilla ook) is namelijk geen native GTK applicatie en al helemaal geen gnome-applicatie.

Vandaar gebruik ik "deze gelaagde samenwerking".

The_Surfer schreef op 30 oktober 2004 @ 00:03:Err... misschien is het handig dat je wat research doet voor je zulke belachelijke beschuldigingen post? Als je even de profiles had vergeleken (of alleen maar m'n sig had bekeken) dan had je gezien dat ik een die-hard oldskool Gentoo user ben, * Niek en Niek zijn dus een-en-dezelfde

Gelukkig sloot ik dat al niet uit vlak voordat ik op "verstuur bericht" drukte. Sorrie, maar ik zag ff dubbel, snap je?

[Niek]

irondog schreef op 30 oktober 2004 @ 12:37:
(...)
Gnome gebruikers hebben Gecko browsers, KDE'ers niet.

Nu dus wel Overigens was er jaren geleden al een Gecko binding (zit net ergens in kdebindings) die in Konqi integreerde, maar het huidige project gaat veel verder en sterft hopelijk dit keer geen stille dood.

Open een zeer grote textfile in Kate, open de KDE system guard en ga dan door de text heen scrollen met page down (20 seconden lang ingedrukt houden). Kijk naar het CPU verbruik in KDE system guard en probeer dit ooit maar eens te halen in Windows met notepad.

Dit is zo ongeveer de slechtste vergelijking die ik ooit heb gelezen. Wil je Kate (highlighting, dynamic word wrapping, code folding, multiple tabs, ingebouwde terminal, plugin interface) vergelijken met zoiets simpels als Notepad? Hoef ik verder geen woorden aan vuil te maken denk ik.

De X11 implementatie's XFree en Xorg zijn traag.

Nee, dat zijn ze niet. Ik heb het idee dat je _of_ een verkeerde driver gebruikt _of_ bijvoorbeeld RenderAccel niet hebt aanstaan. De combi XOrg/Qt/NVidia is retesnel, mits goed geconfigged

Gelukkig sloot ik dat al niet uit vlak voordat ik op "verstuur bericht" drukte. Sorrie, maar ik zag ff dubbel, snap je?

No problem.

[mOrPhie]

irondog schreef op 30 oktober 2004 @ 12:37:

Gnome gebruikers hebben Gecko browsers, KDE'ers niet.

Ik als KDE-gebruiker gebruik trouwens ook GTK-Applicaties (Gimp, Azureus met GTK-bindings bijvoorbeeld) en kan net zo makkelijk Firefox gebruiken. We hebben het hier niet over Gnome of KDE, maar over GTK en QT. Dat KDE-users geen gecko-browsers hebben is dus niet waar. Het is alleen een applicatie die gebruik maakt van GTK en niet van QT. Met die beredenering zou iemand die Window Maker of Fluxbox gebruikt helemaal geen browser hebben buiten lynx en links om.

Correct me if I'm wrong blouweKip , maar blouweKip gebruikt zelfs konqueror in gnome, zoals ik in z'n screenshots heb kunnen zien.
(en ik doe trouwens precies hetzelfde op de Fedora-bakken op m'n studie)

Dat is waarom ik eigenlijk een QT-Mozilla puur iets vind voor iemand die waarde hecht aan een eenduidige theme van z'n toolkit en begrijp me niet verkeerd; die zijn er zat (ik ook stiekem een beetje ). En daarom ook meer voor een Gecko kpart ga.

[dawuss]

mOrPhie schreef op 30 oktober 2004 @ 13:11:
[...]


Ik als KDE-gebruiker gebruik trouwens ook GTK-Applicaties (Gimp, Azureus met GTK-bindings bijvoorbeeld) en kan net zo makkelijk Firefox gebruiken. We hebben het hier niet over Gnome of KDE, maar over GTK en QT. Dat KDE-users geen gecko-browsers hebben is dus niet waar. Het is alleen een applicatie die gebruik maakt van GTK en niet van QT. Met die beredenering zou iemand die Window Maker of Fluxbox gebruikt helemaal geen browser hebben buiten lynx en links om.

Correct me if I'm wrong blouweKip , maar blouweKip gebruikt zelfs konqueror in gnome, zoals ik in z'n screenshots heb kunnen zien.
(en ik doe trouwens precies hetzelfde op de Fedora-bakken op m'n studie)

Dat is waarom ik eigenlijk een QT-Mozilla puur iets vind voor iemand die waarde hecht aan een eenduidige theme van z'n toolkit en begrijp me niet verkeerd; die zijn er zat (ik ook stiekem een beetje ). En daarom ook meer voor een Gecko kpart ga.

Voor theming hoef je het niet te laten: GTK2 heeft een leuke theme engine, genaamd "GTK-QT", die je GTK widgets vertaalt naar QT widgets.
Verder kan ik niet zeggen dat op mijn machine GTK2 sneller rendert dan QT, terwijl ik helemaal niet zo'n snelle bak heb
Zijn hier betrouwbare tests / cijfers over?

[irondog]

The_Surfer schreef op 30 oktober 2004 @ 12:50:
Nu dus wel

Ja, het komt eraan. Beter beter.

Dit is zo ongeveer de slechtste vergelijking die ik ooit heb gelezen. Wil je Kate (highlighting, dynamic word wrapping, code folding, multiple tabs, ingebouwde terminal, plugin interface) vergelijken met zoiets simpels als Notepad? Hoef ik verder geen woorden aan vuil te maken denk ik.

Neem mij even serieus en pak Ultra Edit i.pv. Notepad óf Kwrite i.p.v. Kate. Windows doet het scrollen en dergelijke met een minimale CPU belasting, terwijl dat in Xorg echt ondenkbaar is. Ga dit wezelijke verschil tussen Windows en Linux nu niet weg proberen te praten al speelt Windows vals door grafische dingen in kernel mode te doen.

Utra Edit en Kate is een betere vergelijken en UE is even snel als notepad qua scrollen, vandaar dat ik notepad gemakshalve gewoon noemde.
UE (CPU load < 5%).
Kate (CPU load > 90%)

En ja, dit is net als de vorige monkey test een belachelijke test, maar je ziet maar wat efficiënter met zijn bronnen omgaat. Ik wil nix afkraken, ik had gewoon liever een ideale wereld.

[dawuss]

irondog schreef op 30 oktober 2004 @ 13:33:
[...]
Ja, het komt eraan. Beter beter.


[...]
Neem mij even serieus en pak Ultra Edit i.pv. Notepad óf Kwrite i.p.v. Kate. Windows doet het scrollen en dergelijke met een minimale CPU belasting, terwijl dat in Xorg echt ondenkbaar is. Ga dit wezelijke verschil tussen Windows en Linux nu niet weg proberen te praten al speelt Windows vals door grafische dingen in kernel mode te doen.

Utra Edit en Kate is een betere vergelijken en UE is even snel als notepad qua scrollen, vandaar dat ik notepad gemakshalve gewoon noemde.
UE (CPU load < 5%).
Kate (CPU load > 90%)

En ja, dit is net als de vorige monkey test een belachelijke test, maar je ziet maar wat efficiënter met zijn bronnen omgaat. Ik wil nix afkraken, ik had gewoon liever een ideale wereld.

Om even een korte toevoeging te doen op deze monkey test: Onder GVIM (GTK) krijg ik het niet voorelkaar mijn CPU load boven 30% uit te krijgen door hysterisch te scrollen.
Nu vind ik 30% nog steeds veel te veel, dus je punt is duidelijk, maar 90% vind ik wel erg extreem

Edit: Misschien even vermelden dat ik X.org draai met hardware accelerated composite en damage extensions

[ Voor 6% gewijzigd door dawuss op 30-10-2004 13:47 ]

[mOrPhie]

irondog schreef op 30 oktober 2004 @ 13:33:
Kate (CPU load > 90%)

Ik wil dit best even testen zodra ik thuis kom, maar ik geloof er weinig van. Als je een load hebt boven de 90% met het verplaatsen van kate, dan heb je imho een heel ander probleem. Ook heb ik nog nooit snelheidsproblemen gehad met scrollen in Kate, laat staan in kdevelop bijvoorbeeld.

Bovendien lijkt het me niet relevant voor dit topic.

[FCA]

Misschien kunnen we het afsplitsen ofzo, maar ik vind het wel een interessant onderwerp die scroll-speed:
Ik heb de test maar eens zelf gedaan, kate (en kwrite) geven idd zo'n 90% processortijd aan X als je pagedown ingedrukt houd. Bij dezelfde test in Nedit daarentegen komt het processorgebruik niet boven de 20%.
Ik heb geen gtk2 of gtk editors even snel bij de hand, maar het lijkt er dus op dat de gebruikte toolkit (hier dus Qt vs Motif) wel degelijk een groot verschil uitmaakt qua snelheid.

[blouweKip]

Correct me if I'm wrong blouweKip , maar blouweKip gebruikt zelfs konqueror in gnome, zoals ik in z'n screenshots heb kunnen zien.

idd, konqueror is wat mij betreft een stuk beter (wat betreft useability en mogelijkheden) dan bijvoorbeeld nautilus, alleen jammer dat je naast qt niet alleen konqueror (plus wat kparts) los kan installeren.

[dawuss]

blouweKip schreef op 30 oktober 2004 @ 18:47:
[...]

idd, konqueror is wat mij betreft een stuk beter (wat betreft useability en mogelijkheden) dan bijvoorbeeld nautilus, alleen jammer dat je naast qt niet alleen konqueror (plus wat kparts) los kan installeren.

Dat kan wel met Gentoo, ik heb er nu geen tijd voor, maar ik zal het even voor je opzoeken

[Niek]

dawuss schreef op 30 oktober 2004 @ 19:18:
[...]

Dat kan wel met Gentoo, ik heb er nu geen tijd voor, maar ik zal het even voor je opzoeken

http://kde-metaebuilds.berlios.de/

Maar dan blijft je nog de dependencies op kdelibs/kdebase houden. In de toekomst is dit niet zo erg, omdat HAL/D-BUS geintegreerd worden in de desktops (KDE/Gnome) en de oude technieken vervangen is bijv het trage starten van dcop verleden tijd (iedereen die wel eens een KDE app buiten KDE heeft gedraaid weet wat ik bedoel).

[pelleke]

Hoe zit dat precies met die kdebindings? Dat klinkt nl. interessant. Ik hou nl. van Konqi, maar niet van KHTML. Dat is persoonlijk, ik weet 't, maar hoe krijg ik die kdebinding aan de praat? (EN je wist 't natuurlijk al lang, GENTOO-user MELDT zich.)

// EDIT
Vind mijn post ineens heel slap. Konqi integreert wat lekkerder in KDE, downloads, filemanager, web allemaal in 1 ding. Vin ik zelf lekker. Draai nu FF op GTK2 vanwege Gecko, gewoon ge-emerged. Maar gecko in konqi is ook eigenlijk waar ik naartoe wilde, maar ik d8 dat we dan nog wel een half jaar konden w88.

Is die kdebindings-troep voor gecko officieel gereleased? En hoe installeer ik die?

[ Voor 47% gewijzigd door pelleke op 31-10-2004 15:44 . Reden: Post zinniger gemaakt. :) ]

[mOrPhie]

pelleke schreef op 31 oktober 2004 @ 15:42:
Hoe zit dat precies met die kdebindings?

Het was een binding met mozilla. Maar omdat het zo oud is zou het, naar het schijnt, sinds Mozilla 1.2 niet meer werken.

quote: http://dot.kde.org/1055858793/1055870108/1055970214/

> BTW: I remember that there is a Konqueror mozilla binding. What does this really mean? Can i use the Mozilla 1.4 RC2 enging instead of Konqueror's to display web pages in konqueror with?

It means that Konqueror would use Gecko instead of khtml to render webpages.

However, when it was current, very few people actually used it, so it's become unmaintained and doesn't work with anything past Moz 1.2 afaik. It was cool and all, but it always felt weird using a KDE app with gecko

Perhaps if one day the Qt port of Mozilla (which gradually became unmaintained years ago once khtml started becoming better, and for a time, had eclipsed gecko until about Mozilla 0.8-0.9 or so) was revived and added back into the main development trunk.

Bedenk dat deze quote ook alweer meer dan een jaar oud is. Ik denk dat die bindings dan ook helemaal niet meer werken.