maemo.org - Talk - idea: Update browser engine on N900

maemo.org - Talk (https://talk.maemo.org/index.php)

- Maemo 5 / Fremantle (https://talk.maemo.org/forumdisplay.php?f=40)

- - idea: Update browser engine on N900 (https://talk.maemo.org/showthread.php?t=94107)

idea: Update browser engine on N900

Now I know there are alternative browsers for the N900 (Fennec for one) but those tend to either suck or be based on fairly old versions of their rendering engines.

My idea is to:
1.Find the version of mainline Gecko that matches with the Gecko version being shipped on the N900 (in the microb-engine package)
2.Having found this, identify any patches on top of mainline in the N900 Gecko version (whether they be patches that ended up in mainline Gecko later or whether they were Nokia-specific or otherwise dropped
3.Figure out which of the patches from #2 are actually necessary and forward port those to a more modern Gecko version
4.Make the other changes to the modern Gecko required to get it to function as a replacement for microb-engine and make it work as a browser
5.Reverse engineer the pieces that talk to the browser (flash player, maps, a couple others) and see if they are tied to the browser's APIs in ways that will break with a newer Gecko
and 6.Using reverse engieering and whatever else, find a way to make the stuff in #5 work.

Re: idea: Update browser engine on N900

It would be really great to get micro-b updated!

But you should also ake a look at the efforts marxian did with his qml-browser.
Maybe it helps in any way or even is the way to go?

Re: idea: Update browser engine on N900

Well this every n900 user wanted for ages now ;) btw isint the ui closed and more of a problem ?

Re: idea: Update browser engine on N900

Quote:

Originally Posted by peterleinchen (Post 1445581)

It would be really great to get micro-b updated!
But you should also ake a look at the efforts marxian did with his qml-browser.
Maybe it helps in any way or even is the way to go?

yes qml browser is nice but it nowhere like microb i mean microb feels like a part of the os the user experince and i doubt that something like qml browser could ever be a default but for sure it could be the best third party browser available ;)

Re: idea: Update browser engine on N900

Quote:

Originally Posted by nokiabot (Post 1445588)

I don't know, QML-Browser's UI looks very much like MicroB. It looks and feels like tbe hottest candidate for a true replacement. If only it did not crash on start on Thumb ;)

Re: idea: Update browser engine on N900

@Pichlo ri8 but then isint it qt stuff i mean default apps are based on some other kingpin stuff na ;)
btw they are just my opinion and i want a better browser be it microb or whatever better stuff but microb is something the majority wants :)

Re: idea: Update browser engine on N900

jonwil: as you may know I was pretty active on #embedlite, there are a couple of my patches upstreamed to gecko etc. I was hoping that at some point I will be able to wrap upstream gecko Gtk embedlite implementation in what microb needs.

It turned out all the effort was because of jollaphone, they even dropped q4 support some time ago.

I assess your idea to simply forward port the patches in maemo's gecko to upstream as not feasible - not only the code has changed dramatically, but there is a crucial piece of it which is missing for maybe 3 or more years - GtkMozEmbed. This is what microb eal uses to embed gecko.

On the other hand we don't really need to replace microb, as it is just an UI. What needs to be done is - we get a recent engine, port it to maemo and implement this http://browser.garage.maemo.org/docs/eal/

Re: idea: Update browser engine on N900

As freemangordon stated, gtkmozembed would have to be updated or reimplemented. Below is the reply to an email to the maintainer of the embedlite github repo from 13 feb 2014. This was the reason I stopped work on the qt4 replacement.

Quote:

No, Qt4 is not an option anymore. Qt5 does support QGraphicsView/Widget option still but that is only on qtmozembed side. It's also going to go away soon.

In this branch
https://github.com/tmeshkova/gecko-d...ackendrefactor
We are going to drop Qt4 support and dependency on Qt5Widgets and switch everything to stock Qt5. No time and strength to support both.

As an alternative it should be possible to just build Gtk embedding wrapper around EmbedLite API for Neo900. Similar to what https://github.com/tmeshkova/qtmozembed does for Qt.
All patches for supporting Gtk backend wrapper are welcome.

Re: idea: Update browser engine on N900

Quote:

Originally Posted by Android_808 (Post 1445644)

...As an alternative it should be possible to just build Gtk embedding wrapper around EmbedLite API for Neo900. Similar to what https://github.com/tmeshkova/qtmozembed does for Qt.

Which is not really possible if we want GLES accelerated graphics, as Gtk does not provide/support GLES context. There are some efforts to support OpenGL in Gtk(https://git.gnome.org/browse/gtkglext/), I tried that on n900, but the performance was abysmal

Re: idea: Update browser engine on N900

Year ago I was told that mainline gecko should still have all interfaces except legacy location/map which is used by some nokia/maemo closed plugin. Anyway some of closed microb parts are not closed, just need to dig on garage...

Re: idea: Update browser engine on N900

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?

Re: idea: Update browser engine on N900

Quote:

Originally Posted by pali (Post 1445663)

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

Re: idea: Update browser engine on N900

Quote:

Originally Posted by jonwil (Post 1445666)

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

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 :)

Re: idea: Update browser engine on N900

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.

Re: idea: Update browser engine on N900

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.

Re: idea: Update browser engine on N900

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.

Re: idea: Update browser engine on N900

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.

Re: idea: Update browser engine on N900

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.

Re: idea: Update browser engine on N900

Quote:

Originally Posted by reinob (Post 1445719)

I would be happy dropping flash.

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

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.

Re: idea: Update browser engine on N900

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)

Re: idea: Update browser engine on N900

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)

Re: idea: Update browser engine on N900

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.

Re: idea: Update browser engine on N900

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?

Re: idea: Update browser engine on N900

Quote:

Originally Posted by jonwil (Post 1446202)

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.

Re: idea: Update browser engine on N900

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)

Re: idea: Update browser engine on N900

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

Re: idea: Update browser engine on N900

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.

Re: idea: Update browser engine on N900

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.

Re: idea: Update browser engine on N900

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.

Re: idea: Update browser engine on N900

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.

Re: idea: Update browser engine on N900

Quote:

Originally Posted by marmistrz (Post 1446261)

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.

Maybe because it was not used anymore?;) I think Crapdroid has different "binding" with it, maybe only Fremantle and Harmattan used it and while they haven't been updated for ages, they dropped it? This are just speculations :P

Quote:

Originally Posted by marmistrz (Post 1446261)

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

If the work will be done in a proper way once, the annual maintenance wouldn't be that hard.

Quote:

Originally Posted by marmistrz (Post 1446261)

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 vote a strong NO. Don't get me wrong I'm a big fan of Qt in general, but as long as we're still taking about GTK+Qt4 operaing system, I don't want to have another set of libraries loaded in RAM to open simple web page... I prefer to have more RAM and power for the webpage itself and GTK is sitting in the ram anyway on startup, so why load another stuff just to check the news or other silly stuff online? I would vote for consistency here (system components use GTK, so let's keep it up like it unless the lead of the team decides to change it altogether).

Just my useless 2 cents, I'm not even too active here lately, so if the active devs team has different oppinion, you don't even have to argue with me ;) (in other words = if the person who will do it will do it in Qt5, but it will still work, I will be happy that it is done at all, after all it's their decision as they are the ones that put their precious time into it)

Re: idea: Update browser engine on N900

I say we should stick with GTK too.

Re: idea: Update browser engine on N900

And what if we're to rewrite the UI? We might not be able to use the present microb ui in case of a big incompatibility. Is there anyone who knows gtk there?

Re: idea: Update browser engine on N900

Assuming we remain ABI compatible with the current tablet-browser-daemon/browser-neteal dbus interface, we should have no problems keeping the current GTK UI working.

Re: idea: Update browser engine on N900

managed a quick scan through the maemo removal patch.

a lot of the changes refer to qt, both maemo and harmattan. theres a patch that is linked to maemo bugtracker for flash player bug. some are "if using gtk or maemo" checks reverted to gtk only, which we are still using.

biggest things i can see is a renderer and libconic. the content of the first refers to being able to write directly to image memory so would seem pretty important to me. second, internet connectivity.

the only issue i see with using stock ui at the moment are the dialogs i seem to remember that are in microb-engine. last time i checked (firefox8/9 time), the patches needed adapting to fit but it was still reasonably clear where to put them. as a ui element, i'd rather just have them as part of the actual ui and listen for signal to use them. that way it would make maintenance easier. it also might solve the random issue with dialogs not responding.

even libconic related stuff could technically be seperated out.

Re: idea: Update browser engine on N900

Seems like one would need to dig a lot on b.m.o to find all the "remove xyz" and "change xyz" and "do xyz" bugs/patches (including those that relate to gtkmozembed) that would need to be forward ported or otherwise handled.

But, assuming we can track all those down and we can triage all the "local" patches in the Maemo source tree (the ones in microb-engine_20100401-1.9.2-5.2+0m5.diff.gz that get applied as part of the build process through quilt or whatever it is) I think we might actually be able to pull this "update gecko to something recent" effort off :)

Re: idea: Update browser engine on N900

if i get a chance later i'll try to pull latest embedlite and build with gtk2 to see how far we get.

edit: pulling repo now.

Re: idea: Update browser engine on N900

Fails during early configure stage due to our gtk version. Needs 2.18+, we have 2.14.7.

debian/rules (nearly identical to those for microbe's embedlite build, just changed bold text):

Code:

#!/usr/bin/make -f

# -*- makefile -*-



# Uncomment this to turn on verbose mode.

#export DH_VERBOSE=1



ifneq (,$(findstring Maemo 5,$(shell cat /etc/issue)))

        export PYTHON=/usr/bin/python2.7

endif



package=xulrunner

prefix=usr



# These are used for cross-compiling and for saving the configure script

# from having to guess our platform (since we know it already)

DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)

DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)



CFLAGS = -Wall -g

configopts =



ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))

        CFLAGS += -O0

else

        CFLAGS += -O2

endif



ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))

        INSTALL_PROGRAM += -s

endif



NJOBS:=-j4

ifneq (,$(findstring parallel,$(DEB_BUILD_OPTIONS)))

        PARALLEL_JOBS := $(shell echo $(DEB_BUILD_OPTIONS) | \

        sed -e 's/.*parallel=\([0-9]\+\).*/\1/')

ifeq ($(DEB_BUILD_OPTIONS),$(PARALLEL_JOBS))

        PARALLEL_JOBS := $(shell if [ -f /proc/cpuinfo ]; \

        then echo `cat /proc/cpuinfo | grep '^processor.*:' | wc -l`; \

        else echo 1; fi)

endif

NJOBS:=-j$(PARALLEL_JOBS)

endif



ifneq (,$(findstring CodeSourcery,$(shell gcc --version)))

GCCENV:=.cs

endif



MAKEFLAGS += $(NJOBS)

DEST_OBJ_DIR=objdir-$(DEB_HOST_ARCH)

ifneq (,$(findstring cs2009q3-hard-67-sb16,$(shell gcc --version)))

MOZCONFIG_FILE=mozconfig.qtN9-qt

else

ifneq (,$(findstring Maemo 5,$(shell cat /etc/issue)))

MOZCONFIG_FILE=mozconfig.N900-gtk

else

MOZCONFIG_FILE=mozconfig.qtdesktop

endif

endif

GREVERSION=$(shell cat $(CURDIR)/config/milestone.txt | sed '/^\#/d' | sed '/^$$/d')



configure: configure-$(DEB_HOST_ARCH)-stamp

configure-$(DEB_HOST_ARCH)-stamp:

ifneq (,$(findstring Maemo 5,$(shell cat /etc/issue)))

        QUILT_PATCHES=debian/patches/fremantle quilt push -a

endif

        dh_testdir

        cp $(CURDIR)/embedding/embedlite/config/$(MOZCONFIG_FILE) $(CURDIR)/$(MOZCONFIG_FILE)

ifneq (,$(findstring cs2009q3-hard-67-sb16,$(shell gcc --version)))

endif

ifneq (,$(findstring $(DEB_HOST_ARCH),arm armel))

        echo "ac_add_options --with-gl-provider=EGL" >> $(CURDIR)/$(MOZCONFIG_FILE)

        echo "ac_add_options --disable-webrtc" >> $(CURDIR)/$(MOZCONFIG_FILE)

        echo "ac_add_options --with-arm-kuser" >> $(CURDIR)/$(MOZCONFIG_FILE)

ifneq (,$(findstring thumb,$(DEB_BUILD_OPTIONS)))

        echo "ac_add_options --with-thumb=yes" >> $(CURDIR)/$(MOZCONFIG_FILE)

else

        echo "ac_add_options --with-thumb=toolchain-default" >> $(CURDIR)/$(MOZCONFIG_FILE)

endif

        echo "ac_add_options --with-float-abi=toolchain-default" >> $(CURDIR)/$(MOZCONFIG_FILE)

endif

        echo "ac_add_options --prefix=/$(prefix)" >> $(CURDIR)/$(MOZCONFIG_FILE)

        echo "ac_add_options --disable-tests" >> $(CURDIR)/$(MOZCONFIG_FILE)

        echo "ac_add_options --disable-valgrind" >> $(CURDIR)/$(MOZCONFIG_FILE)

        echo "ac_add_options --disable-profiling" >> $(CURDIR)/$(MOZCONFIG_FILE)

        echo "mk_add_options MOZ_OBJDIR=\"$(DEST_OBJ_DIR)\"" >> $(CURDIR)/$(MOZCONFIG_FILE)

        echo "mk_add_options MOZ_MAKE_FLAGS=\"$(NJOBS)\"" >> $(CURDIR)/$(MOZCONFIG_FILE)

        MOZCONFIG=$(CURDIR)/$(MOZCONFIG_FILE) $(MAKE) -f client.mk configure



        touch configure-$(DEB_HOST_ARCH)-stamp



build: build-$(DEB_HOST_ARCH)-stamp

build-$(DEB_HOST_ARCH)-stamp: configure-$(DEB_HOST_ARCH)-stamp

        dh_testdir

        MOZCONFIG=$(CURDIR)/$(MOZCONFIG_FILE) $(MAKE) -f client.mk build_all



        touch build-$(DEB_HOST_ARCH)-stamp



clean:

        dh_testdir

        dh_testroot

        rm -f build-$(DEB_HOST_ARCH)-stamp

        rm -f configure-$(DEB_HOST_ARCH)-stamp

#        $(MAKE) distclean

        rm -rf $(DEST_OBJ_DIR)

ifneq (,$(findstring Maemo 5,$(shell cat /etc/issue)))

        QUILT_PATCHES=debian/patches/fremantle quilt pop -a || true

endif

        dh_clean



install: build

        dh_testdir

        dh_testroot

        dh_clean -k

        dh_installdirs -s



        # Add here commands to install the package into debian/tmp

        cat $(CURDIR)/debian/xulrunner.install.in | sed 's/%GRE_VERSION%/$(GREVERSION)/g' > $(CURDIR)/debian/xulrunner.install

        cat $(CURDIR)/debian/xulrunner-dev.install.in | sed 's/%GRE_VERSION%/$(GREVERSION)/g' > $(CURDIR)/debian/xulrunner-dev.install

#       make -C $(CURDIR)/$(DEST_OBJ_DIR) install/package does not work on some environments due to missing recent python, let's do it manually

        $(MAKE) -C $(CURDIR)/$(DEST_OBJ_DIR)/xulrunner/installer libxul.pc libxul-embedding.pc mozilla-nspr.pc mozilla-js.pc mozilla-nss.pc mozilla-plugin.pc

        install -d $(CURDIR)/debian/tmp/$(prefix)/bin

        install -d $(CURDIR)/debian/tmp/$(prefix)/include

        install -d $(CURDIR)/debian/tmp/$(prefix)/lib/pkgconfig

        install -d $(CURDIR)/debian/tmp/$(prefix)/share/idl

        install -d $(CURDIR)/debian/tmp/$(prefix)/lib/xulrunner-devel-$(GREVERSION)

        install -m 0664 $(CURDIR)/$(DEST_OBJ_DIR)/dist/bin/xulrunner  $(CURDIR)/debian/tmp/$(prefix)/bin

        cp -rfL $(CURDIR)/$(DEST_OBJ_DIR)/xulrunner/installer/*.pc $(CURDIR)/debian/tmp/$(prefix)/lib/pkgconfig

        cp -rfL $(CURDIR)/$(DEST_OBJ_DIR)/dist/bin $(CURDIR)/debian/tmp/$(prefix)/lib/xulrunner-$(GREVERSION)

        cp -rfL $(CURDIR)/$(DEST_OBJ_DIR)/dist/include $(CURDIR)/debian/tmp/$(prefix)/include/xulrunner-$(GREVERSION)

        cp -rfL $(CURDIR)/$(DEST_OBJ_DIR)/dist/idl $(CURDIR)/debian/tmp/$(prefix)/share/idl/xulrunner-$(GREVERSION)

        ln -s /$(prefix)/include/xulrunner-$(GREVERSION) $(CURDIR)/debian/tmp/$(prefix)/lib/xulrunner-devel-$(GREVERSION)/include

        ln -s /$(prefix)/share/idl/xulrunner-$(GREVERSION) $(CURDIR)/debian/tmp/$(prefix)/lib/xulrunner-devel-$(GREVERSION)/idl

        ln -s /$(prefix)/lib/xulrunner-$(GREVERSION) $(CURDIR)/debian/tmp/$(prefix)/lib/xulrunner-devel-$(GREVERSION)/bin

        cp -rfL $(CURDIR)/$(DEST_OBJ_DIR)/dist/sdk $(CURDIR)/debian/tmp/$(prefix)/lib/xulrunner-devel-$(GREVERSION)/sdk

        rm -f $(CURDIR)/debian/tmp/$(prefix)/lib/xulrunner-devel-$(GREVERSION)/sdk/lib/libxul.so

        ln -s sdk/lib $(CURDIR)/debian/tmp/$(prefix)/lib/xulrunner-devel-$(GREVERSION)/lib

        ln -s /$(prefix)/lib/xulrunner-$(GREVERSION)/libxul.so $(CURDIR)/debian/tmp/$(prefix)/lib/xulrunner-devel-$(GREVERSION)/sdk/lib/libxul.so

        dh_install --sourcedir=debian/tmp



# Build architecture-independent files here.

binary-indep: build install

# We have nothing to do by default.



# Build architecture-dependent files here.

binary-arch: build install

        dh_testdir

        dh_testroot

        dh_link

        dh_compress

        dh_fixperms

        dh_strip --dbg-package=$(package)-dbg

        dh_makeshlibs

        dh_installdeb

        dh_shlibdeps

        dh_gencontrol

ifneq (,$(findstring Maemo 5,$(shell cat /etc/issue)))

        maemo-optify

endif

        dh_md5sums

        dh_builddeb



binary: binary-indep binary-arch

.PHONY: build clean binary-indep binary-arch binary install

gecko-dev/embedding/embedlite/config/mozconfig.N900-gtk:

Code:

export ac_cv_have_usable_wchar_option_v2="no"

ac_add_options --enable-application=xulrunner

#ac_add_options --enable-update-channel=nightly

#ac_add_options --enable-update-packaging

ac_add_options --enable-logging

#ac_add_options --enable-default-toolkit=cairo-qt

ac_add_options --enable-mobile-optimize

ac_add_options --enable-skia



export MOZ_DEBUG_SYMBOLS=1

ac_add_options --enable-debug-symbols="-ggdb"

export MOZILLA_OFFICIAL=1

mk_add_options PROFILE_GEN_SCRIPT=@TOPSRCDIR@/build/profile_pageloader.pl



export CXXFLAGS="-mthumb -mtune=cortex-a8 -mcpu=cortex-a8 -fpermissive -DUSE_ANDROID_OMTC_HACKS=1"

export CFLAGS="-mthumb -mtune=cortex-a8 -mcpu=cortex-a8"



ac_add_options --enable-optimize="-O2 -Wno-psabi"

ac_add_options --disable-jemalloc

ac_add_options --enable-gstreamer



mk_add_options MOZ_MAKE_FLAGS="-j4"

mk_add_options MOZ_OBJDIR="@TOPSRCDIR@/obj-build-n900-gtk"

ac_add_options --with-fpu=neon



ac_add_options --with-system-zlib

ac_add_options --with-system-bz2

ac_add_options --enable-system-pixman



ac_add_options --disable-elf-hack



ac_add_options --enable-libjpeg-turbo



ac_add_options --enable-profile-guided-optimization

#ac_add_options --enable-valgrind

#ac_add_options --enable-profiling



ac_add_options --disable-accessibility

ac_add_options --disable-crashreporter

ac_add_options --disable-updater

ac_add_options --disable-jsd

ac_add_options --disable-printing

ac_add_options --disable-tests

ac_add_options --disable-dbus

ac_add_options --disable-necko-wifi

ac_add_options --disable-updater

ac_add_options --disable-gamepad

ac_add_options --disable-pulseaudio



#ac_add_options --enable-debug



#fails to compile with this enabled, might raise a bug

#ac_add_options --with-maemo-version=5

Updated gst-fix-missing-functions.patch:

Code:

Index: mozilla-central/dom/media/gstreamer/GStreamerFormatHelper.cpp

===================================================================

--- mozilla-central.orig/dom/media/gstreamer/GStreamerFormatHelper.cpp        2013-11-19 02:04:40.000000000 +0200

+++ mozilla-central/dom/media/gstreamer/GStreamerFormatHelper.cpp        2013-11-19 02:04:54.000000000 +0200

@@ -292,25 +292,10 @@

 GList* GStreamerFormatHelper::GetFactories() {

   NS_ASSERTION(sLoadOK, "GStreamer library not linked");

 

-#if GST_VERSION_MAJOR >= 1

-  uint32_t cookie = gst_registry_get_feature_list_cookie(gst_registry_get());

-#else

-  uint32_t cookie = gst_default_registry_get_feature_list_cookie();

-#endif

-  if (cookie != mCookie) {

-    g_list_free(mFactories);

-#if GST_VERSION_MAJOR >= 1

-    mFactories =

-      gst_registry_feature_filter(gst_registry_get(),

-                                  (GstPluginFeatureFilter)FactoryFilter,

-                                  false, nullptr);

-#else

-    mFactories =

-      gst_default_registry_feature_filter((GstPluginFeatureFilter)FactoryFilter,

-                                          false, nullptr);

-#endif

-    mCookie = cookie;

-  }

+  g_list_free(mFactories);

+  mFactories =

+    gst_default_registry_feature_filter((GstPluginFeatureFilter)FactoryFilter,

+                                         false, nullptr);

 

   return mFactories;

 }



 

Index: mozilla-central/dom/media/gstreamer/GStreamerFunctionList.h

===================================================================

--- mozilla-central.orig/dom/media/gstreamer/GStreamerFunctionList.h        2013-11-19 02:04:29.000000000 +0200

+++ mozilla-central/dom/media/gstreamer/GStreamerFunctionList.h        2013-11-19 02:04:54.000000000 +0200

@@ -50,6 +50,7 @@

 GST_FUNC(LIBGSTREAMER, gst_init_check)

 GST_FUNC(LIBGSTREAMER, gst_iterator_next)

 GST_FUNC(LIBGSTREAMER, gst_message_parse_error)

+GST_FUNC(LIBGSTREAMER, gst_message_get_type)

 GST_FUNC(LIBGSTREAMER, gst_message_type_get_name)

 GST_FUNC(LIBGSTREAMER, gst_mini_object_ref)

 GST_FUNC(LIBGSTREAMER, gst_mini_object_unref)

@@ -63,7 +64,6 @@

 GST_FUNC(LIBGSTREAMER, gst_pipeline_get_type)

 GST_FUNC(LIBGSTREAMER, gst_plugin_feature_get_rank)

 GST_FUNC(LIBGSTREAMER, gst_registry_feature_filter)

-GST_FUNC(LIBGSTREAMER, gst_registry_get_feature_list_cookie)

 GST_FUNC(LIBGSTREAMER, gst_segment_init)

 GST_FUNC(LIBGSTREAMER, gst_segment_to_stream_time)

 GST_FUNC(LIBGSTREAMER, gst_static_caps_get)

As for dependency/ debian/control I only have what was installed last time I tried it. Did not edit current control file. The one from last time I tried was:

Code:

Source: xulrunner

Section: libs

Priority: extra

Maintainer: unknown <tmeshkova@github.com>

Build-Depends: debhelper (>= 5),

 autoconf2.13,

 python,

 unzip,

 zip,

 libpango1.0-dev,

 libdbus-1-dev,

 libdbus-glib-1-dev,

 libasound2-dev,

 libgstreamer0.10-dev,

 libgstreamer-plugins-base0.10-dev,

 libx11-dev,

 libxt-dev,

 quilt,

 python2.7,

 libidl-dev,

 libgtk2.0-dev,

 libosso-gnomevfs2-dev | libgnomevfs2-dev,

 sharutils,

 libcairo2-dev,

 liblocation-dev,

 libhildonmime-dev,

 libosso-dev,

 libxdamage-dev,

 libxcomposite-dev,

 libgl1-mesa-dev | opengles-sgx-img-common-dev | libgl-dev,

 libconic0-dev,

 libhildonfm2-dev,

 libglib2.0-dev

Homepage: https://wiki.mozilla.org/Embedding/IPCLiteAPI



Package: xulrunner

Architecture: any

Depends: ${shlibs:Depends}, ${misc:Depends}

Description: <insert up to 60 chars description>

 <insert long description, indented with spaces>



Package: xulrunner-dev

Architecture: any

Depends: ${shlibs:Depends}, ${misc:Depends}, xulrunner (= ${Source-Version})

Description: <insert up to 60 chars description>

 <insert long description, indented with spaces>



Package: xulrunner-dbg

Architecture: any

Depends: ${shlibs:Depends}, ${misc:Depends}, xulrunner (= ${Source-Version})

Description: <insert up to 60 chars description>

 <insert long description, indented with spaces>

Re: idea: Update browser engine on N900

Lets start building a list of all the bugzilla.mozilla.org bugs that are relavent. This is what I have found so far, anyone else with more knowledge of Gecko (or bugzilla) than me got any others to add to the list?
https://bugzilla.mozilla.org/show_bug.cgi?id=648156
https://bugzilla.mozilla.org/show_bug.cgi?id=906072
https://bugzilla.mozilla.org/show_bug.cgi?id=1080529
https://bugzilla.mozilla.org/show_bug.cgi?id=653201

Lets focus on the goal of getting a modern Gecko to work on Maemo and then on getting it to work as a replacement for the system browser engine (including talking to all the users of and plugins for the browser engine on a stock Fremantle system)

As for the configuration/packaging stuff, we should reference the actual files used for Fremantle as a guide to what settings we want for it.

Re: idea: Update browser engine on N900