Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 29 reacties
Bron: Ars Technica

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.

Mozilla logo (klein)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.

Konqueror
Moderatie-faq Wijzig weergave

Reacties (29)

Betekent dit dat binnenkort Safari ook met Gecko kan gaan renderen?
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).
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).
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++ :P
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.
Hoogstwaarschijnlijk niet. Safari is gebaseerd op de KHTML engine, niet op Konqueror zelf.
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.
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.
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)
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.
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.
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.
De Mozilla Foudation

typo :)
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.
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?
I.h.a. geldt wel dat minder code = makkelijker te begrijpen = makkelijker onderhoud.
Wat me dan weer opvalt, is dat mensen denken dat dit een keuze van het Konqueror team is geweest, maar vergeten dat iedereen dit had kunnnen doen ( met genoeg tijd en kennis natuurlijk ). Het hele idee van GPL en vrije software is niet alleen gratis maar ook vrij om aanpassingen te maken, ook dingen waar de originele auteur niet achter staat.

Ik vind het idee geweldig, ik gebruik nogsteeds firefox/thunderbird onder KDE, maar met 3.3 is in KMail alles opgelost wat ik miste, dus ik ga binnekort weer naar KMail en als ik dus onder Konqueror kan kiezen tussen Gecko of KHTML, dan wordt het hoog tijd om toch maar eens een weekje met Konq. te gaan werken.
De implementatie van deze nieuwe ontwikkeling vond plaats tijdens de aKademy, een KDE-conferentie in Duitsland.
implementatie moet presentatie zijn?
Implementatie klopt wel.
In het nieuwsbericht is te lezen dat de benodigde code om dit te realiseren, KPart, in vier dagen is ontwikkeld. Is dus waarschijnlijk (grotendeels) tijdens de conferentie zelf gebeurd.
Nee, aKademy bestond uit een aantal delen (het duurde dan ook 10 dagen ofzo), waarvan een behoorlijk deel gereserveerd was voor een `hackfest'. Gedurende die activiteit is dit idee ge´mplemententeerd (en nog veel, veel meer). Het is dus echt tijdens aKademy ge´mplementeerd.
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.
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 :9
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.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True