I know this is sooner than the usual week, but I didn't see any @gentoo.org emails tracking Mozilla bug 448989, so I'm assuming nobody over there is aware of it. Anyhow, it would be very nice if Gentoo had some www-client/mozilla-firefox that supported the qt4 USE flag.
Uh...well, this is for mozilla-central which is post 3.1a1...so nothing to do here...reopen when a2 is released, at least.
The Mozilla overlay has 3.1 alpha 2
I have managed to emerge a live build of xulrunner/firefox with Qt4 interface by modifying slightly the ebuilds from mozilla overlay and the eclasses in the main tree (had also to use bundled cairo and nspr for xulrunner to compile). What I would like to say is that currently it is not worth the effort, as the interface looks even worse than when using GTK with a Qt theme :) If anybody is interested, I could share my modifications.
Anyway,that's tempting.I am interested.
Created attachment 171667 [details, diff] The diff to in-tree eclasses These are the changes (seemingly dirty) I've made to official eclasses.
Created attachment 171668 [details] A live firefox ebuild with cairo-qt
Created attachment 171669 [details] A live xulrunner ebuild with cairo-qt
As for me, I did not even get working nsplugins with this build (not sure whether the problem is with my ebuilds or with upstream code). Also keep in mind that mercurial checkouts are painfully slow here.
Created attachment 171748 [details] Updated ebuild Minor updates to allow for building current trunk.
Created attachment 171750 [details, diff] A patch to build the bundled cairo with Qt This one is taken from the upstream bugzilla (corrects a minor compile-time error).
Created attachment 171751 [details] Updated firefox ebuild This one corrects the wrapper script to set the environment variable properly (did not start up otherwise).
Created attachment 171752 [details] A screenshot of a running Firefox/Qt This is a screenshot of a KDE4 session (current trunk) with a Firefox window opened, built with the above ebuilds from current trunk. Note the multiple inconsistencies in the UI. Also keyboard shortcuts (Ctrl+T, Ctrl+Backspace, double-click to select a word, etc) do not work properly, and currently I do not have nsplugins working (did not yet try to apply the corresponding Gentoo patch, though). Last but not least, saving and printing are completely non-functional.
thank you very much
any update? i tried to compile (gcc 4.3.3), both manually and using this ebuild but i get an error: nsWindow.cpp: In member function 'virtual nsresult nsWindow::Move(PRInt32, PRInt32)': nsWindow.cpp:419: error: 'class nsIWidget' has no member named 'mDrawingArea' nsWindow.cpp:420: error: 'class nsIWidget' has no member named 'mDrawingArea' nsWindow.cpp: In member function 'void nsWindow::NativeResize(PRInt32, PRInt32, PRInt32, PRInt32, PRBool)': nsWindow.cpp:1878: error: 'class nsIWidget' has no member named 'mDrawingArea' nsWindow.cpp:1879: error: 'class nsIWidget' has no member named 'mDrawingArea' gmake[5]: *** [nsWindow.o] Error 1 !!! When you file a bug report, please include the following information: GENTOO_VM=sun-jdk-1.6 CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.6.0.11" JAVACFLAGS="-source 1.4 -target 1.4" COMPILER="" Portage 2.1.6.7 (default/linux/amd64/2008.0, gcc-4.3.3, glibc-2.8_p20080602-r1, 2.6.27-gentoo-r8 x86_64) ================================================================= System uname: Linux-2.6.27-gentoo-r8-x86_64-Intel-R-_Core-TM-2_Duo_CPU_T7500_@_2.20GHz-with-glibc2.2.5 Timestamp of tree: Wed, 25 Feb 2009 19:15:01 +0000 app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7-r1, 2.1.6-r1 dev-lang/python: 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 dev-util/cmake: 2.6.2-r1 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=core2 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/4.2/env /usr/kde/4.2/share/config /usr/kde/4.2/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=core2 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://darkstar.ist.utl.pt/gentoo/ " LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/mozilla /usr/local/portage" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Any chance this could be integrated into beta3 in the overlay (once it gets there, it was released a few days ago)? This would really make me a happy camper :)
net-libs/xulrunner-1.9.1_beta4-r1 failed with USE="qt" cairo-qpainter-surface.cpp: In function 'cairo_int_status_t _cairo_qpainter_surface_show_glyphs(void*, cairo_operator_t, cairo_pattern_t*, cairo_glyph_t*, int, cairo_scaled_font_t*, int*)': cairo-qpainter-surface.cpp:1391: error: invalid conversion from 'int' to 'cairo_text_cluster_flags_t' cairo-qpainter-surface.cpp:1391: error: initializing argument 10 of 'cairo_status_t _cairo_surface_show_text_glyphs(cairo_surface_t*, cairo_operator_t, cairo_pattern_t*, const char*, int, cairo_glyph_t*, int, const cairo_text_cluster_t*, int, cairo_text_cluster_flags_t, cairo_scaled_font_t*)' gmake[5]: *** [cairo-qpainter-surface.o] Error 1
(In reply to comment #16) > net-libs/xulrunner-1.9.1_beta4-r1 failed with USE="qt" > ewarn "You are enabling the EXPERIMENTAL qt toolkit" ewarn "Usage is at your own risk" ewarn "Known to be broken. DO NOT file bugs." Please read the messages. They are there for a reason. The reason being: No patches will be added to this ebuild for this feature, and this feature will *not* be moved to portage unless it works properly upstream.
qt support will be added back to the overlay at a later time. Right now main concern is getting xulrunner/firefox in the tree unmasked. Once this happens I will revisit the qt support.
Latest Firefox is stable in the main tree.
Please do not reopen this bug, I am aware that many of you are wanting qt support, it is no where near ready for mainline use and not supported even by upstream at this time, until it is this will be resolved as later.
*** Bug 292158 has been marked as a duplicate of this bug. ***
Has anything been done with this recently? It would be nice to have a Qt4 firefox build on Gentoo Linux, even if it is only for beta testing purposes. Mozilla Firefox 3.6.3 is out at this point and the ebuilds here seem to be for Firefox 3.0.
Cairo with qt4 support is in main tree. What about firefox?
(In reply to comment #23) > Cairo with qt4 support is in main tree. What about firefox? > Do up a patch and email me directly and I will review and see about adding to overlay, if you get this too me soon enough I might even concider adding it to the tree upon final release of xulrunner-2.0/firefox-4.0
Created attachment 247612 [details] xulrunner-2.0_beta7 fail with USE=qt4
(In reply to comment #25) > Created an attachment (id=247612) [details] > xulrunner-2.0_beta7 fail with USE=qt4 > We now it fails, this is not part of the bug, we will fix it when we get to it qt is not officially supported in gentoo at the moment.
If qt is reworked upstream to compile again, I will reopen the bug. In the current state there is no upstream dev working on qt support anymore so it is surely either gonna be removed from the mozilla tree or someone will step up and maintain it.
Fixed again, now mozilla autobuilds qt builds of firefox http://blog.johnford.info/linux-qt-builds-of-firefox-now-being-generated-2/
(In reply to comment #28) > Fixed again, now mozilla autobuilds qt builds of firefox > http://blog.johnford.info/linux-qt-builds-of-firefox-now-being-generated-2/ > If you truely believe this go ahead and add support and test, if all goes well then attach a patch and we will land it in the overlay.
Created attachment 260152 [details, diff] Patch for xulrunner-2.0_beta10_pre.ebuild to support qt USE flag Unfortunately building fails, as I have too new (4.7.x) version of Qt4. Is someone has 4.6(.x), please test. Doesn't work with 4.5(.x) too.
Given comment #28, this bug deserves reopening IMO.
(In reply to comment #31) > Given comment #28, this bug deserves reopening IMO. > Mozilla team has made their decision, when it warrants reopening the bug we will make it happen, until then please leave as later unless you have been able to build with success in gentoo.
Shouldn't it be marked as UPSTREAM then?
Presumably he means the Gentoo Mozilla herd. Upstream has Qt4 support.
As Jory said in comment #29, if you make a working patch, he will add it to the overlay.
Is firefox-9999 in sardemff7 overlay? Cause I didn't find any 9999 in mozilla-overlay.
