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

Mozilla stopt met ondersteunen embedded Gecko

Mozilla heeft aangekondigd niet langer het embedden van browserengine Gecko in andere applicaties te ondersteunen. De benodigde code wordt niet meer onderhouden en staat nieuwe ontwikkelingen voor Gecko in de weg, aldus Mozilla.

Bij monde van Benjamin Smedberg, die verantwoordelijk is voor Gecko's embeddingmodules, heeft Mozilla bekendgemaakt niet langer binary embedding te ondersteunen. Volgens Smedberg kost de ondersteuning veel tijd die ook in Firefox gestopt kan worden. Ook passen aanstaande verbeteringen in de Gecko-browserengine, zoals het splitsen van pagina's renderen en de gebruikersinterface in verschillende processen, slecht in de huidige oplossing voor embedding.

Smedburg geeft aan de modules gtkmozembed, javaxpcom en de ActiveX-control en plugin te verwijderen uit de Gecko-code. Geïnteresseerde ontwikkelaars kunnen zich melden om deze modules te onderhouden. Smedberg sluit niet uit dat in de toekomst, zodra het renderen in Gecko door een apart proces gebeurt, gekeken wordt naar een nieuwe manier om embedding mogelijk te maken.

Het team achter Camino, een browser van Mozilla voor Mac OS X, overweegt door de aankondiging Gecko in te ruilen voor WebKit. Camino gebruikt Apples Cocoa-interface in plaats van Mozilla xul. Het ondersteunen van embedden heeft nooit een hoge prioriteit gehad bij Mozilla, waardoor de ontwikkeling van Camino achterligt op Firefox. De ontwikkelaars van Camino werken aan de binnenkort te verschijnen versie 2.1 van de browser, die dezelfde Gecko 1.9.2-engine gebruikt als Firefox 3.6.

Door Bart de Water

Nieuwsposter

03-04-2011 • 10:32

42 Linkedin Google+

Reacties (42)

Wijzig sortering
een beetje onduidelijk bericht, ergens anders las ik dit:

I'm a developer at Mozilla. It looks like there is some confusion about this announcement.

1. Most importantly, *it is still possible to create applications that use Gecko*. Even without the Gecko embedding APIs, you can write such apps. For example, there are two separate Mozilla-supported apps that use Gecko: Firefox and Fennec (mobile Firefox). There is also Songbird, which is written in a similar way (the article mistakenly implies Songbird will be negatively affected by this announcement, which is not true - the situation for them is very different than for Camino, for example).

In other words, you *can* still write Gecko apps, but you must integrate tightly with Gecko. This is sort of like the Linux kernel not committing to a stable API, things change as needed (people sometimes complain about that, but overall it lets the kernel move forward faster). Similarly, for Mozilla moving forward is much easier without committing to stable APIs for embedding. But again, you can still write apps that use Gecko without such APIs, just like you can write code for Linux.

2. Second, to clarify the term 'killed' that the article used: If someone steps up to maintain the embedding APIs, they can continue. So in that sense nothing is 'killed'. It is just that Mozilla itself, however, isn't focusing on them, for the reasons I mentioned before.

So, where does this leave things? If you want to write an app that embeds an HTML engine, you can still choose Gecko or WebKit. WebKit is easier to embed, but that has a price. As an example, look how quickly Google added cross-process support to Chrome, without any stable API promises and without anything but Chrome benefiting; Apple is adding cross-process support to WebKit itself, with a stable API, but it is still not complete as the process takes much longer.

I would argue, however, and this is totally my personal opinion - not Mozilla's - that all of this *doesn't really matter*. The places that need to embed a web browser are decreasing, not increasing, because things are moving *into* web browsers, not vice versa. What I am trying to say, is that these days people fire up their web browser and do everything from read news to check email to play games. They don't have separate apps for each that embed a web browser, they have a single web browser for all their activities.

Current applications that embed web browsers, like say Songbird, could today be websites or browser plugins, as browser capabilities have improved so much recently. For that matter, alternative browsers like Flock and RockMelt could be browser plugins.

That leaves projects like Camino and Epiphany that provide much better OS integration than cross-platform browsers like Firefox or Chrome. There is a place for such OS integration. Some of it can be achieved with browser plugins, but I concede that it might be necessary in some cases to do more. I think that such work code be done with the upstream projects, though, to get the best results, as opposed to separate projects that just embed rendering engines. For example, Firefox can render using Qt on Linux, but it needs more love - would be great to see more Qt hackers contribute upstream on that, and to get Firefox/Qt stable.

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True