The real issue is not gtkmozembed but whether or not there exists a way to embed gecko into a GTK app anymore via some other method. If its still possible to embed gecko into GTK, we are good since the only thing we need to remain ABI compatible for users of microb/gecko is the dbus interface exposed by tablet-browser-daemon (for nokia maps it doesn't look like cloning the actual nokia-maps binary so it can talk to the browser engine in a different way would be a massive undertaking)

If there is no way to embed Gecko into a GTK app anymore then we could come up with a new browser engine/UI that replaced microb as the system web browser (with the same level of system integration as microb had) and kept only those bits that rtcom-messaging-api/maps actually need.

So to figure out where we go from here we need to answer the following questions:
1.Which non-browser packages on Fremantle use libraries that can be considered part of the "browser" (whether that be tablet-browser-*, browser-eal, browser-neteal or otherwise)
2.Is there still a way to embed the Gecko rendering engine into a GTK application that can be used on Fremantle? (via embedlite or otherwise)
and 3.If not, is there a way to embed Webkit into a GTK application that can be used on Fremantle?

Having regard to the answers to #2 and #3, would it be better to:
A.Use new-Gecko as a replacement for browserd
B.Use new-Gecko in a new browser UI (that replaced the system browser but not the engine used by rtcom-messaging-api/maps)
C.Use Webkit as a replacement for browserd
D.Use Webkit in a new browser UI (that replaced the system browser but not the engine used by rtcom-messaging-api/maps)
or E.Keep microb as the system browser but make a new browser (with either engine) that installed alongside microb (and didn't try to integrate with any system stuff)

Further to marmistrz's link, here's my repo. It's a few commits ahead, a bit of clean up, some refactoring and beginnings of bookmark support. The aim was going to be to track as much cpp code from sailfish-browser as possible so I only really had UI code to work on. I didn't want to start working on qt5 until the xcb workaround was properly solved and more projects were working with it.
https://github.com/android-808/microbe

Qt Quick Controls can be themed, like what is done at the moment for Desktop in qt5.3 and Android and iOS in qt5.4.
https://qt.gitorious.org/qt/qtquickc...ontrols/Styles


qt-components-hildon could be used as a reference for the theme. This was something I'd been toying with for Jessie. Ditch as much QtMaemo5 stuff as possible and externalize the remaining module like libqt5x11extras5 so I could use stock Debian qt5.

Qt5/GTK3/general outdated libs are a real annoyance to me.

With regards to gtk2, I don't see why there wouldn't be a way. At the end of the day qtmozembed only acts as a simplified wrapper around existing functions within embedlite. Can we not just track down the last version of gtkmozembed and see what needs adapting to work with recent embedlite/gecko. I would rather use embedlite because IIRC it works on a similar design to the changes used in microb.

So the first place to start is to find the Mozilla mainline code that matches the Fremantle codebase. Anyone know how to track that down?

Have a look here for Fremantle:

https://garage.maemo.org/projects/browser

and here Mozilla:

https://hg.mozilla.org/mozilla-central/

Now you just need to match them up. I believe that MicroB is based on Gecko 1.9.

FOSS packages that are part of the browser engine:
tablet-browser-daemon
browser-eal
libgtkmozembed
microb-eal
microb-engine
libnss3
libnspr4
microb-engine-common
browser-neteal
libnss3-certs

Closed source packages that are part of the browser UI:
tablet-browser-ui
osso-browser
tablet-browser-view
tablet-browser-controls
tablet-bookmark-manager
tablet-browser-dialogs
tablet-browser-widgets

Other things that talk to microb: (on a stock Fremantle system, no clue about Extras)
rtcom-messaging-ui (closed source, uses tablet-browser-view and browser-neteal to talk to browserd)
tablet-browser-view-test (open source, uses tablet-browser-view and browser-neteal to talk to browserd)
nokia-maps-core (closed source, talks to microb via browser-eal)
modest (open source, seems to want microb-engine but also gtkhtml, not sure what its really doing)
libmaemosec-certman0 (open source, wants libnss3 for some reason)
tutorial-home-applet (closed source, uses browser-neteal to talk to browserd)

Plugins that work alongside microb: (on a stock Fremantle system, no clue about Extras)
adobe-flashplayer (closed source, implemented as an NPAPI plugin)
libssoautologin (closed source, implemented as an extention with a .xpt file, a .jar file, some .js files and a .so file)
microb-geolocation (open source, implemented as an extention with a .jar file, some .js files and a .so file)
nokia-maps-core (closed source, implemented with 2 NPAPI plugins plus some browser components as .so, .xpt and .js files)
tablet-browser-default-plugin (closed source, implemented as an NPAPI plugin)
tablet-browser-mediaplayer-plugin (closed source, implemented as an NPAPI plugin)

Wfill we be able to keep Flash compatibility if upgading Gecko/switching to Webkit?

i did find a copy of gtkmozembed online but i can't find what version it matches at the moment. it was on a documentation page relating to seamonkey (or whatever original browser now is). seemed to be one header and one cpp file. one widget to act as container and some callbacks for basic functionality.

i'll try to remember where and post link later. callbacks i suppose would just need updating to be similar to those in qtmozembed.

one thought that has just crossed my mind is pulseaudio. how long do we suppose 0.9 series will be supported? i know there has been some work in this area lately but we may eventually be forced to update that as well.

Ok so it looks like microb-engine_20091230-1.9.2.orig.tar.gz in the SDK repos came from some version of the mozilla-central tree (which version it is I cant seem to find) and then microb-engine_20091230-1.9.2-6.8+0m5.diff.gz sits on top of it to add debian packaging (including what looks like a bunch of local patches)

https://bugzilla.mozilla.org/show_bug.cgi?id=906072 indicates that the maemo bits that were in Gecko were removed from Gecko a while back.

Seems like getting newest Gecko to be usable on Maemo might not be so easy, we need to figure out just what bits were removed (in bug 906072 and any number of other bugs) that Maemo was using and which of those bits are actually important and also figure out which of the local patches in the .diff.gz file are actually important.

If the goal was "lets build an alternative browser for Fremantle" we could just get any browser that built and ran on the platform and make it work (e.g. fixing up qmlbrowser to make it go). But the goal isn't that, the goal (at least my goal) is to find a way to make a newer gecko rendering engine function as the system browser on Fremantle (with the same level of system integration as the current one) so we get the advantage of all the security fixes, technology support and other things that come with a new browser but also have the system integration that comes with the current browser engine.

That said with all the bugs that reference removing Maemo-specific stuff (bug 1080529, bug 906072, bug 653201 and likely others), the work required to make anything resembling a recent Gecko to actually be usable (let alone feature complete) on a Fremantle installation may be far more than the few Maemo developers left in the community can handle. And that's before you start thinking about gtkmozembed and what to do about it.

xulrunner i think is 1.9.2.3pre

without going through the lists, i can't say for certain how much is involved. it really depends on what the actual port changed and what can be provided by other means.

AIUI, ipclite and therefore embedlite build on the ideas used in microb. A lot of the microb patches add ui elements (pop up dialogs) within the xulrunner code. embedlite can post signals to the app, which then displays own dialogs and sends results back. at least it can for qt, which are forwarded by qtmozembed.

need to see what mechanism exists for handling events when using gtk.

Wait...

gtkmozembed is deprecated! This means we need extra work to adapt it to the current situation. Besides, there must've been a reason to deprecate it.

Moreover, if we decide to update the engine yearly, it means that the work has to be done yearly!

Wouldn't it be better to redo the UI of Sailfish Browser in Qt5 and simply upgrade all the Embedlite libraries whenever needed? This would also mean being able to use any Sailfish Browser functionality provided the UI is redone.

I'll have my next week extremely busy but I can try building a Qt Quick Controls example after 14th Nov.