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
Re: TWM: truetype support
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
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 | |
