Re: ANN: xterm patch #236
Hello, Having studied the http://invisible-island.net/xterm/ctlseqs/ctlseqs.html document I discovered several very useful xterm escape-sequence features. There is one of which I am not able to put to work properly though, so here is the puzzle. :-) Lets consider the sequence category CSI P s ; P s ; P s t Window manipulation ... and in particular P s = 2 1 - Report xterm window’s title as OSC l title ST (It appears OSC l title ST means ESC] l title ESC\ ) Obviously something like #!/bin/sh t=`echo -ne \033[21t` for i in 5 4 3 2 1 do echo -ne \033]2;...wait $i...\07 sleep 1 done echo $t doesn't work as l above needs to be replaced by 2; and ESC\ by \07 provided this is kind of approach is possible at all. Is there any way to use this above escape sequence in the sense as apparent from the above shell script? ... or how is this sequence supposed to be used? Thanks in advance for your time, Eeri Kask ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: TWM: truetype support
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
:
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@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: TWM: truetype support
(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
(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
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
on that screen 'not active'. Being at it, entering DrawIconManagerBorder()/DrawIconManagerEntry() we have the GC of the screen we just *entered* with the WList *tmp of the screen we just *left*. This ends in X-server refusing to do anything with this GC. Nobody noticed this because we have a couple of double-drawings executed for every iconmanager not-active cases which get triggered as the mouse leaves the twm-created frame window of the client, as well as the reparented client window itself. (The same double painting occurs as we enter some client: we draw iconmanager 'active' as we enter the frame window followed by a draw 'active' as we enter the reparented client window itself.) Noone noticed this bug probably because the iconmanager entry was (doubly) painted 'not active' already as we left the corresponding client window on the previous screen, and now entering the current screen this entry was tried to paint 'not active' 3rd time; ending in failure. It became only visible as now we paint the iconmanager entry in full, including text. Now travelling from one screen to the other the iconmanager entry was painted 'not active' as usual; but the third time painting after entering the current screen root window resulted in overpainting the iconmanager entry window name label on that screen in noticeably *huge* letters. So I observed this overpainting with different font sizes, not cleaning up there the previous (normal sized) text first. Only then I discovered the issue of the GC problem: the X server refused to XFillRectangle() that entry, but XftDrawStringUtf8() had no problem to overdraw text ... having the font structure of the current screen with a significantly different dpi resolution ended in huge letters. (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? Yes, this is the last one: stepping along iconmanager entries raises them unconditionally. I had no good idea what to do with the situation: usually one wants windows be raised, while looking for / searching some application in a stack of lots of windows. In the same time I am hesitant to invent new keywords for every single little feature (I think it is better to try to utilise already existing keywords). The correct solution could maybe be to overwork the twm used-defined function execution framework. This is incomplete in the sense, that if user-defined functions include commands depending on the existence of some 'active window', execution of these functions is not deterministic, if they are executed at all; as the 'active window' is sometimes not defined at the moment the execution starts. But that situation can change during execution! And this aspect seems not implemented in the current model. If this gets fixed then the autoraise feature can be removed as I am then able to incorporate it into a user-defined function. P.S. The f.hideiconmgr case above is badly implemented as well, I'll correct this next time: we don't have to move the mouse if we are already in the correct client window. Greetings, Eeri Kask ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: TWM: truetype support
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: 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 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
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 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
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 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
TWM: truetype support
Hello, in order to reach broader audience I'll post my recent twm activities besides [EMAIL PROTECTED] here as well (assuming these audiences do not 100% cover)... :-) For twm users here are two patchsets introducing truetype font support into twm in two steps. (1) twm-1.0.3-MyFont_ChangeGC.tgz cleans up some bitmap font rendering infrastructure as a preparatory step. (2) twm-1.0.3-TWM_USE_XFT.tgz then applied ontop introduces truetype font support enclosed in #ifdef TWM_USE_XFT. So compile with -DTWM_USE_XFT -I/usr/include/freetype2 -lXft Then insert TitleFont sans-9 MenuFontsans-9 IconFontsans-9:bold IconManagerFont sans-9 ResizeFont sans-10:bold into .twmrc and have fun! How it looks like you can see at www.inf.tu-dresden.de/~ek1/TheGIMP-screenshot.png (Opacity visible there is not yet finished and present here.) Step (1) actually does nothing in appearance and in speed, but as intended, all bugs, if any, should come in here. Step (2) then effectively only replaces XmbDrawString() by XftDrawString8() for text rendering in util.c so any performance or memory footprint issues coming up disclose problems hopefully only in xft. I tried to keep the Hamming distance to the original xorg twm-1.0.3 source code minimal, i.e. touch as few code lines as possible. If you are a twm user, please test it; what do you think? :-) Greetings, Eeri Kask twm-1.0.3-MyFont_ChangeGC.tgz Description: application/compressed-tar twm-1.0.3-TWM_USE_XFT.tgz Description: application/compressed-tar
