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" MenuFont"sans-9" IconFont"sans-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
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 > >> TitleFont"sans-9" >> MenuFont"sans-9" >> IconFont"sans-9:bold" >> IconManagerFont"sans-9" >> ResizeFont"sans-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" IconManagerHighlight"grey65" 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 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
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: > 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-di
Re: TWM: truetype support
ow (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 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
> 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
>> (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
>>> (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
>> 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. > > Marc. 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. :-) 8<8< 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: */ 8<8< Greetings, Eeri Kask ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: TWM: truetype support
Mike Russo wrote: > Hey dude - thanks for spending some time on twm and making it look > good. Any chance you might upload a gzipped Linux/x86 binary? :) Hey I have a better idea. You have wget, gcc and X11 headers installed? (1) Then run this script: 8< #!/bin/sh mkdir twm.tweaked cd twm.tweaked wget http://xorg.freedesktop.org/archive/individual/app/twm-1.0.3.tar.gz wget http://www.inf.tu-dresden.de/~ek1/twm-1.0.3-diff1-7.tar tar -xzf twm-1.0.3.tar.gz tar -xf twm-1.0.3-diff1-7.tar cd twm-1.0.3 LDFLAGS=-lXft \ CFLAGS="-O2 -DTWM_USE_OPACITY -DTWM_USE_XFT -I/usr/include/freetype2" \ ./configure --prefix=/usr/local cd src tar -xzf ../../twm-1.0.3-diff1.MyFont_ChangeGC.tgz tar -xzf ../../twm-1.0.3-diff2.TWM_USE_XFT.tgz tar -xzf ../../twm-1.0.3-diff3.Spacing.tgz tar -xzf ../../twm-1.0.3-diff4.TWM_USE_OPACITY.tgz tar -xzf ../../twm-1.0.3-diff5.Fixes.tgz tar -xzf ../../twm-1.0.3-diff6.Improvements.tgz tar -xzf ../../twm-1.0.3-diff7.Appearance.tgz ./Apply_diff1.sh ./Apply_diff2.sh ./Apply_diff3.sh ./Apply_diff4.sh ./Apply_diff5.sh ./Apply_diff6.sh ./Apply_diff7.sh make cp twm ../../ cd ../../ rm -rf twm-1.0.3 rm twm-1.0.3-diff[1-7].*.tgz 8< ... and you'll have twm with XFT Linux/x86 binary in twm.tweaked/. (2) xcompmgr is at http://xapps.freedesktop.org/release/xcompmgr-1.1.3.tar.gz (3) put Section "Extensions" Option "RENDER" "Enable" Option "Composite" "Enable" Option "DAMAGE" "Enable" Option "XFIXES" "Enable" EndSection into xorg.conf, (4) run "xcompmgr -c -o 0.5 -r 6 -t -6 -l -9 &" prior to "exec twm" in .xinitrc. That's it. :-) Greetings, Eeri Kask ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: [Patch] twm: combined patchset
Ed Schouten wrote: > * Eeri Kask <[EMAIL PROTECTED]> wrote: >> In my opinion too, this would be a very helpful feature. It would be >> even perfect if in all places you can specify a window name in a list in >> .twmrc you could use regexp notation generally. (E.g., vtwm has it for >> some years probably.) >> >> (Probably all strcmp() calls in LookInList() and GetColorFromList() in >> list.c are the starting place to look at.) :-) > > Well, I'm not sure about that. We're supposed to keep it minimalistic, > right? But I'm only saying this because I don't have a use for that > (yet). > Anyway: I've finished my patchset, consisting of three new features I > wanted my twm to be capable of: > > 1. The wildcard support, which allows you to match all windows in >AutoRaise and, more important, WindowRing. To be strict, momentarily "*" is not "wildcard support" but an alias for "all windows". :-) > 2. Retaining focus when moving the pointer on the root window. Unfortunately the mouse gets too sloppy as it stands in the final version. Test this: (1) Put NoTitle { "XTerm" } into .twmrc, start xterm, then xcalc. (I assume xcalc has titlebar.) (2) Now move mouse into xcalc, then into xterm. How do you focus xterm? Probably only by killing xcalc. (Or doing f.unfocus to xcalc.) Why that? It appears twm is architected with the "focus follows mouse" from ground up and everywhere in the code this policy seems to be assumed (excluding the case one executes f.focus on some window explicitly, only then you leave the "PointerRoot" mode). Now it is true every titled window gets focus explicitly assigned to that window (in HandleEnterNotify()), but if you kill PointerRoot recovery in HandleLeaveNotify() no window without a title bar is assigned focus in HandleEnterNotify(), they rely on PointerRoot focus mode. Destroy handler (as well as f.unfocus) recovers PointerRoot mode. Attached is an alternative initial attempt of the sloppy-mouse functionality. Mostly this is based on what f.focus does but adapted so that it (1) should coexist peacefully with the PointerRoot overall policy, (2) does not break the icon manager (keeps sending focus into client windows if mouse is in icon manager, and so on). This patchset is a "minimalistic implementation" in the sense that now we don't have f.focus functionality: If one sets f.focus to some client and then enters some other client, the focus warps over there as well. To keep f.focus functionality probably some additional housekeeping state is needed to distinguish SloppyFocus mode from focus tied to some client. There may be (I hope only) some minor cosmetic bugs in this implementation remaining, probably in drawing icon manager entries under some conditions. (Apply this patchset against plain Xorg twm-1.0.3 realease.) > 3. Automatically focusing windows after they have been placed on screen. > > I've written the last patch, because I tend to use the keyboard a lot. > It would be nice if I could just press a keycombo to start the terminal > and have focus on it automatically. Right now you first have to move the > mouse cursor on top of the window, which is awful in my opinion. Why don't you use the already existing "WarpCursor" keyword for that? There seems no apparent reason not to do that. This only is maybe a matter of taste: to utilise existing keywords as much as possible than inventing new ones for every feature. :-) Greetings, Eeri Kask twm-1.0.3-diff.SloppyFocus.tgz Description: application/compressed-tar
Re: [vtwm-hackers] TWM: truetype support (now for VTWM)
>> }Hello twm users, >> } >> }let me kindly present recent advancements done to the twm window >> }manager. Attached is a tar file containing the following tar files: >> >> Thanks Eeri. Now we just need someone to port the diffs to vtwm. >> >> C > > > As there seems interest I definitely want to do that in principle. > The first part (preparatory cleanup work for porting > twm-1.0.3-diff1.MyFont_ChangeGC.tgz) is the most tedious part I think, > but not that hard. [] Hello vtwm users, Here comes what I once promised: attached are (*) vtwm-5.4.7-diff0-2.tar (*) VTWM-Tweaked.sh (You can get these at www.inf.tu-dresden.de/~ek1/vtwm-5.4.7-diff0-2.tar www.inf.tu-dresden.de/~ek1/VTWM-Tweaked.sh as well.) In fact this is only a very preliminary patchset, I only ported some of the twm work to vtwm over the weekend with as little effort as I only could. Included are: (*) Imakefile.no-sound.diff this disables sound support (I don't have rplay installed, ... and I prefer silence anyway. :-) If you run VTWM-Tweaked.sh for automatic compile and want sound, then manually please comment out the appropriate line in that script you'll find easily. (*) Intro-twm.h.diff Intro-screen.h.diff I had problems with the 'Image'-data structure in util.h being unknown to the compiler so I had to change the order some header files are included. (*) vtwm-5.4.7-diff0.NO_I18N_SUPPORT.tgz This is the most intrusive cleanup patch I had to do to vtwm in order to start Xft support work at all. Hereby I ask anyone among vtwm developers with free time and interest in helping to read these line-by-line and detect places I have unintentionally screwed up. :-) NO_I18N_SUPPORT now actually only determines how window and icon names are retrieved from window properties, and I think this could be streamlined as well, i.e. one should remove this configuration parameter entirely (i18n support will be determined in run-time evaluating some locale-functions, as twm does). (*) vtwm-5.4.7-diff1.MyFont_ChangeGC.tgz (*) vtwm-5.4.7-diff2.TWM_USE_XFT.tgz These come directly from twm, I even was 'lazy' to change TWM_USE_XFT into VTWM_USE_XFT (as simply being irrelevant). (*) dot.vtwmrc Slightly edited system.vtwmrc file I used for testing, to reflect my keyboard shortcut preferences. If you are a vtwm user, please test this in all your configurations and lets sort out bugs et cetera you may encounter. I haven't tested the "doors" part because I dont know yet what they are and how to make use of them, thought. Spacing corrections are missing for now as vtwm code is a little harder to read in that respect but at least some icon labeling adjustments need to be done. Opacity support is as an easy part coming as well. Then later the sloppy-focus if finished for twm will follow for sure as my elbow unintentionally moves the mouse out of windows permanently otherwise resulting in constant hassle in using computers. :-) Greetings and have fun, Eeri Kask P.S. Apply against vtwm-5.4.7.tar.gz (or only run the script attached). VTWM-Tweaked.sh Description: application/shellscript vtwm-5.4.7-diff0-2.tar Description: Unix tar archive
Re: TWM: truetype support
e.g. the icon manager in twm was supposed to work at all --- maybe one should dig in decades old mailing lists to get some hints :-). > I'm attaching a diff, against XFree86 CVS source, of those of your changes > that I have so far integrated. In the Xorg version of the twm source code one has to use in the following code sequence while drawing the window title : else if (Tmp_win != NULL) { if (Event.xany.window == Tmp_win->title_w) { MyFont_DrawImageString (dpy, DRAW_WIN(Tmp_win,title_w), &Scr->TitleBarFont, DRAW_COL(Tmp_win,TitleC), Scr->TBInfo.titlex, Scr->TitleBarFont.y, Tmp_win->name, strlen(Tmp_win->name)); flush_expose (Event.xany.window); } else if (Event.xany.window == Tmp_win->icon_w) { : the function MyFont_DrawImageString() and not MyFont_DrawString(). This is because if there is no "NoTitleHighlight" in .twmrc then moving mouse in and out of the client window causes the title-highlight window (the checkerboard pattern) be mapped/unmapped as focus moves in and out. While moving out expose events are generated for the underlying titlebar-window which draws the title bar always anew without erasing the draw area first, effectively alpha-blending the Xft partly transparent text onto the title window again and again resulting in smearing the titlebar text. In the other case if NoTitleHighlight is active then expose events only come if the title bar was obscured, resulting in clearing the titlebar window by the X server first, then drawing the title by MyFont_DrawString(). > Lastly, do you intend to update twm's man page? It has to be updated of course if these improvements are finished and considered useful to be included into the twm source tree. I am happily going to write the initial text, but I'll have to find someone with English as a native language to correct this then. :-) Greetings, Eeri Kask ___ Devel mailing list Devel@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: ANN: xterm patch #234
Hello guys, what do you think, would it be a good idea to invent some shell-escape sequence for xterm to set the XUrgency hint by shell scripts? We have some for setting the xterm window title, icon name, and some properties. Currently one can even configure the bell to set this hint. (Maybe this feature exists already and I only haven't figured out how to use it... :-) Greetings, Eeri Kask ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Xinerama support for vtwm
Hello vtwm users, www1.inf.tu-dresden.de/~ek1/vtwm-20080210-tweaked-diffs.tar includes a patchset containig the backport of the Xinerama support recently developed for twm. It is to be applied against the 20080210 trunk version of the vtwm source code; execute svn export http://cadaver.deadbeast.net/svn/vtwm/trunk to download this. Not entering the local 'trunk/' subdirectory, running www1.inf.tu-dresden.de/~ek1/VTWM-Tweaked.sh should download the above patchset and compile the tweaked vtwm with Xinerama enabled. (Having been asked to supply compile scripts/instructions, so here I am happily doing this.) :-) * How this Xinerama support looks like and how it was created is somewhat tedious/unnecessary to describe here, though this dummy screenshot www1.inf.tu-dresden.de/~ek1/TheGimp-Xinerama.png shows some of the development/testing environment. In short, the left half is a circular Xnest/Xdmx Xinerama mockup (spanning 9 tiles), 'fdclock' running in the background and vtwm managing the vertically-zoomed ghostscript window (depicting the implemented full-zoom algorithm enlarging the pink sample window into green). The right half is twm-managed X11 physical screen used to take the screenshot by gimp. (As xcompmgr seemingly does not run on Xinerama, the vtwm "screen" looks somewhat flat.) The most important implementation aspect to be noted here probably is, the zoom functions (fullzoom included) only zoom across Xinerama tiles which the client window already intersects, and do not perform a kind of "global maximise", spanning the client across Xinerama tiles resulting in a maximum possible area covered. Second, the vtwm/twm window manager elements (iconmanagers, icon regions, virtual-display window, doors, etc) falling onto "dead areas" by .vtwmrc configuration are brought back onto visible area with the least possible effort. This means, under certain unlucky conditions these elements may appear one ontop of some other, if the geometric computations so result. (I did not put any effort into tracking screen coverage in this respect as being unnecessary complexity, which can be in fact easily avoided by .vtwmrc configuration.) Having tested this code for some time already, though I am not using Xinerama very extensively myself, so I have to rely largely on any problem reports, ideas, etc. one may encounter. Have fun, Eeri Kask ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
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