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
- 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

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

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.


One more thing, before I forget (again). The man page should be updated accordingly.



|  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.

Attachment: cvs-devel.diff.gz
Description: Binary data

Reply via email to