Closed Bug 239466 Opened 20 years ago Closed 20 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: 20 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: 20 years ago → 20 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: 20 years ago → 20 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: