Re: TWM: truetype support
Oh, I am happy you take the time to work on twm, big thanks! :-) (2) twm-1.0.3-diff2.TWM_USE_XFT.tgz introduces Xft support (replaces bitmap text rendering functions with xft-font rendering). [Compile with -DTWM_USE_XFT to activate.] This leaks memory in the form of XftDraw structures that never get released. I've reworked this to fix that problem, and also to re-instate core font support even if TWM_USE_XFT is #define'd. If a font cannot be found through libXft, it will be looked for through the older standard mechanism. Oops, I see, I'am very sorry about that! Now as you say, I'll understand the problem. May I kindly ask you to give me your corrections if you don't mind, as it would be pointless by me to investigate issues you have already solved (and it would save time). (3) twm-1.0.3-diff3.Spacing.tgz (Vertical) spacing corrections; having scalable fonts one should use scalable spacing as well, otherwise one day having 600x600 dpi screen vertical spacing of, e.g. 4 pixels, results in text line distance of zero. Now baseline skip is computed like 1.2 times font height or something. I would prefer that this be done only for Xft fonts, or, better, be made configurable. I agree and I'll put these changes inside #ifdef TWM_USE_XFT as well. Configurable ... in what sense? Using some compile-time #define? If you prefer this, I'll do it that way. (4) twm-1.0.3-diff4.TWM_USE_OPACITY.tgz If you value transparency in twm menus and icon manger/icons, apply this. This patchset introduces MenuOpacity and IconOpacity keywords having integer values in range 0...255. [Enable with -DTWM_USE_OPACITY] As stated previously, this will not be integrated as it relies on X.Org-specific functionality. I have thought about your standpoint here. This may be Xorg functionality, but if twm is run to manage the Xorg server, this functionality will be available to twm, regardless which X11 implementation/distribution twm belongs to. So I'd suggest this functionality be available as twm patch, and its everyone's own decision to include/apply it ... or not. (I have all respect in your preference not to do this if you so like.) (I am even considering to very slightly enlarge opacity support in the sense that twm should intercept these opacity property change requests from client windows and propagate them to self-created frame-windows of these top-level clients. The user is responsible to run xcompmgr in the backround, twm will not be dealing with transparency in any other way. This increases opacity code in twm maybe about ten lines or so in HandlePropertyNotify() in events.c. So if some client asks for transparency, twm wouldn't stand in the way.) (5) twm-1.0.3-diff5.Appearance.tgz Here lies probably the most radical change I have made to twm: the iconmanager painting DrawIconManagerBorder() is now DrawIconManagerEntry() and draws the iconmanager entry in full. This work is not completed yet. I'm inclined to delay this one until it is complete. If you didn't, I would have asked you to do this. :-) (6) twm-1.0.3-diff6.Fixes.tgz Here are bugs I encountered in twm as improving icon manager functionality; some are serious. Such as? Please be more descriptive. (1) In iconmgr.c.diff6 at the end is corrected a bug which leads to *multicolumn* iconmanager window width gradual collapse under certain circumstances while computing 'wwidth'. I observed this while resizing and/or moving the icon manager window and then terminating some client, say xcalc. In that moment the icon manager window gets squeezed unexpectedly showing this bug. Other 'fixes' in this diff somehow clarify the MoveIconManager() (which is the second most heavily modified function next to DrawIconManagerEntry()), with the purpose of returning a mapped (not iconified or unmapped) client window if the icon manager window is *not* mapped. I noticed that f.forwiconmgr gets stuck on some unmapped/iconified window if the icon manager is not mapped as well, leaving the mouse sporadically somewhere on the root window (exactly there, where the iconified client window would appear if it where mapped -- and if this falls inside some other mapped window, the f.forwiconmgr cycling starts from this client again; a kind of sub-cycling emerges). So in the end one can step along *all* windows if the icon manager is mapped, and only along *mapped* windows if the icon manager is not mapped. This was my intended solution to the mouse getting lost problem. (2) In events.c.diff6 in HandleEnterNotify() I discovered a situation where entering the root window (one can enter the root window in leaving some client window on the same screen; and in leaving some other screen) while coming from some other screen and then --- being on the screen just entered NotActiveIconManager() gets called with the UnHighLight_win client window data structure on the screen just left in order to paint the iconmanager entry on that
Re: TWM: truetype support
Eeri Kask 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
On Wed, 10 Oct 2007, Eeri Kask wrote: (2) twm-1.0.3-diff2.TWM_USE_XFT.tgz introduces Xft support (replaces bitmap text rendering functions with xft-font rendering). [Compile with -DTWM_USE_XFT to activate.] This leaks memory in the form of XftDraw structures that never get released. I've reworked this to fix that problem, and also to re-instate core font support even if TWM_USE_XFT is #define'd. If a font cannot be found through libXft, it will be looked for through the older standard mechanism. Oops, I see, I'am very sorry about that! Now as you say, I'll understand the problem. May I kindly ask you to give me your corrections if you don't mind, as it would be pointless by me to investigate issues you have already solved (and it would save time). I'm attaching a context diff of what I've done on this so far. It is against our main CVS repository as it stands now. Note that, as of this writting, our publicly accessible repository mirror has yet to be sync'ed (but it should be sometime today). This includes (among other odds ends): - your first change (MyFont_ChangeGC); - my rework of your second change (TWM_USE_XFT); - two non-spacing changes I found in your third batch (Spacing); - the XSetClassHint() and DefaultFont changes from your fifth batch (Appearance); - your seventh change (Improvements). This is not yet ready to commit. (3) twm-1.0.3-diff3.Spacing.tgz (Vertical) spacing corrections; having scalable fonts one should use scalable spacing as well, otherwise one day having 600x600 dpi screen vertical spacing of, e.g. 4 pixels, results in text line distance of zero. Now baseline skip is computed like 1.2 times font height or something. I would prefer that this be done only for Xft fonts, or, better, be made configurable. I agree and I'll put these changes inside #ifdef TWM_USE_XFT as well. Configurable ... in what sense? Using some compile-time #define? If you prefer this, I'll do it that way. By configurable, I meant through .twmrc. But this might be more trouble than it's worth. So, I'd settle on adjusting spacing only for Xft fonts. (4) twm-1.0.3-diff4.TWM_USE_OPACITY.tgz If you value transparency in twm menus and icon manger/icons, apply this. This patchset introduces MenuOpacity and IconOpacity keywords having integer values in range 0...255. [Enable with -DTWM_USE_OPACITY] As stated previously, this will not be integrated as it relies on X.Org-specific functionality. I have thought about your standpoint here. This may be Xorg functionality, but if twm is run to manage the Xorg server, this functionality will be available to twm, regardless which X11 implementation/distribution twm belongs to. So I'd suggest this functionality be available as twm patch, and its everyone's own decision to include/apply it ... or not. (I have all respect in your preference not to do this if you so like.) (I am even considering to very slightly enlarge opacity support in the sense that twm should intercept these opacity property change requests from client windows and propagate them to self-created frame-windows of these top-level clients. The user is responsible to run xcompmgr in the backround, twm will not be dealing with transparency in any other way. This increases opacity code in twm maybe about ten lines or so in HandlePropertyNotify() in events.c. So if some client asks for transparency, twm wouldn't stand in the way.) I doubt very much anyone would ever use XFree86's twm with X.Org's xcompmgr. But I understand your point. (5) twm-1.0.3-diff5.Appearance.tgz Here lies probably the most radical change I have made to twm: the iconmanager painting DrawIconManagerBorder() is now DrawIconManagerEntry() and draws the iconmanager entry in full. This work is not completed yet. I'm inclined to delay this one until it is complete. If you didn't, I would have asked you to do this. :-) OK. Let me know when it's ready. (6) twm-1.0.3-diff6.Fixes.tgz Here are bugs I encountered in twm as improving icon manager functionality; some are serious. Such as? Please be more descriptive. (1) In iconmgr.c.diff6 at the end is corrected a bug which leads to *multicolumn* iconmanager window width gradual collapse under certain circumstances while computing 'wwidth'. I observed this while resizing and/or moving the icon manager window and then terminating some client, say xcalc. In that moment the icon manager window gets squeezed unexpectedly showing this bug. Other 'fixes' in this diff somehow clarify the MoveIconManager() (which is the second most heavily modified function next to DrawIconManagerEntry()), with the purpose of returning a mapped (not iconified or unmapped) client window if the icon manager window is *not* mapped. I noticed that f.forwiconmgr gets stuck on some unmapped/iconified window if the icon manager is not mapped as well, leaving the mouse sporadically somewhere on the root window (exactly there, where the iconified client
Re: TWM: truetype support
On Wed, 10 Oct 2007, Eeri Kask wrote: Eeri Kask wrote: (6) twm-1.0.3-diff6.Fixes.tgz Here are bugs I encountered in twm as improving icon manager functionality; some are serious. Such as? Please be more descriptive. (1) In iconmgr.c.diff6 at the end is corrected a bug which leads to *multicolumn* iconmanager window width gradual collapse under certain circumstances while computing 'wwidth'. I observed this while resizing and/or moving the icon manager window and then terminating some client, say xcalc. In that moment the icon manager window gets squeezed unexpectedly showing this bug. I am sure my correction to this problem is not correct, as it only undoes something what gets screwed somewhere else (namely, ip-width seems to have incorrect value on enrty into PackIconManager()). I'll have to study the problem more closely and then suggest a bugfix. OK. Thanks for letting me know. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: TWM: truetype support
On Wed, 10 Oct 2007, Marc Aurele La France wrote: I'm attaching a context diff of what I've done on this so far. It is against our main CVS repository as it stands now. Note that, as of this writting, our publicly accessible repository mirror has yet to be sync'ed (but it should be sometime today). This includes (among other odds ends): - your first change (MyFont_ChangeGC); - my rework of your second change (TWM_USE_XFT); - two non-spacing changes I found in your third batch (Spacing); - the XSetClassHint() and DefaultFont changes from your fifth batch (Appearance); - your seventh change (Improvements). This is not yet ready to commit. Oops. Use this one instead. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. cvs-devel.diff.gz Description: Binary data
