Closed Bug 239466 Opened 21 years ago Closed 21 years ago

enable Xft by default in GTK2 builds

Categories

(SeaMonkey :: Build Config, defect)

Product:
SeaMonkey
Component:
Build Config
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.8alpha1

People

(Reporter: dbaron, Assigned: blizzard)

References

Details

(Whiteboard: [patch])

Attachments

(1 file, 1 obsolete file)

make xft work with gtk2 by default
1.14 KB, patch
bryner
: review+
dbaron
: superreview+
Details | Diff | Splinter Review
We should enable Xft by default in GTK2 builds. By this, I mean that of the six sets of options: 1. ./configure 2. ./configure --enable-xft 3. ./configure --disable-xft 4. ./configure --enable-default-toolkit=gtk2 5. ./configure --enable-default-toolkit=gtk2 --enable-xft 6. ./configure --enable-default-toolkit=gtk2 --disable-xft we should change the behavior of (4) so that Xft is enabled rather than disabled, since most users building with GTK2 probably also want Xft.
Attachment #145348 - Flags: superreview?(blizzard)
Attachment #145348 - Flags: review?(bryner)
Status: NEW → ASSIGNED
Whiteboard: [patch]
Target Milestone: --- → mozilla1.7final
Comment on attachment 145348 [details] [diff] [review] patch dbaron: How should this work on platforms which do not have Xft ? Neither Solaris, HP-UX nor AIX have Xft and likely won't adopt such a proprietary technology.
Attachment #145348 - Flags: review?(bryner) → review-
Then they can --disable-xft. This is to convenience *most* gtk2 users, as dbaron stated.
And I don't think xft is proprietary technology (else Red Hat wouldn't ship it), unlike HP-UX or AIX...
Christopher A. Aillon wrote: > Then they can --disable-xft. This is to convenience *most* gtk2 users, as > dbaron stated. That will still break the default GTK2 build on platforms which do not have Xft. "configure --enable-default-toolkit=gtk2" should work out-of-the box - this was at least the default for all toolkits in the last years. I suggest to enable the GTK2/Xft combination only on Linux since this is the only platform which supports Xft by "default".
Christopher A. Aillon wrote: > And I don't think xft is proprietary technology (else Red Hat wouldn't ship > it), unlike HP-UX or AIX... Please correct me if I am wrong: "Xft" is NOT SUPPORTED in any way by the X Consortium. And they make the X11 standard, not Red Hat.
Comment on attachment 145348 [details] [diff] [review] patch People on those platforms can --disable-xft. They're a tiny minority compared to Linux users.
Attachment #145348 - Flags: review- → review?(bryner)
(In reply to comment #6) > "Xft" is NOT SUPPORTED in any way by the X Consortium. And they make the X11 > standard, not Red Hat. GTK isn't supported by the X Consortium either. So how is that relevant?
Comment on attachment 145348 [details] [diff] [review] patch dbaron: I am STRONGLY against breaking the default GTK2 build for every platform except Linux.
Attachment #145348 - Flags: review?(bryner) → review-
Comment on attachment 145348 [details] [diff] [review] patch You're not an owner or peer for any of the relevant modules, so please stop touching review flags that you shouldn't be touching. Xft seems to me to be a core part of the open-source GTK-based desktop environment, and is certainly used on platforms other than Linux (e.g., FreeBSD), and is likely to be used on more. And I don't see any reason it can't be used on any of the platforms you mention -- it's a client-side technology that uses XRender on the server, and XRender is official X consortium stuff.
Attachment #145348 - Flags: review- → review?(bryner)
David Baron wrote: > (From update of attachment 145348 [details] [diff] [review]) > You're not an owner or peer for any of the relevant modules, so please stop > touching review flags that you shouldn't be touching. As you wish. I've CC:'ed a few platform owners. And I am sure they are VERY UNHAPPY about such a change.
David Baron wrote: > Xft seems to me to be a core part of the open-source GTK-based desktop > environment, This is not correct. Solaris and other Unix vendors use Gnome/GTK+ without Xft. And Xft itself is likely to be replaced by another technolocy currently in development.
what's a technolocy?
Dan Witte wrote: > what's a technolocy? That was a typo (see http://dict.leo.org/?search=technolocy&searchLoc=0&relink=on&spellToler=standard&sectHdr=on&tableBorder=1&cmpType=relaxed&lang=en ... I wish bugzilla would have a spellchecker :) , I mean "technology".
Roland, stop making a bogus fuss about Xft and stop messing with review request flags -- you're putting your bugzilla privileges in jeopardy. If Sun or whomever comes up with an alternative to Xft, and it's open, and it works well, then let's talk -- in another bug. /be
While Roland's tactics are out of line, he does have a point. What practical application does this have outside of making certain users' mozconfig's more convenient? I've always stated that we shouldn't tie one set of build options to another (although that seems to be happening more often now). IIRC, xft isn't otherwise tied to gtk2 so why turn it on just for gtk2 builds? And is this the sort of last minute change that should go into a release that was supposed to branch RSN?
FWIW, I don't like this patch either. gtk2 and xft are separate entities, let's not muddy the waters.
Fine, I'll stop caring about other people's code.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
Actually, never mind. (And the reason I was mad was really what cls said on IRC, not what he said on the bug.) At some point we're going to want to make GTK2 the default for X11 builds rather than GTK1. It also seems reasonable that at some point we'd want to make --enable-xft the default. So is it really that unreasonable to make --enable-xft the default for GTK2 builds and not GTK1 builds at this point, since users with GTK2 are *far* more likely to have Xft than those that don't have GTK2?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
David Baron wrote: > At some point we're going to want to make GTK2 the default for X11 builds > rather than GTK1. > It also seems reasonable that at some point we'd want to make > --enable-xft the default. So is it really that unreasonable to make > --enable-xft the default for GTK2 builds and not GTK1 builds at this point, > since users with GTK2 are *far* more likely to have Xft than those that don't > have GTK2? What about enabling Xft support for GTK2 builds ONLY when libXft and the fontconfig libs are available ?
Using future possibilities is a poor justification for making a poor decision right now. While these features may be popular and often-used, they are separate and should not be joined together like that. If you want to separately make gtk2 the default toolkit and make xft a requirement, then propose that. Btw, far more people build optimized than debug but yet we haven't changed that default which would make far more sense (bug 54828) with regards to "user convenience". And what makes this build change so urgent that it's being targetted for 1.7final?
If we want to do this, I don't see any reasons not to do it for 1.7 -- it certainly wouldn't affect any of the builds mozilla.org produces. But beyond that, I wasn't expecting this to be so controversial considering the consensus a bunch of us had when discussing it yesterday. So wontfix.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → WONTFIX
I agree with what dbaron said in comment 19 -- we will want to change the defaults sometime in the near future. Perhaps not before 1.7 though. However, I think the xft test in configure.in need to be reworked in order for this to happen reasonably. IMO, We want to test for the presence of xft, enable xft support if it is present, and proceed without it if not. No xft support should only be fatal if --enable-xft was given explicitly. dbaron, I think I was part of the concensus about switching on xft by default but this patch isn't quite what I had in mind.
Comment on attachment 145348 [details] [diff] [review] patch minusing per my previous comment
Attachment #145348 - Flags: review?(bryner) → review-
Attachment #145348 - Flags: superreview?(blizzard)
I'm not a big fan of doing things differently depending on what's installed on the system -- since then a given choice of compiler and set of configure options isn't a reliable way to reproduce the same type of build. The only place I can think of where we already do that is the freetype test, although maybe there are others. But anyway...
Just a warning: it's very likely that with the upcoming pango integration that I'm going to make it so that xft won't build without gtk2.
No, we still want to do this. We just need a better patch to do it.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Patch that builds Xft by default with Gtk2 and doesn't allow it to be built without Gtk2 as the toolkit. Also allows --disable-xft.
Attachment #145348 - Attachment is obsolete: true
Attachment #145407 - Flags: superreview?(dbaron)
Attachment #145407 - Flags: review?(bryner)
Comment on attachment 145407 [details] [diff] [review] make xft work with gtk2 by default dbaron has a point... I think other apps do the sort of use-it-if-it's-there approach I mentioned but maybe that doesn't make it a good thing. I don't have a strong opinion either way at this point. Given that, this patch seems fine. But I think it should wait for 1.8 alpha.
Attachment #145407 - Flags: review?(bryner) → review+
Comment on attachment 145407 [details] [diff] [review] make xft work with gtk2 by default note that specifying gtk2 but not having Xft is still fatal (and with a cryptic message) with this patch
Assignee: dbaron → blizzard
Status: REOPENED → NEW
Target Milestone: mozilla1.7final → mozilla1.8alpha
Attachment #145407 - Flags: superreview?(dbaron) → superreview+
(In reply to comment #30) > (From update of attachment 145407 [details] [diff] [review]) > note that specifying gtk2 but not having Xft is still fatal (and with a cryptic > message) with this patch > Not fatal if you use --disable-xft.
Brian Ryner (IBM) wrote: > (In reply to comment #30) > > (From update of attachment 145407 [details] [diff] [review]) > > note that specifying gtk2 but not having Xft is still fatal (and with a cryptic > > message) with this patch > > Not fatal if you use --disable-xft. This wouldn't be a "default" GTK2 build then anymore. Can someone please make a new patch which explicitly disables this new functionality on AIX, HP-UX and Solaris ? I guess then everybody will be happy again :)
(In reply to comment #25) > The only place I can > think of where we already do that is the freetype test, although maybe there are > others. there's also gnomevfs and negotiateauth (checks for gssapi) and maybe others.
Xft is certainly the preferred font system for gtk 2.x. There's zero doubt about that. As an example, gtk 2.4 doesn't even include support for core X fonts anymore. You have to use Xft. So those other operating systems are going to have to upgrade or stay at Gtk 2.2 for the long term. I think that for those who are going to use the non-preferred font rendering system with the toolkit in question having to include an extra flag to configure isn't too much to ask, and it certainly means that those who do builds by hand are going to get the best out of their systems when it's available and be warned when they are setting up without the best configuration possible.
Status: NEW → ASSIGNED
I'm with blizzard and dbaron, in case it isn't obvious. This bug is about policy, so permit me to advocate policy for a moment: Unix fragmentation will be the death of us all. I've been hacking kernel and usercode since the early eighties, and I'm sick of it. How many open source projects have to compromise, or simply drop features altogether, because there is no cross-Unix/Linux (antialiased font technology | object file metadata format | GUI toolkit | ...)? The Enemy has no such handicap. It's time for the Unixes of the world to converge. That inevitably means someone's ox gets gored. Tough: the alternative is that we hang apart. Let's hang together. Concretely, if this means the non-gtk2+xft configs have to type extra configure options, that's the way it should be. I don't mean we should have poor configure error handling, of course. /be
Blocks: gtk2
OK, after 1.7 is cut this is going in.
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
checking for GTK - version >= 1.2.0... yes configure: error: Cannot enable XFT support for non-GTK2 toolkits. *** Fix above errors and then restart with "gmake -f client.mk build" gmake: *** [/home/dark/MOZ/TREE2/mozilla/Makefile] Error 1
>Patch that builds Xft by default with Gtk2 and doesn't allow it to be built >without Gtk2 as the toolkit. Also allows --disable-xft. Oh my.. it's intentional! Why on earth isn't it allowed anymore to build with Xft if using Gtk 1.2?
Because it's a configuration that I don't want to have to support in the long term. And we're about to add a lot of pango love to that code, which will definitely make it require gtk2.
I get now the same error when building on Fedora core 1 without "--enable-default-toolkit=gtk2" but with "--enable-xft". Why should it be broken on purpose if it worked before this "patch" was checked-in? Well, comment #40 seems to answer that but I am still not 100% convinced.
It's worth asking those who want the GTK1 + Xft configuration: why don't you want GTK2 + Xft?
David: the better question would be why if GTK2 is present, it is not used by default? If GTK2 was used by default, my config (the one without "--enable-default-toolkit=gtk2" but with "--enable-xft") would be working.
To comment 42: First of all: I didn't expect "enable Xft by default in GTK2 builds" to mean "disable Xft forever in GTK1 builds". That's cheating. Secondly: My Gtk2 build has a distinct sluggish feel to it, compared to Gtk1 builds. For isntance resizing the sidebar feels like wrestling a piece of jello. I prefer UI fonts to not be aa'ed, but with Gtk2, text in sidebar, alerts, dialogs are ALSO anti-aliased. Perhaps they pick up fonts a different Gtk theme. Scrollbars and widgets also changed, I can't seem to change them again, unless running under Gnome. (Which here, after some encounters with Ximian, looks like a jumpy kaleidoscope for each click on it. Broken Gnome. So I use KDE. Those were some practical drawbacks. If the idea behind this bug was to force users onto Fedora: Ingenous. After some hours of sweating here, I actually started an upgrade. I don't mean people should struggle behind with old libraries forevermore, but there are nicer ways to encurage upgrades than the stunt pulled in this bug.
personal preferences aside, if XFT support is going to require pango and thus GTK2 (bug 215219) then arguing about disabling GTK1+XFT now instead of later is academic at best.
Mike is right. With Pango patch forthcoming (in bug 215219), there's no point of talking about gtk1 + Xft.
I tried the GTK2 builds a long time ago and found them to be sluggish and unresponsive on my old Pentium II 450, so I stayed with the GTK1 builds with Freetype2 enabled for a long time. I figured out the best settings in unix.js to make the fonts look almost as nice as the Xft builds. At some point, I discovered that I could enable Xft in the GTK1 builds, and for a while I had the speed of GTK1 with the nice Xft fonts. Eventually, that support was dropped and I got build errors (I think) from not linking against a fontconfig library. So, I went back to GTK2 builds again. By then, I had upgraded to the Linux 2.6 kernel and I also started building with GCC 3.4 snapshots, so now GTK2 builds are just responsive enough to be acceptable. I did pull down a GTK1 nightly build yesterday and discovered it didn't even have Freetype2 support compiled in, so the fonts were barely tolerable. This brings a couple questions to mind. First, why don't the GTK1 builds have Freetype support enabled to at least make pages look semi-decent? Second, why do you even do GTK1 builds anymore? Considering that most modern Linux distros have GTK2/Xft Mozilla installed by default, I don't see why very many people would want the current builds. Maybe just a few people on older, slower machines than even mine who don't realize how ugly non-Freetype2 and non-Xft builds really are.
Blocks: 241095
Why I don't use GTK2 is for it breaks all the shift-ctrl key combinations and GTK1 is a lot faster.
(In reply to comment #42) > It's worth asking those who want the GTK1 + Xft configuration: why don't you > want GTK2 + Xft? I don't care for XFT either way. GTK2 has bloody too many depencies for me to care for it. Thus i prefer GTK1 support w/o XFT.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: