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 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@xxxxxxxxxxx
http://XFree86.Org/mailman/listinfo/devel
