Laut einem von dot.kde.org veröffentlichten Bericht planen die Entwickler, »das Beste der beiden Welten zu vereinen«. Wie Lars Knoll vom KHTML-Projekt betont, wird die neue Engine »eine Menge Türen öffnen«, ohne dass der Benutzer einen Kompromiss eingehen muss, was das saubere Design von KHTML angeht. Das neue Produkt soll als eine KDE-Komponente KPart realisiert werden und keinesfalls ein Ersatz, sondern eine Ergänzung zu KHTML darstellen.
Noch während der diesjährigen KDE-Konferenz aKademy haben Lars Knoll und Zack Rusin innerhalb von vier Tagen einen ersten lauffähigen Port von Gecko für Qt und KDE fertig gestellt. Laut eigenen Aussagen soll die Lösung mittlerweile durchaus ausgereift sein und das Team befindet sich an einer Anbindung der neuen Engine an die höheren Funktionen des Konqueror-Browsers wie dem Password-Manager KWallet oder der Cookie-Verwaltung KcookieJar.
Die KParts-Architektur von KDE, auf die die neue Gecko-Erweiterung fußen wird, ermöglicht es, die Funktionalität einer Applikation in verschiedenen Programmen zu nutzen. Gegenüber einer API-Bibliothek basiert die Architektur auf Standardkomponenten von Qt/KDE wie z.B. QWidget oder KmainWindow und benutzt einen sehr einfachen Satz von Klassen. Jede Komponente ist in einer Bibliothek »gespeichert« und wird zur Laufzeit dynamisch zum Programm hinzugefügt. Es wird deshalb technisch gesehen problemlos möglich sein, zwischen der HTML-kompatiblen Bibliothek KHTML, die unter anderem DOM, Java, JavaScript und Cascading Style Sheets (CSS) unterstützt, und der Standard-Rendering-Engine Gecko des Mozilla-Browsers zu wechseln.
