KDE krijgt ondersteuning voor Gecko-engine

Ars Technica meldt dat KDE-ontwikkelaars ondersteuning voor de HTML-rendering engine van Mozilla hebben toegevoegd aan Konqueror. Konqueror is de standaard webbrowser voor het KDE-platform en maakt normaliter gebruik van de KHTML-engine die door de ontwikkelaars van KDE zelf is ontwikkeld. De Mozilla HTML-engine Gecko wordt momenteel gebruikt door Mozilla, Firefox, Galeon en Epiphany maar kan nu dus ook door Konqueror worden gebruikt in plaats van de KHTML-engine.

De implementatie van deze nieuwe ontwikkeling vond plaats tijdens de aKademy, een KDE-conferentie in Duitsland. De ontwikkeling van een zogenaamd KPart van de Gecko-engine duurde slechts 4 dagen. Hoewel het geheel nog niet in alle details is afgewerkt, is het bruikbaar. In de toekomst is dan ook de verwachting dat Konqueror kunnen kiezen welke HTML-engine ze willen gebruiken. De Mozilla Foundation, de organisatie achter de Mozilla-browser, heeft ondersteuning toegezegd aan het initiatief. Ars Technica vraagt zich nu af of de nieuwe ontwikkeling geen negatieve gevolgen zal hebben voor de minder gebruikte KHTML-engine. Mozilla wordt momenteel meer gebruikt dan de HTML-engine van KDE en is daardoor vaak beter compatible met websites dan KHTML. Het voordeel van KHTML boven Gecko is dat eerstgenoemde een kleinere 'codebase' heeft en dus uit minder regels programmacode bestaat. Naast KDE gebruikt ook Apple deze engine in zijn Safari-browser.

Reacties (29)

[MahRain]

Betekent dit dat binnenkort Safari ook met Gecko kan gaan renderen?

[FailFr8er]

Nee, Safari wordt onderhouden door Apple, niet door het KDE-team. Apple zal dus zelf de beslissing moeten nemen om over te stappen op de Gecko engine, en Apple kennende zullen ze dat niet snel doen.

Ik vind het een beetje dubbelzijdig, wel een eigen engine maken, en dan later ondersteuning bieden voor de ander. Zo kun je er op nagaan dat KDE's KHTML-support doodbloedt, omdat Gecko gewoon een stuk beter werkt...

[edit]
Voor details over beter werken, 't zijn voornamelijk CSS zaken, CSS menu's die niet werken enzo. Ben ik heel veel tegenaan gelopen met Konqueror. Of een memleak op gewone pagina's die XHTML 1.1 en CSS validated zijn (en die voor de rest niets raars qua scripts erop hebben).

[Verwijderd]

Eerst maak je een eigen engine omdat er geen goed alternatief is, en vervolgens (als die er wel is) bouw je support voor de betere engine in.

Dat is niet 'dubbelzijdig', maar gewoon grootmoedig je verlies kunnen toegeven.

Ook als beide engines gelijkwaardig zijn dan is dit een teken dat men niet streeft naar markt-dominatie, maar naar goede kwaliteit voor de gebruiker (die kan nu immers meer kiezen).

[jimshatt]

Meer keuze betekent niet per se betere kwaliteit. In dit geval durf ik het tegenovergestelde te beweren. Ik wil gewoon Konqueror met 'de beste' rendering engine, en daar verder zelf niets aan doen. Of dat Gecko vanwege z'n standards support is, of KHTML vanwege z'n performance is, die afweging moeten de makers van Konqueror maken, anders kun je net zogoed geen 'product' op de markt zetten. Dan kun je net zo goed zeggen, ik heb een browser waar je ALLES zelf kunt kiezen, het heet C++

[Verwijderd]

Ik vind het een beetje dubbelzijdig, wel een eigen engine maken, en dan later ondersteuning bieden voor de ander.

Gecko heeft als voordeel dat het volwassener is dan KHTML, maar de Gecko code is oud, ingewikkeld en zeer omvangrijk. Nieuwe features toevoegen aan Gecko is heel arbeidsintensief.

KHTML heeft als voodeel dat het jong, snel, licht is, en heel elegant in elkaar steekt. De code is veel mooier en makkelijker uit te breiden dan die van Gecko. Nadeel van KHTML is dat het nog niet heel volwassen is.

KHTML zal zeker niet verdrongen worden door Gecko, omdat het een te mooi produkt is.

Beide zn eigen voordelen en nadelen dus, en nu is er de keuze welke je wil gebruiken in Konqueror.

[Verwijderd]

Hoogstwaarschijnlijk niet. Safari is gebaseerd op de KHTML engine, niet op Konqueror zelf.

[Verwijderd]

Betekent dit dat binnenkort Safari ook met Gecko kan gaan renderen?

Nee, ik denk niet dat Safari zo flexibel is dat je er even een andere engine in hangt. In KDE is dat waarschijnlijk veel eenvoudiger.

[Verwijderd]

Vind het wel een goeie ontwikkeling. Alhoewel ik toch gnome gebruiker ben en maar zelden Konqueror gebruik, is mijn ervaring met KHTML als browser niet zo goed. Veel sites deden het niet goed of zagen er toch niet zo goed uit als op Firefox.

Ik denk echter niet dat KHTML nu langzaam aan gaat verdwijnen, want volgens mij is die engine heel goed te gebruiken voor embedded browsers, zoals je nu op windows heel vaak van die IE controls heb die als enige doel hebben om een voorgeprogrammeerde site weer te geven. Zo'n site kun je makkelijk specifiek voor zo'n engine maken zodat ie altijd werkt.
Als specifiek voorbeeld kan je bv Steam (valve's content platform, voor iedereen die geen games speelt) aangeven. Die gebruikt veel te veel kleine embedded IE controls (die zowiezo al een security leak zijn omdat het IE is, maar daar gaat het hier niet over), alleen om tekst of een banner weer te geven. Als je zo'n programma op Linux zou hebben zou je daar denk ik beter KHTML voor kunnen gebruiken dan de zwaardere gecko engine.

[lambda1]

Alhoewel ik toch gnome gebruiker ben

Als je zo'n programma op Linux zou hebben zou je daar denk ik beter KHTML voor kunnen gebruiken dan de zwaardere gecko engine.

Als gnome gebruiker zou ik dan toch eerder geneigd zijn om libgtkhtml te verkiezen, op die manier kun je toch een volledige GTK+ desktop gebruiken

gtkhtml wordt momenteel vooral door de ximian mensen ontwikkeld (wordt vaak gebruikt in Evolution)

[cashewnut]

Dat is het koole van KDE: de object-oriented structuur. Zo is er ook al een KPart die gebruik maakt van OpenOffice om die filetypes te bekijken.

Ik denk btw niet dat KHTML nu doodbloedt; ten eerste is er binnen KDE veel kennis van deze engine, en ten tweede is KHTML kleiner en "schoner". Deze dingen maken het doorontwikkelen een stuk makkelijker.

[ATS]

Hoewel de ondersteuning voor Gecko nieuw is, is het kunnen kiezen van de rendering engine niet nieuw. In het verleden kon je al eens kiezen. Helaas is dit toen doodgebloed. Ik ben benieuwd of het initiatief dit keer een langer leven beschoren is. Overigens is deze post misschien verhelderend voor mensen die zich afvragen wat nu precies de plannen voor dit initiatief zijn en wat de consequenties. Het betreft hier een van de auteurs van de port.

[irondog]

In princiepe gebruik ik Konqueror liever dan Mozilla. De associaties voor bestandstypen die ik in KDE instel, worden compleet genegeerd door Mozilla. Mozilla in KDE integreert dus ook voor geen meter: knoppen, scrollbalken e.d. zien er compleet anders uit en open/save dialogs zijn om te huilen zo slecht en gebruikersonvriendelijk. Met themes is dit probleem uiteraard slechts zeer beperkt op te lossen.

Konqueror kan ik echter zeker niet instellen als default browser en dan mijn zusje, m'n ex of een van mijn vrienden (die bijna allemaal ook veel met computertechniek bezig zijn) achter mijn pc laten werken. Het eerste wat dit soort windows gebruikers doen is naar lijpe sites gaan met gigantische javascripts die volledig ontwikkeld zijn in MSIE en hooguit een keer getest in Mozilla (WTF is khtml zullen de meeste frontpage gebruikers zeggen).

Kijk, ikzelf heb niet zoveel sites die niet werken in KHTML. Ik vervloek en ban de sites die standaarden niet respecteren en kom nooit meer terug. Maar datzelfde doen mensen met een desktop environment die hun favo pagina niet goed weergeeft. KDE heeft dit echt nodig!

offtopic:
Standaarden zouden beter gerespecteerd moeten worden en in een perfecte wereld zou Konqueror echt geen gecko nodig hebben om functioneler te zijn.

[Starck]

De Mozilla Foudation

typo

[zeekoe]

GoT > Frontpage Algemeen > Spel- en typefoutjes - deel 8

[Proxy]

Er is iets fout gegaan. Probeer het later nog eens, of ga terug.
Je bent gebanned Proxy, permanent.
(interne identificatie: user::check_ipban::banned_forever)

Daarom dus hier i.p.v. op GoT.

[Olaf van der Spek]

Het voordeel van KHTML boven Gecko is dat eerstgenoemde een kleinere 'codebase' heeft en dus uit minder regels programmacode bestaat.

Dat is toch geen voordeel op zich?

[Verwijderd]

I.h.a. geldt wel dat minder code = makkelijker te begrijpen = makkelijker onderhoud.

[smokalot]

Toch wel erg mooi dat KDE zo flexibel is.

Ik gebruik overigens altijd konqueror, en die rendert bijna alles zoals het bedoeld is. Bij een pagina die het niet doet weet mozilla het soms wel, soms niet voor elkaar te krijgen.

Vind het nogal een ingrijpende wijziging, die wat mij betreft niet nodig was geweest.

[ATS]

Het is juist totaal geen ingrijpende wijziging. In de rest van de KDE code wordt namelijk niets gewijzigd! Je kan gewoon in je menutje View -> View Mode een Gecko kiezen in plaats van KHTML (en de andere opties die er nu al staan). Op welke manier is dat ingrijpend?
Overigens kan natuurlijk omiddelijk ook elke andere KDE applicatie gebruik maken van Gecko als ze dat willen. Lang leve kparts

[Verwijderd]

Vind het nogal een ingrijpende wijziging, die wat mij betreft niet nodig was geweest.

Je kan nog steeds KHTML gebruiken als je dat wil. Ik denk zelfs dat Konqueror standaard nog wel KHTML zal gebruiken. Er komt nu gewoon een extra keuze bij, en da's altijd mooi meegenomen.

Verder lijkt het meest interessante wel de integratie van Firefox in KDE. Dus dat je wachtwoorden worden bewaard in KWallet, je de file-dialogs van KDE krijgt, enz.

[TheNose]

Ook fijn is dat Mozilla/Firefox nu gecompileerd kan worden met QT in plaats van GTK, waardoor deze programma's er beter / natuurlijker uit zullen zien onder KDE in Linux.

[Verwijderd]

Ja inderdaad. Ik vindt Firefox veel fijner werken als Konqueror maar niet in mijn favoriete Desktop Environment KDE.

Knippen en plakken werkt niet goed. Als je Firefox afsluit zijn de gegevens uit het geheugen. Ook mist de look en Feel van KDE natuurlijk in het GTK gecompileerde Firefox.

Ik hoop dan ook dat er ook QT versies van Firefox komen want het is een heel fijne browser.

[Michali]

In de toekomst is dan ook de verwachting dat Konqueror kunnen kiezen welke HTML-engine ze willen gebruiken.

Beetje vreemde zin vind ik het. Mischien moet het zijn: "dat gebruikers van Konqueror kunnen"...?

Ik vraag me verder wel af hoe ze dit gaan doen dan? Of je dan twee smaken die apart te installeren zijn krijgt of dat dit bij de instellingen zo te switchen is. Het lijkt me een beter idee om de gewoon de best functioneerende zo goed en stabiel mogelijk te implementeren en niet voor twee smaken te gaan. Denk dat weinig mensen dat toch voor de mindere zullen gaan wat dus betekent dat het werk hieraan eigenlijk een beetje tijd verspilling is.

[ATS]

Dat kiezen van engine is in KDE heel erg eenvoudig. Dat kan nu ook al, en daar hoeft Konqueror niet voor aangepast te worden. Alle kparts die met het mimetype text/html (in dit geval) overweg kunnen komen in een menutje terect (View -> View Mode), en als je een Gecko kpart aan KDE toevoegt, dan komt die daar gewoon automagisch tussen te staan. Op het moment staan er bij mij al vier opties daar, waar onder KHTML.