only microb parts I know of that are open but not in the Maemo SDK are browser-neteal and tablet-browser-daemon. The UI packages (tablet-browser-view, tablet-browser-widgets etc etc) are all closed unless someone knows something I dont.

As for OpenGL stuff, isn't that just needed for webgl or is Mozilla doing something more with it these days?

They lied to you, see https://bugzilla.redhat.com/show_bug.cgi?id=727914 for example

Yes, it is needed for webgl, but don't we want it? I mean - if we are going to put such an effort, I'd prefer to have it all

Isn't it also needed to offset some of the rendering workload? Is it worth trying to backport GtkGLArea from 3.16?

Would be a hell of a lot easier if freemantle/jessie etc could just ditch gtk2/qt4 for gtk3 etc.

The other suggestion that has been raised is to ditch Gecko completly and use webkit instead (since that still has suitable GTK bindings).
To make that happen and still support the stock stuff, the following things would need to be done:
1.Replace gecko/microb-engine/microb-eal/browser-eal and related packages with webkit (including possibly tablet-browser-daemon)
2.Identify any "special features" in the microb-engine code that webkit doesn't have (e.g. I know microb has a feature where phone numbers on some web pages are highlighted and you can click them to dial them) and support them in webkit
3.Ensure we support whichever bits of npapi are needed by adobe-flashplayer, tablet-browser-default-plugin and tablet-browser-mediaplayer-plugin.
4.Clone/replace libssoautologin and microb-geolocation and make something that works with the new browser engine
5.Handle nokia-maps. This could be done by retaining Gecko/browser-eal/microb-eal for nokia-maps (nokia-maps is the only thing that talks to those libs directly instead of using tablet-browser-daemon as far as I know) or this could be done by cloning and replacing bits of nokia-maps that are tied to Gecko
6.Ensure that tutorial-home-applet, microb UI and rtcom-messaging-api continue to work including any HTML/JS/etc used by these apps.
and 7.Dealing with anything else I missed that is tied to browser (modest I think uses it but that's FOSS so porting it should be possible)

Mostly I am saying that having a modern less-bug-ridden more-secure browser engine on the N900 (and Neo900) would be a good thing, whether that be Gecko, Webkit or otherwise and I am throwing out ideas so we can see which way is the easiest way to achieve that goal and what work might be required for it.

Quick reply...
I would enjoy seeing MicroB revived with the newest-possible Gecko engine inside.
Supporting GtkMozEmbed. Whole Fremantle is Gtk-based; it would make no sense to use Qt-*-embed.
Not Webkit. Handling 'small' differences between old-Gecko and new-Webkit would be more difficult than going from old-Gecko to new-Gecko?

Thank you. Best wishes.
If there are small tasks, beta-testing, or thorough-reading-search of code (html-markup in maps, for example) to be done, say aloud.

Webkit might be a good idea. As for (2), (3), (4), (5), (6) (and possibly (7)) I would just drop support for all that. We could have a nice "pure" browser.

I would be happy dropping flash. Anything that relies on Maemo-Microb-mess (maps, messaging) could be left as-is. I guess writing a new GUI for messaging should not be *that* hard.

I cannot tell for sure, but the feature of dialing directly from a browser was part of a patent-mess. If I have time I might look into that.

Assuming whatever webkit build we are using still supports npapi, keeping support for adobe-flashplayer, tablet-browser-default-plugin and tablet-browser-mediaplayer-plugin. should be fairly simple.

Not entirely sure what libssoautologin is for so I can't comment if we need it or not.

microb-geolocation we definatly need as its what allows web pages to know your location (handy for things like transit company webpages that use your location as part of journey planning)

Keeping tutorial-home-applet, microb UI and rtcom-messaging-api working should just be a matter of writing code that drops in place of browser-eal/microb-eal/tablet-browser-daemon/etc (all the relavent pieces are FOSS so that shouldn't be a problem).

As for anything special microb engine has vs the matching mainline Mozilla/Gecko code, investigating what those changes are should still be done, there are almost certainly things there that we can easily support in webkit.

Me, my wish is to see a browser engine on maemo that can work with modern HTML5 websites microb can't currently render properly (www.trello.com is one microb fails on) but which integrates into the system just as much as current microb does.

Yeah... I have just done that and it feels GREAT!

Re jonwil's last post, I second keeping the UI. Unless updating the UI also means introducing tabs. That would be nice

Edit: Err... I see jonwil's last post has been edited. Never mind, I stand by my words. The current MicroB UI is fine but tabs would be a welcome improvement.

Well, iirc touching gtkmozembed would require such an enormous amount of work that me & Android_808 decided to leave it.

There was an idea to base on the Sailfish Browser code and simply redo the UI. We do need Qt5 for it. But we need Qt5 for anyhow decent webkit too.

We might too reuse some of the code from here https://github.com/marmistrz/microbe and qmlmozbrowser.

Another (non-exclusive) idea was to use the Qt Quick Controls. But due to the lack of working Qt Quick Controls examples no one took this idea. Or maybe simply no one had the time then.

As for Gtk3, you don't want to do it unless you update the system core. It's a real dependency hell.
<OT> What's the current state of the Jessie + Hildon on N900</OT>

There's a lot of information in this thread: http://talk.maemo.org/showthread.php...39#post1434839
Including information about webkit not being further developed (thus formerly banned from Jolla Harbor)

My two cents: I'd go for reusing the Jolla Browser code, as we might not have 'nuff manpower to build the browser from scratch. Go for embedlite, as it seems to be quite actively developed (even if for jolla phone). And go for Qt5, to be compatible with what is done for Jolla. And use Qt Quick Controls if they give the native look and feel (but we need examples for it to check the performance)