Jesse Barnes wrote:
Well, I created an account but can't seem to edit the page. Anyway, I
like the idea of getting rid of xfs, it seems fairly useless. And to
quote mharris from awhile back:
Long term, what would be really nice, is if someone figured
out a way to implement core fonts using fontconfig/Xft
underneath so we have one font system, and it provides
legacy compatibility to ancient applications that have not
been updated to modern interfaces. That is something that
would need to be spearheaded at the X.Org level rather than
at a specific distribution however.
So here's where I start to admit some font ignorance, but. I took a
hack at this a while back, and it seemed to me like using fontconfig for
matching was the wrong idea, since the properties available from
fontconfig didn't quite match what you can select on with XLFD.
As said on the wiki page, what problem is xfs trying to solve? If it's
just about the ability to add fonts at runtime without having to do
'xset fp rehash', then that should be a very small amount of code to add
to the X server. You need to watch for directories popping in and out
of existance, but, okay, we know how to do that.
That said, which apps care about core fonts these days? Would it make
sense to just build-in a fixed font or something and let everything
else use fontconfig (as most decent apps do these days)?
We do actually have a built-in fixed font now. And cursor. They've
always been in the modular libXfont, we were just never telling the
server to use them. In FC6 they're enabled by default.
You can not remove core font functionality though, for the same reason
you can't remove dashed wide arcs.
Also, which input drivers should we be using? Isn't synaptics much
better for laptops than the default mouse driver? What about evdev?
Should it be the default?
We already detect synaptics via some anaconda voodoo.
evdev should probably become the default once the input hotplug branch
lands upstream and we start shipping that server; that's likely to be
xserver 1.3, so that might not be ready in time for Fedora 7.
That's sort of the pink elephant here. 1.3 will have a lot of really
good stuff merged, but it's likely to be broken, guaranteedly for closed
drivers but also internally. I'm hoping we can get dist-{hg,git} going
soon so I can make packages available for both, 1.3 for the adventurous
and 1.2 for the sane. Yes it's doable with CVS, but that's far more
pain than I'm willing to take.
Thanks all for the feedback, keep it coming.
- ajax
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
