Re: TWM: truetype support

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

 



> 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@xxxxxxxxxxx
http://XFree86.Org/mailman/listinfo/devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [X Forum]     [XFree86]     [XFree86 Newbie]     [X.Org]     [IETF Annouce]     [Security]     [Fontconfig]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux