[openbox] Re: Patches: Xft and i18n enhancements
ben at orodu.net
Thu Apr 3 15:33:52 EST 2003
On Thu, Apr 03, 2003 at 06:37:38PM +0200, Mike FABIAN wrote:
> Ben Jansens <ben at orodu.net> ?$B$5$s$O=q$-$^$7$?:
> > When I started hacking on Openbox 2, I really didn't have the slightest clue
> > what was going on with locales vs UTF-8 etc, so when I started adding UTF-8
> > support, I went about things all wrong. Not to mention the use of catgets.
> > I appreciate the informative email. I have since learnt the err of how xft
> > fonts were handled in the Openbox 2 styles, how they're opened, and about
> > such font aliases. Openbox 3 is going to be much better for this.
> > a) I am using gettext instead of catgets
> Good idea, I believe gettext is more convenient than catgets too.
> > b) All translations will be read in UTF-8:
> > bind_textdomain_codeset(PACKAGE_NAME, "UTF-8");
> > c) Not using Xlib font routines at all. Only using the Xft2 font routines,
> > so UTF-8 can always be drawn.
> I think that is a good idea as well. I only tried to fix the support
> for the Xlib font routines because I thought a patch might be rejected
> immediately if I suggested to remove them. But while trying to fix
> them I realized again how much easier Xft2 is.
> I removed the support for single fonts via Xlib already and kept
> only fontsets to simplify it at least a little bit. But it is still
> ugly compared to Xft2.
> Xft2 is certainly the way to go and investing much time to fix the
> Xlib font supports only for compatibility with old systems is probably
> not worth it.
> Gnome2 already requires Xft2 and I heard GTK2 will require Xft2 soon
> as well. I.e. nobody seems to think it makes sense to support older
> systems with Gnome2.
> If supporting old systems gets in the way with improving openbox
> for modern systems, I think it's OK to drop support for old systems.
Its really not an issue of supporting old systems. Xft is a client side
library that can be installed anywhere. Its being distributed with XFree86
now and is meant to replace Xlib fonts, not be an addition to them.
> > d) All strings will be treated as UTF-8, so menus etc will all need to be in
> > UTF-8 format.
> > e) The few strings I get from window hints for display, which are not in
> > UTF-8 are immediately converted to UTF-8 using the glib conversion
> > routines.
> > f) Fonts are specified in the rc file using simply a string, so the font
> > you choose can be as fancy or as simple as you want. The fallback font
> > will be "sans" or a variation of "sans" so multiple languages should
> > perform better here too.
> > g) I think that's it. I'd appreciate if someone with some
> > multibyte/non-english fonts and skills could try out openbox3 from CVS
> > in the near future. (Its having some build issues at the moment, as I'm
> > removing the use of automake, but in the next few days everything should
> > be rocking again.)
> That sounds very good!
> I'd like to test openbox3 from CVS.
> I just made a CVS checkout to have a look, but currently many files
> seem to be missing. The 'src' directory is empty for example
> and there are not many source files in other places either.
> Is that only because of the restructuring of the build system you
cvs update -P :) The src directory is meant to be empty. The changes I'm
making now affect the Makefiles and configure system.
I am damn unsatisfied to be killed in this way.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the openbox