Marc Aurele La France:
> At first, I really liked this idea, but I now realize that, because your
> spacing changes (as I have them integrated) are only effective for Xft
> fonts, "Xft'ing" bitmap fonts would change twm's default behaviour. Thus,
> I'd rather not call XftFontOpenXlfd(), which leaves me with a GetFont()
> function that looks like ...
>
> void
> GetFont(MyFont *font)
> {
> if (font->fontset != NULL)
> XFreeFontSet(dpy, font->fontset);
> if (font->font != NULL)
> XFreeFont(dpy, font->font);
>
> #ifdef TWM_USE_XFT
>
> if (font->xftfont != NULL)
> XftFontClose(dpy, font->xftfont);
>
> font->xftfont = XftFontOpenName(dpy, Scr->screen, font->name);
> if (font->xftfont != NULL) {
> font->height = font->xftfont->ascent + font->xftfont->descent;
> font->y = font->xftfont->ascent;
> font->ascent = font->xftfont->ascent;
> font->descent = font->xftfont->descent;
> return;
> }
>
> #endif /* TWM_USE_XFT */
>
> [....]
>
> This means that, to use Xft, the user would need to specify
> a font name that is recognized by XftFontOpenName().
May I give two quick comments. :-)
I am very afraid that XftFontOpenName() is going to recognise each name,
including XFLD compliant names, at the same time probably not evaluating
them in the way one would expect. So if TWM_USE_XFT is defined, every
font name like
-b&h-lucidatypewriter-medium-r-*-*-12-*-75-75-*-*-iso8859-1
is being caught by XftFontOpenName() and ending up with some default Xft
font (which is no doubt going to look very good; but it is not that
lucidatypewriter font) and the control never passes to XLoadQueryFont()
few lines below.
This is kind of behaviour described in chapter 5.1 in
Keith Packard: "The Xft font library: architecture and users guide"
In fact this is the only piece of information I could find in order to
learn about Xft, plus a small usage demo program source code found in
www.mail-archive.com/render@xxxxxxxxxxx/msg00131.html. (This explains
in fact all bugs I have done/experienced so far in using Xft because of
the incompleteness of this small program.) Even until today I am
convinced that XftDrawCreate() never fails (much like XCreateWindow() is
never expected to fail) analogously to the Xft claim to always load a
font and report success even if that one requested by the user could not
be found; and last but not least because I am not being able to find any
evidence/documenting of the opposite of being the case.
(Maybe this document is outdated today (or going to outdate someday) and
the Xft's promise not to fail in loading fonts in that document is going
to change.)
The second point I wanted to touch in the above is spacing. Meanwhile I
consider the absolute pixel spacing as it now is in twm a design
deficiency, regardless if it is used with or without Xft (scalable)
fonts. Therefore I have decided to split spacing corrections from
TWM_USE_XFT and enclose these into TWM_USE_SPACING, so anyone interested
can enable/disable them unrelated to TWM_USE_XFT. (Even core fonts can
be given in "points" which is a typographical metrics and it is probably
true that today noone is going to design 120, 150, ... 600 dpi bitmap
fonts besides already existing 75 and 100 dpi fonts any more, but this
doesn't invalidate absolute distances of e.g. 4 pixels in twm of being a
"flawed design".) :-)
> In looking over your latest patch sets, I notice a fair amount of activity
> in the Fixes and Appearance ones. Do you now consider them as finalised?
> What about SloppyFocus?
These cannot be consider finalised. In the meantime I was working on
vtwm in porting some of these twm enhancements to vtwm. (In particular
vtwm got a better infowindow spacing which I want to bring back to twm,
among a few other things.) Then, SloppyFocus is getting into a good
shape thanks to vtwm experiments (there are some minor iconmanager rare
painting issues left) then I am probably finished with vtwm and I'll
want to continue with twm then.
*****
I was a little surprised to find twm's iconmanager (especially in a
multiscreen environment) and the function execution mechanism in an
unfinished state --- partly as unfinished design, partly even as
unfinished code --- as I began to add Xft support; I did not expect it
being so and therefore according to my initial estimate I should have
been done long ago.
So I cant give any estimate how long it takes to finalise the "Fixes",
"Appearances" and "Improvements" enhancements; it depends which parts of
these abovementioned parts need to (or make sense to) be completed
(partly it even is hard to guess how e.g. the icon manager in twm was
supposed to work at all --- maybe one should dig in decades old mailing
lists to get some hints :-).
> I'm attaching a diff, against XFree86 CVS source, of those of your changes
> that I have so far integrated.
In the Xorg version of the twm source code one has to use in the
following code sequence while drawing the window title
:
else if (Tmp_win != NULL)
{
if (Event.xany.window == Tmp_win->title_w)
{
MyFont_DrawImageString (dpy, DRAW_WIN(Tmp_win,title_w),
&Scr->TitleBarFont, DRAW_COL(Tmp_win,TitleC),
Scr->TBInfo.titlex, Scr->TitleBarFont.y,
Tmp_win->name, strlen(Tmp_win->name));
flush_expose (Event.xany.window);
}
else if (Event.xany.window == Tmp_win->icon_w)
{
:
the function MyFont_DrawImageString() and not MyFont_DrawString(). This
is because if there is no "NoTitleHighlight" in .twmrc then moving mouse
in and out of the client window causes the title-highlight window (the
checkerboard pattern) be mapped/unmapped as focus moves in and out.
While moving out expose events are generated for the underlying
titlebar-window which draws the title bar always anew without erasing
the draw area first, effectively alpha-blending the Xft partly
transparent text onto the title window again and again resulting in
smearing the titlebar text. In the other case if NoTitleHighlight is
active then expose events only come if the title bar was obscured,
resulting in clearing the titlebar window by the X server first, then
drawing the title by MyFont_DrawString().
> Lastly, do you intend to update twm's man page?
It has to be updated of course if these improvements are finished and
considered useful to be included into the twm source tree.
I am happily going to write the initial text, but I'll have to find
someone with English as a native language to correct this then. :-)
Greetings,
Eeri Kask
_______________________________________________
Devel mailing list
Devel@xxxxxxxxxxx
http://XFree86.Org/mailman/listinfo/devel
