[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: X in FC7

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]