Active Topics
-
Extra softwares in Sailfish using CLI, repositories, etc (117)
to SailfishOS by nieldk - 5 hrs, 52 mins ago -
Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 1 day, 2 hrs ago - more...
|
2014-11-09
, 11:29
|
|
Posts: 3,328 |
Thanked: 4,476 times |
Joined on May 2011
@ Poland
|
#42
|
Or maybe we could simply update gtk to 2.18? Maybe it'd give us some performance benefit? I'm fetching the source at the moment and I'll see whether it'll build.
/edit: 2.24 needs glib 2.27.
/edit2: 2.20 needs glib 2.23, atk 1.29
Giving up then.
Last edited by marmistrz; 2014-11-09 at 11:44.
/edit: 2.24 needs glib 2.27.
/edit2: 2.20 needs glib 2.23, atk 1.29
Giving up then.
__________________
If you want to support my work, you can donate by PayPal or Flattr
Projects no longer actively developed: here
If you want to support my work, you can donate by PayPal or Flattr
Projects no longer actively developed: here
Last edited by marmistrz; 2014-11-09 at 11:44.
|
|
2014-11-09
, 14:07
|
|
Posts: 1,203 |
Thanked: 3,027 times |
Joined on Dec 2010
|
#43
|
forgot to say my failed build was with thumb target.
thumb might work for updated gtk:
libglib2 2.24.1-1maemo1+0cssu0+thumb0
atk 1.24.0-2maemo1
problem is iirc our gtk is patched. these would need porting as well.
if focus flag exists (and the function mentioned is the only 2.18+ feature) we could just find references to it in gecko and replace with equivalent code.
Edit: mozilla prerequisites page is a bit out of date, lists gtk2.10 but configure.in requires 2.18.
Last edited by Android_808; 2014-11-09 at 18:17.
thumb might work for updated gtk:
libglib2 2.24.1-1maemo1+0cssu0+thumb0
atk 1.24.0-2maemo1
problem is iirc our gtk is patched. these would need porting as well.
if focus flag exists (and the function mentioned is the only 2.18+ feature) we could just find references to it in gecko and replace with equivalent code.
Edit: mozilla prerequisites page is a bit out of date, lists gtk2.10 but configure.in requires 2.18.
Last edited by Android_808; 2014-11-09 at 18:17.
|
|
2014-11-09
, 19:11
|
|
Posts: 1,203 |
Thanked: 3,027 times |
Joined on Dec 2010
|
#44
|
I edited configure.in to require 2.10 instead as I don't quite see the point of that header file otherwise. Unless I'm having a stupid moment, that segment in the ifdef above says if you haven't got 2.18, heres what you you need.
Configure passes after this. I've tweaked my config slightly to be more like microb, but with or without tweak I'm hitting a new error.
A quick look in /usr/include/linux/syscall.h and sys/syscall.h.. and bits/syscall.h indeed shows its missing.
Configure passes after this. I've tweaked my config slightly to be more like microb, but with or without tweak I'm hitting a new error.
Code:
In file included from /home/user/mozembed/gecko-dev/objdir-armel/xpcom/threads/Unified_cpp_xpcom_threads0.cpp:29:0: /home/user/mozembed/gecko-dev/xpcom/threads/ThreadStackHelper.cpp: In member function 'void mozilla::ThreadStackHelper::GetStack(mozilla::ThreadStackHelper::Stack&)': /home/user/mozembed/gecko-dev/xpcom/threads/ThreadStackHelper.cpp:239:17: error: 'SYS_rt_tgsigqueueinfo' was not declared in this scope
|
|
2014-11-09
, 19:23
|
|
Posts: 804 |
Thanked: 1,598 times |
Joined on Feb 2010
@ Gdynia, Poland
|
#45
|
Originally Posted by Android_808
As far as I understand the patch from http://linux-kernel.2935.n7.nabble.c...-td471174.html ... is it possible just to simply declare it like this somewhere (even in different header file) to fix this...?
A quick look in /usr/include/linux/syscall.h and sys/syscall.h.. and bits/syscall.h indeed shows its missing.
|
|
2014-11-09
, 19:41
|
|
Posts: 3,328 |
Thanked: 4,476 times |
Joined on May 2011
@ Poland
|
#46
|
Maybe it's included into kernel power?
|
|
2014-11-09
, 19:43
|
|
Posts: 4 |
Thanked: 2 times |
Joined on Nov 2014
|
#47
|
It not exactly replacing the engine but I think a webkit based browser could be ported to maemo.
looking there: https://git.yoctoproject.org/cgit/cg...ebkit/tree/src
It isn't that much code. Obviously "web2-main.c" depends on libowl and must be rewritten for maemo widgets....
Might be worth a look.
looking there: https://git.yoctoproject.org/cgit/cg...ebkit/tree/src
It isn't that much code. Obviously "web2-main.c" depends on libowl and must be rewritten for maemo widgets....
Might be worth a look.
|
|
2014-11-09
, 22:05
|
|
Posts: 567 |
Thanked: 2,965 times |
Joined on Oct 2009
|
#48
|
Ok so there are 4 things we need to deal with in order to achieve the goal of a newer Gecko on Fremantle.
First is dealing with things that newer Gecko needs that Fremantle doesn't provide (i.e. kernel changes, GTK stuff etc) and figuring out how to work around those (or how to bring them into Fremantle)
Second is dealing with Maemo/Fremantle specific functionality and changes (e.g. the stuff that deals with network connectivity via various Maemo libraries or e.g. various dialogs and bits present in microb-engine) and identifying all the things that were removed but need to be brought back.
Third is dealing with ABI incompatibilities between old plugins and newer Gecko (with the exception of Flash and maybe Maps, we can probably clone all the plugins if we need to)
And last is dealing with the external interface used by other things (browser ui, maps, messaging etc) to talk to the browser and making sure we are ABI compatible with that interface.
First is dealing with things that newer Gecko needs that Fremantle doesn't provide (i.e. kernel changes, GTK stuff etc) and figuring out how to work around those (or how to bring them into Fremantle)
Second is dealing with Maemo/Fremantle specific functionality and changes (e.g. the stuff that deals with network connectivity via various Maemo libraries or e.g. various dialogs and bits present in microb-engine) and identifying all the things that were removed but need to be brought back.
Third is dealing with ABI incompatibilities between old plugins and newer Gecko (with the exception of Flash and maybe Maps, we can probably clone all the plugins if we need to)
And last is dealing with the external interface used by other things (browser ui, maps, messaging etc) to talk to the browser and making sure we are ABI compatible with that interface.
|
|
2014-11-10
, 02:10
|
|
Posts: 1,994 |
Thanked: 3,342 times |
Joined on Jun 2010
@ N900: Battery low. N950: torx 4 re-used once and fine; SIM port torn apart
|
#49
|
Quick message about patches https://vcs.maemo.org/svn/browser/mo...ebian/patches/
Comparing maemo vs mozilla: https://vcs.maemo.org/svn/browser/mo...microb-engine/ http://dxr.mozilla.org/mozilla-central/source/
About localization patches:
exception-en-US.diff should still be done, but the patch may need to be modified because of different line numbers (Mozilla changed their code slightly, but it does not affect -+diff, only the line numbers and pretext of the edit).
bug137606.diff is no longer needed, since Mozilla-trunk does not mention File menu anymore.
bug157237.diff should still be done. Not sure whether line numbers are still the same or changed. bug87973.firefox.hardcoded.diff should still be done. Bug 336029 for Mozilla, by the way.
About crashes:
854ab30d101e.diff was already fixed by Mozilla, so no longer needed.
GetChannelIsUnsafe_bug117540.diff should still be done.
attachment.cgi%3fid=46259.diff was already fixed by Mozilla, so no longer needed.
Comparing maemo vs mozilla: https://vcs.maemo.org/svn/browser/mo...microb-engine/ http://dxr.mozilla.org/mozilla-central/source/
About localization patches:
exception-en-US.diff should still be done, but the patch may need to be modified because of different line numbers (Mozilla changed their code slightly, but it does not affect -+diff, only the line numbers and pretext of the edit).
bug137606.diff is no longer needed, since Mozilla-trunk does not mention File menu anymore.
bug157237.diff should still be done. Not sure whether line numbers are still the same or changed. bug87973.firefox.hardcoded.diff should still be done. Bug 336029 for Mozilla, by the way.
About crashes:
854ab30d101e.diff was already fixed by Mozilla, so no longer needed.
GetChannelIsUnsafe_bug117540.diff should still be done.
attachment.cgi%3fid=46259.diff was already fixed by Mozilla, so no longer needed.
| The Following 5 Users Say Thank You to Wikiwide For This Useful Post: | ||
|
|
2014-11-10
, 11:14
|
|
Posts: 567 |
Thanked: 2,965 times |
Joined on Oct 2009
|
#50
|
Things we need to identify in order to proceed with this work:
1.Any and all bugs in bugzilla.mozilla.org that refer to removed/changed functionality (a few have been linked already but there are no doubt more that haven't been found yet)
2.Any changes to public header files (the ones in microb-engine-dev on Maemo) that break the ABI in ways that affect us (figuring out if a change affects us will rely on reverse engineering the closed plugins and we can figure out what has changed by looking at the commit history for the header files in question). If the Maemo version of a header file says an interface is "frozen" I think we can assume its not going to be incompatible in the latest Gecko (after all, thats the point of "frozen" status for an interface)
and 3.Which of the local patches actually get used when compiling the Fremantle binaries using the same configs Nokia used and of those patches, which ones matter for us (we especially need to see if any such patches change the public header files)
For item #1 we need someone who knows their way around bugzilla.mozilla.org and can find all those bugs.
For item #2 we need someone who knows how to program npapi and Gecko APIs.
And for item #3, we need someone who knows their way around the Gecko codebase and knows how to read/understand patches.
1.Any and all bugs in bugzilla.mozilla.org that refer to removed/changed functionality (a few have been linked already but there are no doubt more that haven't been found yet)
2.Any changes to public header files (the ones in microb-engine-dev on Maemo) that break the ABI in ways that affect us (figuring out if a change affects us will rely on reverse engineering the closed plugins and we can figure out what has changed by looking at the commit history for the header files in question). If the Maemo version of a header file says an interface is "frozen" I think we can assume its not going to be incompatible in the latest Gecko (after all, thats the point of "frozen" status for an interface)
and 3.Which of the local patches actually get used when compiling the Fremantle binaries using the same configs Nokia used and of those patches, which ones matter for us (we especially need to see if any such patches change the public header files)
For item #1 we need someone who knows their way around bugzilla.mozilla.org and can find all those bugs.
For item #2 we need someone who knows how to program npapi and Gecko APIs.
And for item #3, we need someone who knows their way around the Gecko codebase and knows how to read/understand patches.
http://lxr.mozilla.org/mozilla-relea...gtkwidget.h#88
EDIT: On a quick browse on that page I only found it used once anyways:
http://lxr.mozilla.org/mozilla-relea...ontainer.c#167
Might be worth considering if the function should be implemented as a separate header/file or simply that line re-written...
Last edited by pablocrossa; 2014-11-09 at 11:26.