#include <X11/Xft/Xft.h>
int main()
{
XftFontClose(0, 0); return 1;
;
return 0;
}
Now when I tried to do this from the command line using
gcc -o test `pkg-config --cflags xft` test.c `pkg-config --libs xft`
I recieved quite a few errors, mainly indicating that the FT_* types (alal freetype) could not be found... I'll look into it more, but I don't think it's a fluxbox problem as I have built it myself on a debian system and a gentoo system... I'll do more testing and get back to you.
---------------
Ok weird... but as I was writing this I attempted a recompile of the above and it worked (though segfaults as expected on run). Yet fluxbox will still not detect Xft... as stated, I'll report in on progress later
]]>3. Do the developers of fluxbox even know that the newest version of freetype doesn't work with their software? Just because freetype was upgraded they don't/can't contact everyone who uses it and tell them there may be problems with their new version. Maybe they have a fix in CVS that hasn't made it to release yet. Imagine if every piece of software that depended on something that was upgraded was released at the same time because of an incompatible change.
What extra warning can they give, especially for something as widely used as freetype? And what if the developer of fluxbox doesn't want do the work to support the newest version, sort of like the problem from gnome 1.3 to gnome 2? There are lots of factors to take into account.
From the sounds of it it seems like a pretty easy thing to fix anyway.
]]>Ive tried many different things, and it seems to be a problem with pango/freetype.
I did enable kde/gnome extensions on the new package though.
]]>Just to clarify this - both my version and yours do not have proper XFT enabled, correct?
I'll look into it a bit and see if I can throw together a patch... doubt I'd be faster than someone else attempting the same thing though
]]>2. Numbers do mean something, otherwise they wouldn't be there. With previous freetype releases, when changes were made that caused incompatability, the major version was changed. ie. Freetype1 is incompatable with freetype2.
How would you like it if the kernel team one day decided to make even numbered releases the testing version. It would cause some chaos. People go to download the latest stable source and get some half-broken developers build.
And of course, they've only posted it on the mailing list, so the general public has no idea.
3. If they are forcing proper usage, they should have given more warning. If all the major packages wont build, it seems that the freetype crew just sprung it on the world.
]]>I think it's also silly to expect other people to live up to your expectations for releases. Release numbers mean nothing. Usually it is expected that certain things mean certain other things but ultimately they're just useless numbers. A lot of the time a number that's higher than another number means a newer version but not always.
Who knows, maybe they were fixing a bug by forcing proper usage of their library. That's what it sounds like they're doing. Every change is going to affect compatibility, no matter what.
]]>Its called Compatability. Freetype should have kept it. If they wanted to do something like this, they should have called it freetype3. You cant do something major in a point release.
So yes, its freetype's problem.
Im going to start another thread so we can discuss solutions for the common apps (gimp, pango, gtk2). Because I dont know C.
]]>one thing you can look for is freetype warnings during compilation of fluxbox. you can pipe the output to a file and then analyze this file after.
the other thing you can do is look at the logs to see if there is any info thare about issues fluxbox is having.
the fix will have to be applied to fluxbox likely if it is a freetype2 issue.
]]>Its pretty much the only thing I can think of. It finds XFT, it just cant link to it.
This problem really has to be fixed.
Oh, and a newer version of fluxbox came out. Ill upload a new package, this time w/ KDE and GNOME enabled.
Do me a favor and check /usr/bin/fluxbox -info on your system... mine has XFT disabled and Xinerama enabled (though I dont particularly need it).
I have no clue why, if you specified Xft enabled and it works on your system, it doesn't work on mine... going to do some checking... I know fc-cache works so I do have freetype/fontconfig installed (and pacman forces it anyway when installing X 4.3). I'll get back to you.
In addition, the newest tarballs from fluxbox.org have a few newer additions that your package does not... namely the addition of the startfluxbox script and the .fluxbox/startup file. These aren't important, but I'd like to keep my setup as close to the current one as possible - so if you get around to upgrading the package sometime soon let me know.
Try my package and see if it works.
]]>I copied the fluxbox PKGBUILD and changed it for the newest version of fluxbox... the only difference was that I added --enable-xft --enable-gnome --enable-kde as my flags and am using the 0.9.6 sources.
No everything works all fine and dandy, however the executable that it spits off does not have xft enabled (pkg/usr/bin/fluxbox -info spits out "-XFT" indicating it was disabled)
Any help would be appretiated.
]]>