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 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 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.
Thanks for the clarifications. I'll have another look. Due to dependencies, some of this might have to wait until your "Appearance" changes are complete.
(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).
Well, I personally would find such default behaviour rather annoying, so would prefer to make it optional. I'm not a big fan of window managers that raise windows or move focus and/or pointers all by themselves.
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.
That sounds reasonable.
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.
Right.One more thing, before I forget (again). The man page should be updated accordingly.
Thanks. Marc. +----------------------------------+----------------------------------+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and | fax: 1-780-492-1729 | | Communications Technologies | email: tsi@xxxxxxxxxxx | | 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.
Attachment:
cvs-devel.diff.gz
Description: Binary data
