Mozilla, Embedding, Small Devices (and gtkmozembed)
This past week I’ve written a couple of patches to make embedding Mozilla easier/better:
- Bug 321359 – Give embedders the ability to lock and select profiles
- Bug 299988 – Integrate gtkmozembed with libxul
This second patch caused some concern: I made gtkmozembed use the new toolkit profile-management APIs (gtkmozembed will no longer build with seamonkey). This is not a problem of itself, since Mozilla has already made a commitment that libxul will be the ongoing embedding framework.
The more difficult problem is that the toolkit (xulrunner) currently doesn’t support a lot of the “small-device” build options such as --disable-xul. We definitely want to continue to support small device embedding situations, while avoiding the costs of supporting an exponential combination of little build options that may have complex interactions. This provoked a spirited discussion among drivers@mozilla.org about what options are valuable to support and who should bear the support burden of these options. The provisional outcome of this discussion is as follows: Mozilla is interested in maintaining a couple of “small device profiles”, in cooperation with small-device embedders (cell phone manufacturers and others). I have written up a wiki document with a preliminary proposal describing three profiles. I would like to get input from small-device embedders about what features they actually need, and to what extent they are able to help in the maintenance and documentation of these small-device profiles.
This proposal results in a slightly illogical situation of a small-device “XULRunner” build that doesn’t actually support XUL (it would be an embedding solution). In this sense what you are building is really more “GeckoRunner”; but there’s no need to get caught up in naming…
I’d also like to reiterate that this support is explicitly for small devices that can’t handle the full XULRunner footprint. It doesn’t make sense to have a small-device profile of XULRunner installed on a PC; it is important to support a full-featured web if there are sufficient system resources available.
January 13th, 2006 at 1:15 am
> gtkmozembed will no longer build with seamonkey
What does that mean in practice? Will my builds break, since –enable-tests builds gtkmozembed last I checked? If so, what can I do to fix the breakage?
January 13th, 2006 at 7:46 am
No, your build will not break, building gtkmozembed will be ifdef MOZ_XUL_APP.
January 13th, 2006 at 11:49 am
benjamin,
I read up your previous posts about “what’s coming for gtkmozembed” [1], ‘Testing Matrix’ and they are pretty convincing about the real difficults of keeping both ’embedded’ toolkits (XUL and gtkmozembed) independent. Looking over a mantainer point of view, I’d say DO THAT NOW :) !! But, have you looked over embedders point ? (probably yes, of course)
I’m wondering if in a “minimal configuration”, where XUL itself won’t be supported, but XULRunner(the toolkit), is it ? If so, can you tell me how could I save in terms of footprint if I built the minimal with disable-xul, just caring about gtkmozembed stuff ?
My worries are just because supporting or not –disable-xul, –disable-libxul, or –disable-whateverthatusesxul build options could be really critical choice/change for some embedders like me :) … btw, I’m working on some Nokia 770 browser projects, and XUL apps are suitable in such a device, so far …
[1] http://benjamin.smedbergs.us/blog/2005-12-23/whats-coming-for-gtkmozembed/
January 13th, 2006 at 3:05 pm
doug has clarified some points at [1]
[1] http://weblogs.mozillazine.org/dougt/archives/009576.html
interesting, although I’m not entirily sure about the numbers we will get …
February 4th, 2006 at 7:45 am
One of the advantages of XULRunner on embedded devices would be, that it could be the only widgetset needed, and this, of course, is only possible with XUL built in.
Why would (ie) a Smartphone vendor install the Gecko engine *and* install some widget-system in addition ? This does not save memory. Of course, all could be done using DHTML, not installing any widgetset.
As someone who would like to see XULRunner on his Linux powered Smartphone (as a complete replacement for the current middleware) the main interest to me is
* windowless (ie: direct on a framebuffer, fullscreen, root-window like)
* XUL-native widgets – since we do not use any wm and no hosted widget-set
* full LDAP support inline to XUL apps (no sync-bs anymore. Directly store and retrieve contacts, buddy-lists and bookmarks from a central server. HomeServers will be more common the next years).
This would mean, that all, that is needed for a capable Smartphone would be something like Seamonkey (since it is a communications-suite), sans HTML editor but with added things like IM and XUL applications (mediaplayer (VLC), etc.) running on top of Linux.
December 11th, 2007 at 2:08 pm
[…] people working on mozilla guts (summarized by benjamin) are worried about the hundreds of options that configure.in gives you. There is a […]