Closed Bug 422221 Opened 13 years ago Closed 12 years ago
Port Mozilla to Gtk-Direct
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4 Currently Mozilla trunk supports only X11 backend on Linux platform. Though there was previous work on DirectFB backend support for Mozilla, the patch was based on Firefox1.5 and never made into Mozilla trunk. More over gfx architecture has been changed quite a bit since then. This bug is a place holder for all DirectFB porting related bugs that we are going to file over time. A wiki page (http://wiki.mozilla.org/Mobile/DFBPorting) has been created that explains the porting strategy. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Hardware: All → PC
Version: unspecified → Trunk
This patch will be cleaned up and split into multiple bugs once we have basic thing running. I'm attaching now so that Blizzard and others can reproduce the display issues with the DFB build.
Product: Firefox → Core
QA Contact: general → general
Summary: Port Mozilla over DirectFB → Port Mozilla to Gtk-DirectFB
please search before filing bugs.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 357946
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Duplicate of this bug: 357946
Firefox over DirectFB is very stable now. We still have this bug opened for all our future enhancements/improvements (plugins, SVG, performance etc).
Mohan - Do you have a plan to land this code in our tree so we can get it into our trunk and make it available as an option?
We have a hg repo setup for the dfb work. Stuart will merge it to trunk but I don't know when.
The contents of the page http://wiki.mozilla.org/Mobile/DFBPorting are very, very close to actually being a script for doing what is described on the page. If a script is made from this page, can it be checked in somewhere so that changes to it can be tracked? I can propose a patch of such a script. I have turned this page into a script about a half dozen times. it is just inconvenient to track both a web page that get changed by many people and a script that is only edited by me. But I am probably not the best one to propose a script. For one thing, mine would work best on Mac OS X. It just seems that narrative text and explanations can go into a web page, and "download x-1.22.4 instead of X-1.22.2" can go into a script, yes?
If you mean to automate downloading and installing the packages, have a look at this : http://wiki.mozilla.org/Mobile/DFBPorting#Using_script
Well, I can try it. I tried it a while back and it was not near working. But that was then. But also, I look at the page and I see shell commands. And I need a python script why? And I see notes from other people doing this stuff on other versions of Linux (not Fedora Core 8) and all of them say they did not use the script. But I will try it. Longer term, are there any plans to support this configuration in the traditional Mozilla-ish way, ie with "hg checkout ; ./configure --directfb-only ; make" ?
From http://wiki.mozilla.org/Mobile/DFBPorting#Using_script Any suggestions? $ wget http://wiki.mozilla.org/images/8/8d/Install_gtk_060508.zip --14:33:29-- http://wiki.mozilla.org/images/8/8d/Install_gtk_060508.zip => `Install_gtk_060508.zip' Resolving wiki.mozilla.org... 184.108.40.206 Connecting to wiki.mozilla.org|220.127.116.11|:80... connected. HTTP request sent, awaiting response... 404 Not Found 14:33:29 ERROR 404: Not Found. $ wget http://wiki.mozilla.org/images/b/b5/Platform_patches_060508.zip --14:34:18-- http://wiki.mozilla.org/images/b/b5/Platform_patches_060508.zip => `Platform_patches_060508.zip' Resolving wiki.mozilla.org... 18.104.22.168 Connecting to wiki.mozilla.org|22.214.171.124|:80... connected. HTTP request sent, awaiting response... 404 Not Found 14:34:18 ERROR 404: Not Found.
There seems to be some issue with all the uploaded files/images on Mozilla Wiki.
Ray, you can try doing the Moz-DFB installation using script now. The uploaded packages are available for download.
I have managed to get everything built. However, I did not use the script. A script is an added convenience, but a convenience which is not reliable is not a help. FYI, the wiki page needs to be updated. The DirectFB-1.2.0-rc1 release is no longer available on the web site. They have moved to DirectFB-1.2.0. I would the wiki page myself, but I think the reference to the patch should also be taken out. With DirectFB-1.2.0, the patch is no longer necessary. I did not want to presume to remove a link to somebody else's patch. Maybe a patch is still required for DirectFB-1.2.0? I think not, but someone may know better.
If you post the errors your are getting with the script, may be we could help.
I could. But I was getting 404s off the URLs in the script. Anybody could have tested that and nobody else did. I do not mind taking the time to characterize errors, but I have lots of experience doing that with Moz technologies that nobody was ever planning on fixing. So. I have it working with the manual instructions. So my interest in the script is over. Is this script going to be supported for the long term? If you all were saying I should be able to do a "cd mozilla ; make mobile", I would be much more interested in helping to test that. That is the "Mozilla" way of building apps, and the DirectFB port is not integrated into that way of building. I am not seeing a compelling reason to worry about a way of building the app that will probably be thrown away at some point anyway. So, if you all are planning on doing a "make mobile" integration into the build system, please let everyone know.
To state this more correctly, I was hoping that at some time, one could use --enable-directfb on a call to configure and have the right things happen. Moving to this would be much more interesting than seeing a hacked-together script get fixed.
F it! Why can I not say this correctly. I know what I mean. I am not the idiot I sound like. This would be good: apt-get build-dep firefox-directfb That is it. That is the tool chain I am speaking of. Jeez.....
Ok, core stuff is landed, so I'm going to close off this bug. What's not landed is: - cairo patches upstream (will do later on today probably) - cairo patches in mozilla's in-tree cairo (will happen next cairo upgrade) So those and the gtk patches are still outstanding. But the mozilla-side code should be there. Let me know if I broke anything while doing the merge; also, you'll probably want to start working directly from mozilla-central instead of the mozilla-dfb repo since they diverge at this point.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 12 years ago
Resolution: --- → FIXED
So, is the page (http://wiki.mozilla.org/Mobile/DFBPorting) going to be updated with the new hg checkout procedures?
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
This update seems to have broken my source, c++ -o gfxFT2Fonts.o -c -I../../../dist/include/system_wrappers -include ../../../config/gcc_hidden.h -DIMPL_THEBES -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_COM_OBSOLETE -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES -DZLIB_INTERNAL -DOSTYPE=\"Linux2.6\" -DOSARCH=Linux -I. -I. -I../../../dist/include/cairo -I../../../dist/include/string -I../../../dist/include/pref -I../../../dist/include/xpcom -I../../../dist/include/unicharutil -I../../../dist/include/lcms -I../../../dist/include -I../../../dist/include/thebes -I../../../dist/include/nspr -I../../../dist/sdk/include -fPIC -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-long-long -pedantic -fno-strict-aliasing -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -O3 -I../../../dist/include/cairo -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pixman-1 -I/usr/include/gtk-unix-print-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pixman-1 -DMOZILLA_CLIENT -include ../../../mozilla-config.h -Wp,-MD,.deps/gfxFT2Fonts.pp gfxFT2Fonts.cpp gfxFT2Fonts.cpp: In member function ‘gfxFT2Font* gfxFT2FontGroup::FindFontForChar(PRUint32, PRUint32, PRUint32, gfxFT2Font*)’: gfxFT2Fonts.cpp:378: warning: unused variable ‘selectedFont’ gfxFT2Fonts.cpp: In constructor ‘gfxFT2Font::gfxFT2Font(FontEntry*, const gfxFontStyle*)’: gfxFT2Fonts.cpp:625: error: no matching function for call to ‘gfxFont::gfxFont(const nsString&, const gfxFontStyle*&)’ ../../../dist/include/thebes/gfxFont.h:471: note: candidates are: gfxFont::gfxFont(gfxFontEntry*, const gfxFontStyle*) ../../../dist/include/thebes/gfxFont.h:441: note: gfxFont::gfxFont(const gfxFont&) gfxFT2Fonts.cpp: In member function ‘virtual nsString gfxFT2Font::GetUniqueName()’: gfxFT2Fonts.cpp:778: error: ‘mName’ was not declared in this scope gfxFT2Fonts.cpp: At global scope: gfxFT2Fonts.cpp:261: warning: ‘PRInt32 AppendDirectionalIndicatorUTF8(PRBool, nsACString_internal&)’ defined but not used make: *** [gfxFT2Fonts.o] Error 1 make: Leaving directory `/home/mdew/ff/src/gfx/thebes/src' make: *** [libs] Error 2 make: Leaving directory `/home/mdew/ff/src/gfx/thebes' make: *** [libs] Error 2 make: Leaving directory `/home/mdew/ff/src/gfx' make: *** [libs_tier_gecko] Error 2 make: Leaving directory `/home/mdew/ff/src' make: *** [tier_gecko] Error 2 make: Leaving directory `/home/mdew/ff/src' make: *** [default] Error 2
Pushed some additional compilation fixes; things should build out of the box now, assuming: --enable-system-cairo (and the latest cairo from git -- I pushed out the directfb patches earlier); and --disable-plugins.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
afraid its still broken, http://pastebin.com/f63818539
Add --disable-pango ; configure.in should take care of that, but doesn't currently.
FontEntry is derived from gfxFontEntry and duplicated fields within FontEntry are removed.
File gfxFT2Fonts.cpp has (C) 2005 and no contributors are listed
how can I verify this bug?
One way to verify this bug would be to look at the page on porting (http://wiki.mozilla.org/Mobile/DFBPorting) and see whether the procedures in the "GTK-DFB Package Installation" (script and manual) and "Building and testing Firefox-DFB" sections work on the platforms that are supposed to work. It would also be good to know those procedures, as they are documented, will work in the future also. But this may be a more complicated problem.
http://hg.mozilla.org/mozilla-central/rev/cc78d78aac5e reverted much of the fix for bug 445707.
You need to log in before you can comment on or make changes to this bug.