Re: TWM: truetype support

[Eeri Kask]

 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.


Hello Marc,

Now I am slowly turning back to twm, it seems vtwm is in a pretty good
shape considering Xft and SloppyFocus; I only have obligation to do some
final QA work.  We accomplished the following.

(1) We introduced a screen-based 'EnableXftFontRenderer' boolean .vtwmrc
variable to indicate if Xft is to be used on that particular screen.
Otherwise the core font renderer is used.  Then there is an
Xft-availability test on start-up; if this fails, the legacy core fonts
are used on all screens anyway.  So the font rendering infrastructure
(Xft or legacy core fonts) is 'screen-based'; there is no font
technology mixing inside one particular screen.  I implemented this with
the idea from you, introducing the MyWindow data structure (the
corresponding Xft-color I did put into 'ColorPair').  Then we
accidentally detected a bug in MyFont_TextWidth() by me, this function
ignored the 'len' parameter in Xft mode.  Further, it appears
XftDrawCreate() can return a null pointer if some malloc()'ing fails, so
I invented wrapper functions for XftDrawCreate() and XftDrawDestroy();
and if this fail happens (which I consider a very rare occasion), a
warning is printed on stderr and the corresponding XftDrawString()
functions are silently runtime-skipped. (I consider no runtime
null-pointer tests for Xft 'font' pointers necessary as we always leave
GetFont() with a valid Xft 'font' pointer.)

(2) SloppyFocus isn't showing up any bugs since ... some months, so I
can't but consider it finished so far as well.  (We have 'SloppyFocus'
.vtwmrc global boolean variable, and f.sloppyfocus run-time function to
turn this on.  f.focus and f.unfocus turn SloppyFocus off; and
f.sloppyfocus on root window only restores PointerRoot focus mode,
effectively unfocusing the currently-focused client.)


My intensions for twm for the immediate next would be:

(1) Bring the patchsets 1 (MyFont_ChangeGC) ... 6 (SloppyFocus) to the
state they are in vtwm.

(2) Roll back the iconmanager improvements, except the multicolumn width
collapse bug.

(3) Update the man pages.

Then here I would suggest a temporary 'development stop' in order to
fresh start with the icon manager.  For the icon manager I have to
figure out first what I actually want, i.e. how it would make sense to
be most useful (and to be reached with the least effort).  (Maybe it
appears necessary to fix the function executor as well in parallel in
order to fix the icon manager, therefore I think it makes sense to make
a stop here and now.)

Then, later one day if this is completed I tend to think about
minimalistic xinerama support which includes probably only
xinerama-aware new client window positioning and xinerama aware zoom
(e.g., a window is zoomed across these physical screens which the window
already geometrically crosses, or something).

What do you think about all these EWMH extensions?  I have no opinion
today because I am not in a need to have these implemented; it is only
sometimes some people ask for this.


Greetings,

Eeri Kask
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: TWM: truetype support

[Eeri Kask]

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

-bh-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/[EMAIL PROTECTED]/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


  

Re: TWM: truetype support

[Marc Aurele La France]

On Mon, 5 Nov 2007, Eeri Kask wrote:

So, luckily we are now a step closed to the solution:  let's not use
'fixed' as coded-in-default in twm.c if TWM_USE_XFT is defined, but
'-*-fixed-*-*-*-*-*-*-*-*-*-*-*-*', and neither XListFonts() nor
XftFontOpenXlfd() have any further difficulties!  (Is XListFonts()
supposed to translate font alias names at all?)  This looks a good idea,
in fact this is what you suggested first: let XListFonts() resolve
'fixed' and then use it.  Now we know how to do that. :-)



(As a backside, we then remove the flexibility in twm to use the
'fixed'-alias-redirection to an arbitrary font.)



First, the X server does not even start if it cannot resolve 'fixed'.  In
that case, whether or not `twm` starts is a moot point.



Secondly, there are likely to be .twmrc's out there that specify other
aliases, such as '7x13' and so on.  Thus, it is important to fall back to a
raster font when Xft cannot resolve a font name, whether or not that name is
a default.  This makes it unnecessary to change twm's default font names.



The good news is, Xft is hardly going to fail.



One can easily put A quick brown fox jumps over the lazy dog for
TitleFont into .twmrc as an amusing proof.  So if XLFD loading fails, we
will in fact never enter the fallback branch in util.c in GetFont().



But anyways, on our adventurous path to save fixed I'll put up a one
more proposition.   What about the following code fragment at the
beginning for GetFont() in util.c?   Now fixed, variable, 7x13 et
cetera are fine as font names.   :-)



88



void
GetFont(MyFont *font)
{
#ifdef TWM_USE_XFT

   XFontStruct *xlfd;
   Atom  atom;
   char *atom_name;

   if (font-font != NULL) {
XftFontClose (dpy, font-font);
font-font = NULL;
   }

   /* test if core font: */
   xlfd = XLoadQueryFont (dpy, font-name);
   if (xlfd) {
if (XGetFontProperty (xlfd, XA_FONT, atom) == True) {
atom_name = XGetAtomName (dpy, atom);
if (atom_name) {
font-font = XftFontOpenXlfd (dpy, Scr-screen, atom_name);
XFree (atom_name);
}
}
XFreeFont (dpy, xlfd);
   }

   /* next, try Xft font: */
   if (font-font == NULL)
font-font = XftFontOpenName (dpy, Scr-screen, font-name);

   /* fallback: */



   



88


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 */

if (use_fontset) {
char **missing_charset_list_return;
int missing_charset_count_return;
char *def_string_return;
XFontSetExtents *font_extents;
XFontStruct **xfonts;
int i, ascent, descent, fnum;
char *basename2, **font_names;

basename2 = (char *)malloc(strlen(font-name) + 3);
if (basename2) {
sprintf(basename2, %s,*, font-name);
} else
basename2 = font-name;

if( (font-fontset = XCreateFontSet(dpy, basename2,
missing_charset_list_return,
missing_charset_count_return,
def_string_return)) == NULL) {
fprintf (stderr, %s:  unable to open fontset \%s\\n,
 ProgramName, font-name);
exit(1);
}

if (basename2 != font-name)
free(basename2);

for(i=0; imissing_charset_count_return; i++){
printf(%s: warning: font for charset %s is lacking.\n,
   ProgramName, missing_charset_list_return[i]);
}

font_extents = XExtentsOfFontSet(font-fontset);
fnum = XFontsOfFontSet(font-fontset, xfonts, font_names);
for( i = 0, ascent = 0, descent = 0; i  fnum; i++){
if (ascent  (*xfonts)-ascent) ascent = (*xfonts)-ascent;
if (descent  (*xfonts)-descent) descent = (*xfonts)-descent;
xfonts++;
}
font-height = font_extents-max_logical_extent.height;
font-y = ascent;
font-ascent = ascent;
font-descent = descent;
return;
}

if ((font-font = 

Re: TWM: truetype support

[Eeri Kask]

 (1) In iconmgr.c.diff6  at the end is corrected a bug which leads to
 *multicolumn* iconmanager window width gradual collapse under certain
 circumstances while computing 'wwidth'.  I observed this while resizing
 and/or moving the icon manager window and then terminating some client,
 say xcalc.  In that moment the icon manager window gets squeezed
 unexpectedly showing this bug.
 
 I am sure my correction to this problem is not correct, as it only
 undoes something what gets screwed somewhere else (namely, ip-width
 seems to have incorrect value on enrty into PackIconManager()).  I'll
 have to study the problem more closely and then suggest a bugfix.
 
 OK.  I've #if 0'ed it out for now.  Let me know when you're ready.
 
 Marc.


I am making progress.  While finalising XFT-support in cleaning up
memory leaks with the help of your patches I noticed you have missed one
case in leak-cleanup:  the client window title bar.  Here is the
relevant snippet from events.c function HandleDestroyNotify():

if (Tmp_win-title_height)
{
int nb = Scr-TBInfo.nleft + Scr-TBInfo.nright;
XDeleteContext(dpy, Tmp_win-title_w, TwmContext);
XDeleteContext(dpy, Tmp_win-title_w, ScreenContext);
if (Tmp_win-hilite_w)
{
XDeleteContext(dpy, Tmp_win-hilite_w, TwmContext);
XDeleteContext(dpy, Tmp_win-hilite_w, ScreenContext);
}
if (Tmp_win-titlebuttons) {
for (i = 0; i  nb; i++) {
XDeleteContext (dpy, Tmp_win-titlebuttons[i].window,
TwmContext);
XDeleteContext (dpy, Tmp_win-titlebuttons[i].window,
ScreenContext);
}
}
#ifdef TWM_USE_XFT
XftDrawDestroy (Tmp_win-xft_title_w);
#endif
}


So all in all we have three cases for every client window to clean up:

(1) client window title
(2) client window icon caption
(3) client window entry in icon-manager window


In addition to these I learned from your code is the case of destroying
some menus, in particular the 'f.menu TwmWindows' which is apparently
created and destroyed each time on demand.


Currently I am working on the multicolumn icon manager width gradual
collapse problem.  I come to the conclusion this should be an ancient
bug as I encounter various places in code I recognise as attepmts to
work around it.  I suppose the problem is a design error in tracking
the whole icon manager window width as such, and not the width of a
single entry (the whole width can be trivially computed each time when
needed).  Tracking the whole width leads to some unpleasant corner cases
which need to be dealt with care in various places.
I am not done yet, it looks better but I have twm crashes in multiscreen
configurations resulting from this bug (as being only half-fixed by now).

Then I propose replacing mono-10 and sans-10 with

#define DEFAULT_NICE_FONT
-*-helvetica-bold-r-normal-*-*-120-*-*-*-*-iso8859-1
#define DEFAULT_FAST_FONT
-*-fixed-medium-r-normal-*-*-120-*-*-*-*-iso8859-1

in twm.c for the case TWM_USE_XFT and it works great if no fonts are
given in .twmrc.  (I am not sure if size -100- is better for the general
case, as nowadays fixed resolutions 75x75 are not generally used any
more, but significantly higher, as dynamically autodetected from EDID data?)

In few days I'll put my overworked patch set into public, including
nothing new but finalised opacity enhancements I described some time ago.

Greetings,

Eeri Kask
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: TWM: truetype support

[Eeri Kask]

 (I always considered the significantly simpler approach being enough:
 the user in enabling TWM_USE_XFT voluntarily passes the point of no
 return; if xft-font problems arise, then these are to be solved.)
 
 Well, that's the point.  As you have it, the end user does _not_ in fact 
 decide on TWM_USE_XFT.  The distributor does.
 
 Marc.

I not quite sure if this is the essential point in our case who and how
compiles twm, but which fonts are installed and what stands in
system.twmrc for a user not wishing to touch the default,
distributor-provided configuration.

Having not verified, but I strongly suspect if starting the unmodified
twm having first removed the 'misc/' font directory entirely, then X is
not going to find 'fixed', and as of now, twm refuses to start. It
appears, 'fixed' is an alias to something like
'-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1'
according to misc/fonts.alias;  and the key is, this name is XLFD compliant.

So, luckily we are now a step closed to the solution:  let's not use
'fixed' as coded-in-default in twm.c if TWM_USE_XFT is defined, but
'-*-fixed-*-*-*-*-*-*-*-*-*-*-*-*', and neither XListFonts() nor
XftFontOpenXlfd() have any further difficulties!  (Is XListFonts()
supposed to translate font alias names at all?)  This looks a good idea,
in fact this is what you suggested first: let XListFonts() resolve
'fixed' and then use it.  Now we know how to do that. :-)

(As a backside, we then remove the flexibility in twm to use the
'fixed'-alias-redirection to an arbitrary font.)

Greetings,

Eeri Kask

P.S. We could use some better initialisation for 'fixed' as above, maybe
'-*-fixed-medium-r-normal--*-100-*-*-*-*-iso8859-1' or whatever.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: TWM: truetype support

[Marc Aurele La France]

On Wed, 10 Oct 2007, Eeri Kask wrote:

Eeri Kask wrote:

(6) twm-1.0.3-diff6.Fixes.tgz
Here are bugs I encountered in twm as improving icon manager
functionality; some are serious.

Such as?  Please be more descriptive.



(1) In iconmgr.c.diff6  at the end is corrected a bug which leads to
*multicolumn* iconmanager window width gradual collapse under certain
circumstances while computing 'wwidth'.  I observed this while resizing
and/or moving the icon manager window and then terminating some client,
say xcalc.  In that moment the icon manager window gets squeezed
unexpectedly showing this bug.



I am sure my correction to this problem is not correct, as it only
undoes something what gets screwed somewhere else (namely, ip-width
seems to have incorrect value on enrty into PackIconManager()).  I'll
have to study the problem more closely and then suggest a bugfix.


OK.  I've #if 0'ed it out for now.  Let me know when you're ready.

Marc.

+--+--+
|  Marc Aurele La France   |  work:   1-780-492-9310  |
|  Academic Information and|  fax:1-780-492-1729  |
|Communications Technologies   |  email:  [EMAIL PROTECTED] |
|  352 General Services Building   +--+
|  University of Alberta   |  |
|  Edmonton, Alberta   |Standard disclaimers apply|
|  T6G 2H1 |  |
|  CANADA  |  |
+--+--+
XFree86 developer and VP.  ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: TWM: truetype support

[Eeri Kask]

 Oops.  Use this one instead.
 
 Marc.


Thank you very much!
(In the moment I have to finish a conference paper but in few days I'll
be back at twm.)

Actually I only had in mind the part considering the memory leak.  You
have apparently completed a huge work in delaing with fallback to bitmap
raster fonts if some xft font problems arise.  I never wanted to make
this issue that complicated (I never even thought about this
possibility),  :-)   so momentarily I don't yet have any opinion about
reusing your work in full in this regard.
(I always considered the significantly simpler approach being enough:
the user in enabling TWM_USE_XFT voluntarily passes the point of no
return; if xft-font problems arise, then these are to be solved.)

Greetings,

Eeri Kask
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: TWM: truetype support

[Eeri Kask]

Oh, I am happy you take the time to work on twm, big thanks! :-)

 (2) twm-1.0.3-diff2.TWM_USE_XFT.tgz
 introduces Xft support (replaces bitmap text rendering functions with
 xft-font rendering). [Compile with -DTWM_USE_XFT to activate.]
 
 This leaks memory in the form of XftDraw structures that never get released. 
 I've reworked this to fix that problem, and also to re-instate core font 
 support even if TWM_USE_XFT is #define'd.  If a font cannot be found through 
 libXft, it will be looked for through the older standard mechanism.


Oops, I see, I'am very sorry about that!   Now as you say, I'll
understand the problem.  May I kindly ask you to give me your
corrections if you don't mind, as it would be pointless by me to
investigate issues you have already solved (and it would save time).


 (3) twm-1.0.3-diff3.Spacing.tgz
 (Vertical) spacing corrections; having scalable fonts one should use
 scalable spacing as well, otherwise one day having 600x600 dpi screen
 vertical spacing of, e.g. 4 pixels, results in text line distance of
 zero. Now baseline skip is computed like 1.2 times font height or something.
 
 I would prefer that this be done only for Xft fonts, or, better, be made 
 configurable.


I agree and I'll put these changes inside #ifdef TWM_USE_XFT as well.
Configurable ... in what sense?  Using some compile-time #define?  If
you prefer this, I'll do it that way.


 (4) twm-1.0.3-diff4.TWM_USE_OPACITY.tgz
 If you value transparency in twm menus and icon manger/icons, apply
 this. This patchset introduces MenuOpacity and IconOpacity keywords
 having integer values in range 0...255. [Enable with -DTWM_USE_OPACITY]
 
 As stated previously, this will not be integrated as it relies on 
 X.Org-specific functionality.


I have thought about your standpoint here.  This may be Xorg
functionality, but if twm is run to manage the Xorg server, this
functionality will be available to twm, regardless which X11
implementation/distribution twm belongs to.  So I'd suggest this
functionality be available as twm patch, and its everyone's own decision
to include/apply it ... or not.  (I have all respect in your preference
not to do this if you so like.)

(I am even considering to very slightly enlarge opacity support in the
sense that twm should intercept these opacity property change requests
from client windows and propagate them to self-created frame-windows of
these top-level clients.  The user is responsible to run xcompmgr in the
backround, twm will not be dealing with transparency in any other way.
This increases opacity code in twm maybe about ten lines or so in
HandlePropertyNotify() in events.c.  So if some client asks for
transparency, twm wouldn't stand in the way.)



 (5) twm-1.0.3-diff5.Appearance.tgz
 Here lies probably the most radical change I have made to twm: the
 iconmanager painting DrawIconManagerBorder() is now
 DrawIconManagerEntry() and draws the iconmanager entry in full. This
 work is not completed yet.
 
 I'm inclined to delay this one until it is complete.

If you didn't, I would have asked you to do this.  :-)


 (6) twm-1.0.3-diff6.Fixes.tgz
 Here are bugs I encountered in twm as improving icon manager
 functionality; some are serious.
 
 Such as?  Please be more descriptive.


(1) In iconmgr.c.diff6  at the end is corrected a bug which leads to
*multicolumn* iconmanager window width gradual collapse under certain
circumstances while computing 'wwidth'.  I observed this while resizing
and/or moving the icon manager window and then terminating some client,
say xcalc.  In that moment the icon manager window gets squeezed
unexpectedly showing this bug.

Other 'fixes' in this diff somehow clarify the MoveIconManager() (which
is the second most heavily modified  function next to
DrawIconManagerEntry()), with the purpose of returning a mapped (not
iconified or unmapped) client window if the icon manager window is *not*
mapped.  I noticed that f.forwiconmgr gets stuck on some
unmapped/iconified window if the icon manager is not mapped as well,
leaving the mouse sporadically somewhere on the root window (exactly
there, where the iconified client window would appear if it where mapped
-- and if this falls inside some other mapped window, the f.forwiconmgr
cycling starts from this client again; a kind of sub-cycling emerges).

So in the end one can step along *all* windows if the icon manager is
mapped, and only along *mapped* windows if the icon manager is not
mapped.  This was my intended solution to the mouse getting lost problem.


(2) In events.c.diff6 in HandleEnterNotify() I discovered a situation
where entering the root window (one can enter the root window in leaving
some client window on the same screen; and in leaving some other screen)
while coming from some other screen and then --- being on the screen
just entered NotActiveIconManager() gets called with the UnHighLight_win
client window data structure on the screen just left in order to paint
the iconmanager entry on that 

Re: TWM: truetype support

[Eeri Kask]

Eeri Kask wrote:
 (6) twm-1.0.3-diff6.Fixes.tgz
 Here are bugs I encountered in twm as improving icon manager
 functionality; some are serious.
 Such as?  Please be more descriptive.
 
 (1) In iconmgr.c.diff6  at the end is corrected a bug which leads to
 *multicolumn* iconmanager window width gradual collapse under certain
 circumstances while computing 'wwidth'.  I observed this while resizing
 and/or moving the icon manager window and then terminating some client,
 say xcalc.  In that moment the icon manager window gets squeezed
 unexpectedly showing this bug.


I am sure my correction to this problem is not correct, as it only
undoes something what gets screwed somewhere else (namely, ip-width
seems to have incorrect value on enrty into PackIconManager()).  I'll
have to study the problem more closely and then suggest a bugfix.

Greetings,

Eeri Kask
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: TWM: truetype support

[Marc Aurele La France]

On Wed, 10 Oct 2007, Eeri Kask wrote:

(2) twm-1.0.3-diff2.TWM_USE_XFT.tgz
introduces Xft support (replaces bitmap text rendering functions with
xft-font rendering). [Compile with -DTWM_USE_XFT to activate.]



This leaks memory in the form of XftDraw structures that never get released.
I've reworked this to fix that problem, and also to re-instate core font
support even if TWM_USE_XFT is #define'd.  If a font cannot be found through
libXft, it will be looked for through the older standard mechanism.



Oops, I see, I'am very sorry about that!   Now as you say, I'll
understand the problem.  May I kindly ask you to give me your
corrections if you don't mind, as it would be pointless by me to
investigate issues you have already solved (and it would save time).


I'm attaching a context diff of what I've done on this so far.  It is 
against our main CVS repository as it stands now.  Note that, as of this 
writting, our publicly accessible repository mirror has yet to be sync'ed 
(but it should be sometime today).


This includes (among other odds  ends):
- your first change (MyFont_ChangeGC);
- my rework of your second change (TWM_USE_XFT);
- two non-spacing changes I found in your third batch (Spacing);
- the XSetClassHint() and DefaultFont changes from your fifth batch
  (Appearance);
- your seventh change (Improvements).

This is not yet ready to commit.


(3) twm-1.0.3-diff3.Spacing.tgz
(Vertical) spacing corrections; having scalable fonts one should use
scalable spacing as well, otherwise one day having 600x600 dpi screen
vertical spacing of, e.g. 4 pixels, results in text line distance of
zero. Now baseline skip is computed like 1.2 times font height or something.



I would prefer that this be done only for Xft fonts, or, better, be made
configurable.



I agree and I'll put these changes inside #ifdef TWM_USE_XFT as well.
Configurable ... in what sense?  Using some compile-time #define?  If
you prefer this, I'll do it that way.


By configurable, I meant through .twmrc.  But this might be more trouble 
than it's worth.  So, I'd settle on adjusting spacing only for Xft fonts.



(4) twm-1.0.3-diff4.TWM_USE_OPACITY.tgz
If you value transparency in twm menus and icon manger/icons, apply
this. This patchset introduces MenuOpacity and IconOpacity keywords
having integer values in range 0...255. [Enable with -DTWM_USE_OPACITY]


As stated previously, this will not be integrated as it relies on
X.Org-specific functionality.



I have thought about your standpoint here.  This may be Xorg
functionality, but if twm is run to manage the Xorg server, this
functionality will be available to twm, regardless which X11
implementation/distribution twm belongs to.  So I'd suggest this
functionality be available as twm patch, and its everyone's own decision
to include/apply it ... or not.  (I have all respect in your preference
not to do this if you so like.)



(I am even considering to very slightly enlarge opacity support in the
sense that twm should intercept these opacity property change requests
from client windows and propagate them to self-created frame-windows of
these top-level clients.  The user is responsible to run xcompmgr in the
backround, twm will not be dealing with transparency in any other way.
This increases opacity code in twm maybe about ten lines or so in
HandlePropertyNotify() in events.c.  So if some client asks for
transparency, twm wouldn't stand in the way.)


I doubt very much anyone would ever use XFree86's twm with X.Org's 
xcompmgr.  But I understand your point.



(5) twm-1.0.3-diff5.Appearance.tgz
Here lies probably the most radical change I have made to twm: the
iconmanager painting DrawIconManagerBorder() is now
DrawIconManagerEntry() and draws the iconmanager entry in full. This
work is not completed yet.



I'm inclined to delay this one until it is complete.



If you didn't, I would have asked you to do this.  :-)


OK.  Let me know when it's ready.


(6) twm-1.0.3-diff6.Fixes.tgz
Here are bugs I encountered in twm as improving icon manager
functionality; some are serious.



Such as?  Please be more descriptive.



(1) In iconmgr.c.diff6  at the end is corrected a bug which leads to
*multicolumn* iconmanager window width gradual collapse under certain
circumstances while computing 'wwidth'.  I observed this while resizing
and/or moving the icon manager window and then terminating some client,
say xcalc.  In that moment the icon manager window gets squeezed
unexpectedly showing this bug.



Other 'fixes' in this diff somehow clarify the MoveIconManager() (which
is the second most heavily modified  function next to
DrawIconManagerEntry()), with the purpose of returning a mapped (not
iconified or unmapped) client window if the icon manager window is *not*
mapped.  I noticed that f.forwiconmgr gets stuck on some
unmapped/iconified window if the icon manager is not mapped as well,
leaving the mouse sporadically somewhere on the root window (exactly
there, where the iconified client 

Re: TWM: truetype support

[Marc Aurele La France]

On Wed, 10 Oct 2007, Eeri Kask wrote:

Eeri Kask wrote:

(6) twm-1.0.3-diff6.Fixes.tgz
Here are bugs I encountered in twm as improving icon manager
functionality; some are serious.



Such as?  Please be more descriptive.



(1) In iconmgr.c.diff6  at the end is corrected a bug which leads to
*multicolumn* iconmanager window width gradual collapse under certain
circumstances while computing 'wwidth'.  I observed this while resizing
and/or moving the icon manager window and then terminating some client,
say xcalc.  In that moment the icon manager window gets squeezed
unexpectedly showing this bug.



I am sure my correction to this problem is not correct, as it only
undoes something what gets screwed somewhere else (namely, ip-width
seems to have incorrect value on enrty into PackIconManager()).  I'll
have to study the problem more closely and then suggest a bugfix.


OK.  Thanks for letting me know.

Marc.

+--+--+
|  Marc Aurele La France   |  work:   1-780-492-9310  |
|  Academic Information and|  fax:1-780-492-1729  |
|Communications Technologies   |  email:  [EMAIL PROTECTED] |
|  352 General Services Building   +--+
|  University of Alberta   |  |
|  Edmonton, Alberta   |Standard disclaimers apply|
|  T6G 2H1 |  |
|  CANADA  |  |
+--+--+
XFree86 developer and VP.  ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: TWM: truetype support

[Marc Aurele La France]

On Wed, 10 Oct 2007, Marc Aurele La France wrote:
I'm attaching a context diff of what I've done on this so far.  It is against 
our main CVS repository as it stands now.  Note that, as of this writting, 
our publicly accessible repository mirror has yet to be sync'ed (but it 
should be sometime today).



This includes (among other odds  ends):
- your first change (MyFont_ChangeGC);
- my rework of your second change (TWM_USE_XFT);
- two non-spacing changes I found in your third batch (Spacing);
- the XSetClassHint() and DefaultFont changes from your fifth batch
 (Appearance);
- your seventh change (Improvements).



This is not yet ready to commit.


Oops.  Use this one instead.

Marc.

+--+--+
|  Marc Aurele La France   |  work:   1-780-492-9310  |
|  Academic Information and|  fax:1-780-492-1729  |
|Communications Technologies   |  email:  [EMAIL PROTECTED] |
|  352 General Services Building   +--+
|  University of Alberta   |  |
|  Edmonton, Alberta   |Standard disclaimers apply|
|  T6G 2H1 |  |
|  CANADA  |  |
+--+--+
XFree86 developer and VP.  ATI driver and X server internals.

cvs-devel.diff.gz
Description: Binary data

Re: TWM: truetype support

[Marc Aurele La France]

On Mon, 1 Oct 2007, Eeri Kask wrote:


Here are patchsets (against Xorg twm release 1.0.3) completing and
polishing Xft support for twm (and improving the icon manager):



(1) twm-1.0.3-diff1.MyFont_ChangeGC.tgz
to my knowing has not changed from last time: cleans up bitmap font drawing.


OK.


(2) twm-1.0.3-diff2.TWM_USE_XFT.tgz
introduces Xft support (replaces bitmap text rendering functions with
xft-font rendering). [Compile with -DTWM_USE_XFT to activate.]


This leaks memory in the form of XftDraw structures that never get released. 
I've reworked this to fix that problem, and also to re-instate core font 
support even if TWM_USE_XFT is #define'd.  If a font cannot be found through 
libXft, it will be looked for through the older standard mechanism.



(3) twm-1.0.3-diff3.Spacing.tgz
(Vertical) spacing corrections; having scalable fonts one should use
scalable spacing as well, otherwise one day having 600x600 dpi screen
vertical spacing of, e.g. 4 pixels, results in text line distance of
zero. Now baseline skip is computed like 1.2 times font height or something.


I would prefer that this be done only for Xft fonts, or, better, be made 
configurable.



Maybe here some spacing corrections need to be done as some ttf-fonts
may include bad metrics. I have mostly tested with bitstream vera
fonts.  (E.g. Apple's Lucida Grande looks vertically definitely too tight.)


I don't believe fonts with bad metrics should be dealt with in twm.


(4) twm-1.0.3-diff4.TWM_USE_OPACITY.tgz
If you value transparency in twm menus and icon manger/icons, apply
this. This patchset introduces MenuOpacity and IconOpacity keywords
having integer values in range 0...255. [Enable with -DTWM_USE_OPACITY]


As stated previously, this will not be integrated as it relies on 
X.Org-specific functionality.



(5) twm-1.0.3-diff5.Appearance.tgz
Here lies probably the most radical change I have made to twm: the
iconmanager painting DrawIconManagerBorder() is now
DrawIconManagerEntry() and draws the iconmanager entry in full. This
work is not completed yet.


I'm inclined to delay this one until it is complete.


This patchset introduces DefaultFont
keyword. The default font was up to now like some orphan parameter not
configurable by the user and in the same time used prominently in
rendering InfoWindow/SizeWindow text. (Letting it be fixed as in
bitmap rendering would cause twm become non-usable in whole as
XftFontOpenXlfd() (at least the installed library I have to use) is not
able to load that font, so something needed to be done anyway. Lacking
any better idea now by default DefaultFont is set to mono-10 if XFT is
compiled in.)


My rework of your second change fixes this.


(6) twm-1.0.3-diff6.Fixes.tgz
Here are bugs I encountered in twm as improving icon manager
functionality; some are serious.


Such as?  Please be more descriptive.


(7) twm-1.0.3-diff7.Improvements.tgz
Here are some improvements to the icon manager. The old behaviour is
kept as long as WarpCursor is not defined: actually the meaning of
this variable is broadened in the sense that everywhere where warping
mouse makes sense, this is done:



(*) if some client window has focus and this client opens a transient
window, then mouse is transfered there; like in password prompt and
file-open dialogs (this is a valuable idea from vtwm);



(*) if iconifying some client window and the icon manager is currently
mapped, the mouse is transfered into the corresponding icon manager entry;



(*) if executing f.hideiconmgr transfer mouse into the corresponding
client if some iconmanager entry was active.



(*) iconmanager navigation functions raise the corresponding client
windows as stepping around entries.


OK, except that, as you currently have it coded, that last one does not 
depend on WarpCursor.  Is that intentional?



P.P.S. How to put TWM_USE_XFT, TWM_USE_OPACITY into autoconfig or Imake
if you are interested please kindly help as not coming from software
development it is a little complicated. (Few weeks ago I only learned
how to use 'diff'.)  :-)


The automangle suite isn't a concern here, and my integration of these 
changes, as it currently stands, already takes care of imake.


Marc.

+--+--+
|  Marc Aurele La France   |  work:   1-780-492-9310  |
|  Academic Information and|  fax:1-780-492-1729  |
|Communications Technologies   |  email:  [EMAIL PROTECTED] |
|  352 General Services Building   +--+
|  University of Alberta   |  |
|  Edmonton, Alberta   |Standard disclaimers apply|
|  T6G 2H1 |  |
|  CANADA  |  |
+--+--+
XFree86 developer and VP.  ATI driver and X server internals.

Re: TWM: truetype support

[Marc Aurele La France]

On Mon, 1 Oct 2007, Eeri Kask wrote:


Marc Aurele La France:

The point of using XListFonts() is that it'll resolve fixed  variable
to their respective XLFDs which can then be passed to XftFontOpenXlfd().



I have installed Xorg 7.2.0 release and here XListFonts() returns
fixed if called with fixed, which XftFontOpenXlfd() unfortunately
cannot load.  Maybe this is a bug in XftFontOpenXlfd() or in
XListFonts(), it actually doesn't matter;  but as long as it is so
coding fixed as a default (at least for 7.2.0) is very inconvenient
for the end user (as there is as is no DefaultFont keyword to change the
default font), in fact resulting in twm being unusable.



Some possible solutions: (1) agree on a different than fixed font
which XftFontOpenXlfd() in all X11-implementations can definitely load;
(2) let mono-10 or some other ttf-font be the default if XFT is
compiled in.  (1) makes not that much sense in the case one has to drop
fixed anyway.


There is a third option:  change TWM_USE_XFT to TWM_ALLOW_XFT and make the 
use of libXft configurable (default to no), instead of forcing it.


Marc.

+--+--+
|  Marc Aurele La France   |  work:   1-780-492-9310  |
|  Academic Information and|  fax:1-780-492-1729  |
|Communications Technologies   |  email:  [EMAIL PROTECTED] |
|  352 General Services Building   +--+
|  University of Alberta   |  |
|  Edmonton, Alberta   |Standard disclaimers apply|
|  T6G 2H1 |  |
|  CANADA  |  |
+--+--+
XFree86 developer and VP.  ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: TWM: truetype support

[Eeri Kask]

Marc Aurele La France:
 The point of using XListFonts() is that it'll resolve fixed  variable 
 to their respective XLFDs which can then be passed to XftFontOpenXlfd().

I have installed Xorg 7.2.0 release and here XListFonts() returns
fixed if called with fixed, which XftFontOpenXlfd() unfortunately
cannot load.  Maybe this is a bug in XftFontOpenXlfd() or in
XListFonts(), it actually doesn't matter;  but as long as it is so
coding fixed as a default (at least for 7.2.0) is very inconvenient
for the end user (as there is as is no DefaultFont keyword to change the
default font), in fact resulting in twm being unusable.

Some possible solutions: (1) agree on a different than fixed font
which XftFontOpenXlfd() in all X11-implementations can definitely load;
(2) let mono-10 or some other ttf-font be the default if XFT is
compiled in.  (1) makes not that much sense in the case one has to drop
fixed anyway.

(Regarding other aspects in XFT-font loading code I followed your
suggestions.)

Greetings,

Eeri Kask
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: TWM: truetype support

[Eeri Kask]

Eeri Kask wrote:
 This means, any performance degrading or huge memory footprint you are
 going to observe from now on will hopefully reveal problems only in the
 xft-subsystem and not in twm.

Xft has disclosed probably a very old bug in twm!  :-)
(Drawing with a current screen GC onto a 'noncurrent' screen.)


Here are patchsets (against Xorg twm release 1.0.3) completing and
polishing Xft support for twm (and improving the icon manager):


(1) twm-1.0.3-diff1.MyFont_ChangeGC.tgz
to my knowing has not changed from last time: cleans up bitmap font drawing.


(2) twm-1.0.3-diff2.TWM_USE_XFT.tgz
introduces Xft support (replaces bitmap text rendering functions with
xft-font rendering). [Compile with -DTWM_USE_XFT to activate.]


(3) twm-1.0.3-diff3.Spacing.tgz
(Vertical) spacing corrections; having scalable fonts one should use
scalable spacing as well, otherwise one day having 600x600 dpi screen
vertical spacing of, e.g. 4 pixels, results in text line distance of
zero. Now baseline skip is computed like 1.2 times font height or something.

Maybe here some spacing corrections need to be done as some ttf-fonts
may include bad metrics. I have mostly tested with bitstream vera
fonts.  (E.g. Apple's Lucida Grande looks vertically definitely too tight.)


(4) twm-1.0.3-diff4.TWM_USE_OPACITY.tgz
If you value transparency in twm menus and icon manger/icons, apply
this. This patchset introduces MenuOpacity and IconOpacity keywords
having integer values in range 0...255. [Enable with -DTWM_USE_OPACITY]


(5) twm-1.0.3-diff5.Appearance.tgz
Here lies probably the most radical change I have made to twm: the
iconmanager painting DrawIconManagerBorder() is now
DrawIconManagerEntry() and draws the iconmanager entry in full. This
work is not completed yet. This patchset introduces DefaultFont
keyword. The default font was up to now like some orphan parameter not
configurable by the user and in the same time used prominently in
rendering InfoWindow/SizeWindow text. (Letting it be fixed as in
bitmap rendering would cause twm become non-usable in whole as
XftFontOpenXlfd() (at least the installed library I have to use) is not
able to load that font, so something needed to be done anyway. Lacking
any better idea now by default DefaultFont is set to mono-10 if XFT is
compiled in.)


(6) twm-1.0.3-diff6.Fixes.tgz
Here are bugs I encountered in twm as improving icon manager
functionality; some are serious.


(7) twm-1.0.3-diff7.Improvements.tgz
Here are some improvements to the icon manager. The old behaviour is
kept as long as WarpCursor is not defined: actually the meaning of
this variable is broadened in the sense that everywhere where warping
mouse makes sense, this is done:

(*) if some client window has focus and this client opens a transient
window, then mouse is transfered there; like in password prompt and
file-open dialogs (this is a valuable idea from vtwm);

(*) if iconifying some client window and the icon manager is currently
mapped, the mouse is transfered into the corresponding icon manager entry;

(*) if executing f.hideiconmgr transfer mouse into the corresponding
client if some iconmanager entry was active.

(*) iconmanager navigation functions raise the corresponding client
windows as stepping around entries.


These are the most important modifications I feeled necessary to turn
the icon manager --- mostly by popping it on and off on demand --- into
a useful tool for keyboard-driven focus and mouse navigation along
client windows. Please let me know if you have problems, differing
preferences or further good ideas regarding this.

As further work the icon manager has few bugs remaining I have observed
but not yet investigated (some occurring in multiscreen environments).

How it now looks like you can see at

www.inf.tu-dresden.de/~ek1/TheGIMP-iconmgr-screenshot.png

(Btw. menutitle is painted with titlebar font (as a menu-title-bar), not
included in the patches. There are some font height issues to be decided
regarding this in order to make it 'failsafe'.)


Greetings, and have fun,

Eeri Kask

P.S. If you don't mind tweaking in these patches, then please help test
diff7, diff6 and diff5 first. :-)  I'll consider diff1...diff4 finished
if no bugs (and needed spacing corrections) become apparent.

P.P.S. How to put TWM_USE_XFT, TWM_USE_OPACITY into autoconfig or Imake
if you are interested please kindly help as not coming from software
development it is a little complicated. (Few weeks ago I only learned
how to use 'diff'.)  :-)



twm-1.0.3-diff1.MyFont_ChangeGC.tgz
Description: application/compressed-tar


twm-1.0.3-diff2.TWM_USE_XFT.tgz
Description: application/compressed-tar


twm-1.0.3-diff3.Spacing.tgz
Description: application/compressed-tar


twm-1.0.3-diff4.TWM_USE_OPACITY.tgz
Description: application/compressed-tar


twm-1.0.3-diff5.Appearance.tgz
Description: application/compressed-tar


twm-1.0.3-diff6.Fixes.tgz
Description: application/compressed-tar


twm-1.0.3-diff7.Improvements.tgz

Re: TWM: truetype support

[Eeri Kask]

As quick answer, I'd take two good ideas from you suggestion instantly:

(1) Use XListFonts() instead of XLoadQueryFont() to test if a font is
available;

(2) Use DefaultFont as a first fallback if requested font could not be
loaded. (I don't know if it makes sense to give a stderr warning that
the requested font could not be found and a replacement was needed?)


Regarding the issue of fixed/variable -- mono-10/sans-10  I'd
suggest to find out how XftFontOpenXlfd() is per definition _supposed_
to work if called with fixed or variable.  Now my installed Xft
library crashes twm in whole;  but irrespective to that, if
XftFontOpenXlfd() is supposed or is free to choose a random replacement
(as not being able to load fixed for example), then initialising to
mono-10 instead of fixed makes sense as the outcome to the user is
kind of more deterministic.  This is a matter of opinion/taste, and in
the end a minor issue.


 void
 GetFont(font)
 MyFont *font;
 {
 #ifdef TWM_USE_XFT
 
  char **fontlist;
  int listcount;
 
  if (font-font != NULL)
   XftFontClose(dpy, font-font);


GetFont() is only called on screen initialisation in CreateFonts() and
the font-font variable is priorly initialised to NULL; this is
guaranteed.  So the 'if' test here --- if passing --- would hide some
programming error somewhere else, if I am correct...  :-)

Greetings,

Eeri Kask
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: TWM: truetype support

[Marc Aurele La France]

On Fri, 28 Sep 2007, Eeri Kask wrote:


As quick answer, I'd take two good ideas from you suggestion instantly:



(1) Use XListFonts() instead of XLoadQueryFont() to test if a font is
available;


No.  It is to test if it is a core font.


(2) Use DefaultFont as a first fallback if requested font could not be
loaded. (I don't know if it makes sense to give a stderr warning that
the requested font could not be found and a replacement was needed?)


The !defined(TWM_USE_XFT) case doesn't.  Both cases should be consistent.


Regarding the issue of fixed/variable -- mono-10/sans-10  I'd
suggest to find out how XftFontOpenXlfd() is per definition _supposed_
to work if called with fixed or variable.  Now my installed Xft
library crashes twm in whole;  but irrespective to that, if
XftFontOpenXlfd() is supposed or is free to choose a random replacement
(as not being able to load fixed for example), then initialising to
mono-10 instead of fixed makes sense as the outcome to the user is
kind of more deterministic.  This is a matter of opinion/taste, and in
the end a minor issue.


The point of using XListFonts() is that it'll resolve fixed  variable 
to their respective XLFDs which can then be passed to XftFontOpenXlfd().



void
GetFont(font)
MyFont *font;
{
#ifdef TWM_USE_XFT

 char **fontlist;
 int listcount;

 if (font-font != NULL)
XftFontClose(dpy, font-font);



GetFont() is only called on screen initialisation in CreateFonts() and
the font-font variable is priorly initialised to NULL; this is
guaranteed.  So the 'if' test here --- if passing --- would hide some
programming error somewhere else, if I am correct...  :-)


Again, look at the !defined(TWM_USE_XFT) code.

Marc.

+--+--+
|  Marc Aurele La France   |  work:   1-780-492-9310  |
|  Academic Information and|  fax:1-780-492-1729  |
|Communications Technologies   |  email:  [EMAIL PROTECTED] |
|  352 General Services Building   +--+
|  University of Alberta   |  |
|  Edmonton, Alberta   |Standard disclaimers apply|
|  T6G 2H1 |  |
|  CANADA  |  |
+--+--+
XFree86 developer and VP.  ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: TWM: truetype support

[Eeri Kask]

Marc Aurele La France wrote:
xcompmgr -c -o 0.5 -r 6 -t -6 -l -9  
 
 in the background, this has no effect on anything.
 
 I found two keywords the only solution as menus and icons have too
 different transparency values in order to configure them with one
 keyword.  I have  MenuOpacity 245 and IconOpacity 200 in .twmrc.
 
 This one is X.Org-specific as it relies on an extension not provided by
 XFree86.

It makes sense if I extract the iconmanager window entry drawing from
(4)-Appearance patchset and move it to (6)-Improvements; then swap
(4) and (3)-Opacity, so patches (1)...(3) replace bitmap font
rendering with xft including all vertical spacing changes, and these
improvements can be treated as a whole.   So I'll do that.


 [] Concerning xft I believe having read Keith Packard
 sans, serif and mono should be expected included in every xft
 installation, so I chose sans-10 and mono-10 as a replacement for
 variable and fixed in twm.c.
 This is the story to that decision. :-)

 This can be remedied with the use of XListFonts().

 Marc.


I don't quite catch your suggestion, please help, be more specific. :-)


It seems XftFontOpenName() is quite robust, even if I give it '\0'
character as a font name, it returns a quite good replacement.  So the
easiest way would be to rely on the smartness of XftFontOpenName()?

(In fact, I suspect we will never know for sure if our requested font is
really what we get out of XftFontOpenName() in the end, so maybe it
doesn't make much sense to do lots of work in formulating the
fallback/default replacement request?)

Greetings,

Eeri Kask
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: TWM: truetype support

[Eeri Kask]

Marc Aurele La France wrote:
 On Tue, 18 Sep 2007, Eeri Kask wrote:
 []
 So compile with  -DTWM_USE_XFT  -I/usr/include/freetype2  -lXft
 
 Then insert
 
 TitleFontsans-9
 MenuFontsans-9
 IconFontsans-9:bold
 IconManagerFontsans-9
 ResizeFontsans-10:bold
 
 If you are a twm user, please test it; what do you think? :-)
 
 I have refit this to our current source.  However, I don't think the
 default fonts `twm` uses should be changed as doing so will surprise
 many users.  It appears that restoring the previous defaults would only
 require additional changes to InitVariables() in twm.c and GetFont() in
 util.c.
 
 Comments?
 
 Marc.


Wait, please, don't commit yet!  :-)

In the meanwile I have done some minor cosmetic improvements to the Xft
inclusion and now I am in two days ready to release these (I renamed two
macros, as being no english native speaker these looked stupid in the
first iteration).  That is, I am in fact right now ready to release
these improvements, but additionally I have done some one-liner
corrections to text spacing everywhere in rendering as well, so that all
menu items, icon captions, iconmanager window label texts and so on look
considerably better spaced.  In the sense, that vertical spacing now
goes proportionally to the font height and not by a fixed amount like
font height plus 4 pixels etc. (but 1.2 times font height, and the
like).  It really goes hand in hand with using scalable fonts: one also
has to have scalable spacing as well!  :-)

These improvements are indeed finished too.


Two days I want to spend on completeing a small focus tweak: if and only
if some client window has focus and this client opens a transient window
(like thunderbird password prompt, or some file-open dialogue), then the
mouse should be warped into that window.  I am thinking how to do this
best using as much existing twm code and functionality as possible; and
it also remains to decide if it makes sense to invent a new keyword like
WarpToTransients as in vtwm to that purpose, to retain old behaviour
if the user so wishes.

Then I also found a serious bug and fixed a multicolumn iconmanager
geometry problem (in Xorg 1.0.3 twm release):  if mapped and one moves
that iconmanager window then its width gets corrupted during next
packing.  It was a small thinking error in PackIconManager() in
iconmgr.c while computing wwidth, it should/could be something like

wwidth = (ip-first ? (ip-first-width  0 ? ip-first-width :
ip-width/ip-columns) : 150);


These above improvements are unrelated to xft-support in twm though.


So actually I didn't quite understand you what do you mean by preserving
default fonts twm uses?  Currently twm uses fixed and variable in
twm.c as default fonts if no fonts are specified in .twmrc.   Next, if
some font failed to load, then fixed is (unrelated to InitVariables()
in twm.c) tried in util.c as a fallback.  So by the way, the DefaultFont
as initialised in twm.c is actually never used as a fallback, this font
is used only to render infowindow text!  (It should be called InfoFont
instead, but let it be DefaultFont as it is; we have DefaultForeground
and DefaultBackground as colours as well and nobody actually knows for
what purpose: to draw size- and infowindows.)  Much more important is
that one can specify DefaultFont in .twmrc which needs to be fixed (and
already is :-).

I am afraid we need to change fixed and variable in twm.c if Xft is
included because xft-subsystem crashes (at least mine) if one uses these
in XftFontOpenXlfd(), probably because these names are not
XLFD-compliant. (xft should not crash because of that, but it is xft's
problem, not ours.)  So as long as default font names (or user-specified
font names in .twmrc) are xlfd-conform one can use these as usual, in
that regard nothing has changed.  If I am correct the choice of fixed
as a default font is always justified by the fact that this font is
guaranteed present in every X11 installation and so it is a very
reasonable decision.  Concerning xft I believe having read Keith Packard
sans, serif and mono should be expected included in every xft
installation, so I chose sans-10 and mono-10 as a replacement for
variable and fixed in twm.c.
This is the story to that decision. :-)

Greetings,

Eeri Kask
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: TWM: truetype support

[Eeri Kask]

Eeri Kask wrote:
 Wait, please, don't commit yet!  :-)
 []

Here are my current twm improvement patches, organised thematically:

(1) Preparatory font rendering cleanup (should have no changes compared
to last time).


(2) Xft-support for twm, besides macro renaming the main improvement is:
 use_fontset is back again, now meaning to use XftDrawStringUtf8()
instead of XftDrawString8() if locale is set.
(What it effectively means I don't know as I don't have anybody using
twm in Chinese or Japanese, so if someone can try it out and explain me
the difference, I'd be happy!)  :-)


(3) Introduces twm menu and iconmanager (and icon) transparency,
introducing two keywords:  MenuOpacity, IconOpacity (in range 0 =
transparent ... 255 = opaque).  Effectively it will be compiled in only
if set '#define TWM_USE_OPACITY'.  It adds no complexity to twm as it
only sets the window opacity property and as long you don't run
something like

xcompmgr -c -o 0.5 -r 6 -t -6 -l -9  

in the background, this has no effect on anything.

I found two keywords the only solution as menus and icons have too
different transparency values in order to configure them with one
keyword.  I have  MenuOpacity 245 and IconOpacity 200 in .twmrc.


(4) Xft-related apperance fixes: all fixed-pixel-height based spacing
computations are converted to scalable, font height-dependent spacing
computations.  These are effectively one-line improvements which don't
(should not) have side effects.

Here is one exception though -- iconmanager window entry layout.
Previously iconmanager was highlighted by calling
DrawIconManagerBorder(). This function now draws the whole iconmanager
window label entry, and I renamed it therefore to
DrawIconManagerEntry().  This is the most radical change I have made to
twm and it is not that fully tested (in regard to bugs and side effects
which may arise).
So in case of problems let this function be as it was; and then don't
remove MyFont_DrawString() at the end of HandleExpose() in events.c as
well.  This issue should affect no other places.

I only was trying to streamline iconmanager and twm menu appearance, I
was in opinion they should look somewhat similar.  Or alternatively I'll
try to optimise iconmanager to having only one row (not one column) with
text in huge letters, like as if one had

IconManagerFont sans-13:bold
IconManagerGeometry =1500x10+200-300 10
IconManagerForeground   white
IconManagerBackground   grey15
IconManagerHighlightgrey65
IconForeground  white
IconBackground  grey15
IconBorderColor black


in .twmrc.

As apparent, iconmanager appearance is not completed and I am more than
eager to discuss what you are thinking.

This patchset (4) introduces DefaultFont keyword as it is critical to
have all appearance parameters configurable from the outside and this
font is used prominently in InfoWindow text rendering.


Having that done I personally find twm regarding its appearance finished
for now for me;  and I'll continue working in my spare time in tracing
bugs and put some focus and iconmanager control/usability tweaks into
it, to make twm fully keyboard-usable in regard to present day GUI
applications.


(5) Fixes patchset is where I'll try to gather bugs/fixes as I'll find
them and find fixes.

(6) Then there is an Improvements patchset which is currently empty,
but should include experiments with new, selected features. (In the
sense of improving twm current usability, and not introducing completely
new functionality. :-)


Probably (1)...(4) can be made stable and completed quickly;  I consider
(1)...(3) finished myself if they only prove to being bugfree.


Greetings,

Eeri Kask



twm-1.0.3-diff1.MyFont_ChangeGC.tgz
Description: application/compressed-tar


twm-1.0.3-diff2.TWM_USE_XFT.tgz
Description: application/compressed-tar


twm-1.0.3-diff3.TWM_USE_OPACITY.tgz
Description: application/compressed-tar


twm-1.0.3-diff4.Appearance.tgz
Description: application/compressed-tar


twm-1.0.3-diff5.Fixes.tgz
Description: application/compressed-tar

Re: TWM: truetype support

[Marc Aurele La France]

On Wed, 26 Sep 2007, Eeri Kask wrote:

Eeri Kask wrote:

Wait, please, don't commit yet!  :-)



Here are my current twm improvement patches, organised thematically:


[...]


(3) Introduces twm menu and iconmanager (and icon) transparency,
introducing two keywords:  MenuOpacity, IconOpacity (in range 0 =
transparent ... 255 = opaque).  Effectively it will be compiled in only
if set '#define TWM_USE_OPACITY'.  It adds no complexity to twm as it
only sets the window opacity property and as long you don't run
something like



   xcompmgr -c -o 0.5 -r 6 -t -6 -l -9  



in the background, this has no effect on anything.



I found two keywords the only solution as menus and icons have too
different transparency values in order to configure them with one
keyword.  I have  MenuOpacity 245 and IconOpacity 200 in .twmrc.


This one is X.Org-specific as it relies on an extension not provided by 
XFree86.


Marc.

+--+--+
|  Marc Aurele La France   |  work:   1-780-492-9310  |
|  Academic Information and|  fax:1-780-492-1729  |
|Communications Technologies   |  email:  [EMAIL PROTECTED] |
|  352 General Services Building   +--+
|  University of Alberta   |  |
|  Edmonton, Alberta   |Standard disclaimers apply|
|  T6G 2H1 |  |
|  CANADA  |  |
+--+--+
XFree86 developer and VP.  ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: TWM: truetype support

[Marc Aurele La France]

On Wed, 26 Sep 2007, Eeri Kask wrote:


Marc Aurele La France wrote:

On Tue, 18 Sep 2007, Eeri Kask wrote:
[]

So compile with  -DTWM_USE_XFT  -I/usr/include/freetype2  -lXft



Then insert



TitleFontsans-9
MenuFontsans-9
IconFontsans-9:bold
IconManagerFontsans-9
ResizeFontsans-10:bold



If you are a twm user, please test it; what do you think? :-)


I have refit this to our current source.  However, I don't think the
default fonts `twm` uses should be changed as doing so will surprise
many users.  It appears that restoring the previous defaults would only
require additional changes to InitVariables() in twm.c and GetFont() in
util.c.

Comments?

Marc.



Wait, please, don't commit yet!  :-)

In the meanwile I have done some minor cosmetic improvements to the Xft
inclusion and now I am in two days ready to release these (I renamed two
macros, as being no english native speaker these looked stupid in the
first iteration).  That is, I am in fact right now ready to release
these improvements, but additionally I have done some one-liner
corrections to text spacing everywhere in rendering as well, so that all
menu items, icon captions, iconmanager window label texts and so on look
considerably better spaced.  In the sense, that vertical spacing now
goes proportionally to the font height and not by a fixed amount like
font height plus 4 pixels etc. (but 1.2 times font height, and the
like).  It really goes hand in hand with using scalable fonts: one also
has to have scalable spacing as well!  :-)

These improvements are indeed finished too.


Two days I want to spend on completeing a small focus tweak: if and only
if some client window has focus and this client opens a transient window
(like thunderbird password prompt, or some file-open dialogue), then the
mouse should be warped into that window.  I am thinking how to do this
best using as much existing twm code and functionality as possible; and
it also remains to decide if it makes sense to invent a new keyword like
WarpToTransients as in vtwm to that purpose, to retain old behaviour
if the user so wishes.

Then I also found a serious bug and fixed a multicolumn iconmanager
geometry problem (in Xorg 1.0.3 twm release):  if mapped and one moves
that iconmanager window then its width gets corrupted during next
packing.  It was a small thinking error in PackIconManager() in
iconmgr.c while computing wwidth, it should/could be something like

wwidth = (ip-first ? (ip-first-width  0 ? ip-first-width :
ip-width/ip-columns) : 150);


These above improvements are unrelated to xft-support in twm though.


So actually I didn't quite understand you what do you mean by preserving
default fonts twm uses?  Currently twm uses fixed and variable in
twm.c as default fonts if no fonts are specified in .twmrc.   Next, if
some font failed to load, then fixed is (unrelated to InitVariables()
in twm.c) tried in util.c as a fallback.  So by the way, the DefaultFont
as initialised in twm.c is actually never used as a fallback, this font
is used only to render infowindow text!  (It should be called InfoFont
instead, but let it be DefaultFont as it is; we have DefaultForeground
and DefaultBackground as colours as well and nobody actually knows for
what purpose: to draw size- and infowindows.)  Much more important is
that one can specify DefaultFont in .twmrc which needs to be fixed (and
already is :-).

I am afraid we need to change fixed and variable in twm.c if Xft is
included because xft-subsystem crashes (at least mine) if one uses these
in XftFontOpenXlfd(), probably because these names are not
XLFD-compliant. (xft should not crash because of that, but it is xft's
problem, not ours.)  So as long as default font names (or user-specified
font names in .twmrc) are xlfd-conform one can use these as usual, in
that regard nothing has changed.  If I am correct the choice of fixed
as a default font is always justified by the fact that this font is
guaranteed present in every X11 installation and so it is a very
reasonable decision.  Concerning xft I believe having read Keith Packard
sans, serif and mono should be expected included in every xft
installation, so I chose sans-10 and mono-10 as a replacement for
variable and fixed in twm.c.
This is the story to that decision. :-)

Greetings,

   Eeri Kask




+--+--+
|  Marc Aurele La France   |  work:   1-780-492-9310  |
|  Academic Information and|  fax:1-780-492-1729  |
|Communications Technologies   |  email:  [EMAIL PROTECTED] |
|  352 General Services Building   +--+
|  University of Alberta   |  |
|  Edmonton, Alberta   |Standard disclaimers apply|
|  T6G 2H1 |  |
|  CANADA  |  |