On Sun 25 May 2014 at 23:27:54 -0500, Matthew D. Fuller wrote:
> 
> > Dangit.  Looks like we have some backtracking to do...
> 
> OK, well, whatever bug _this_ is, is old.  What's happening is that
> I'm getting the icon managers from the first workspace, no matter what
> WS I'm in (though the windows shown, with iconified/not status, are
> from the proper one).  That goes back at least as far as 3.8a.  So, we
> don't need to worry overmuch about that right now.

Finally that bug seems to manifest on my scratch monkey, ^W^W, work
laptop. I don't know why this suddenly happens.

I have (for the test) only one icon manager configured. What I see,
after I do f.showiconmgr, is several icon manager windows stacked on top
of each other. If I move them apart, it turns out that there are 9: one
for each workspace.

Most of them are empty (but have space for 2 windows), and one has
nearly all windows + icons in the current workspace, plus 2 empty spots.
These are probably for xbiff and xclock. One of the 2-entry windows is
not empty but lists xbiff and xclock (so that one plus the one with the
other windows makes a complete list for the workspace).

When switching workspaces, the windows correct themselves. For some of
them it takes a few times.

(This is *different* from what I see on my coding machine; where it
would be much less convenient to debug...)

Anyway, I made some notes while staring at the code. It's far from
complete yet... and may still be wrong anyway.

The effect I saw with the 9 windows may be related to my note below on
GotoWorkspace().

/*
 * Theory of operation.
 *
 * Start with the one-workspace case.
 *
 * In the .ctwmrc you can specify multiple icon managers, and which windows
 * will be placed in them. Let's call them the primary IconMgr and secondary
 * IconMgrs.
 * There is nothing stopping you from specifying them so, that one window
 * can appear in multiple icon managers.
 *
 * ScreenInfo.iconmgr (Scr->iconmgr) points to the primary icon manager.
 * The secondary ones are linked to it via IconMgr.next and .prev.
 *
 * So each window may occur in one or more icon managers: it has a little
 * sub-window in each of them.
 * The sub-window is represented by struct WList.
 * twm_win->iconmanagerlist points to that. If the window does occur in
 * multiple iconmanagers, these occurrences are linked via WList.next and
 * .prev.
 *
 * Undiscovered:
 * - IconMgr.lasti
 * - how IconMgr.first .last .active (all WLists) are related to the
 *   pointers from the windows
 *
 *
 * Expand to multiple workspaces.
 *
 * The iconmanagers are different windows in each workspace: it is not
 * just a single window with multiple occupation. This is so that you
 * can move it where you want in each of them.
 * (Personally I would probably have used a single window and moved it
 * around to remembered locations in each workspace)
 *
 * So both the IconMgr and the WLists are replicated for each workspace.
 * These instances are linked via IconMgr.nextv and WList.nextv.
 *
 * The replicated instances are created after the first IconMgr, in
 * AllocateOthersIconManagers().
 *
 * If we believe CreateIconManagers(), then from the primary IconMgr
 * for workspace #0 (Scr->iconmgr), you can follow ->nextv to get to the
 * replicas for workspace #1, #2, ..., and from each of those, follow
 * ->next to get to the secondary IconMgrs for the same workspace.
 * But the replication function is confusing.
 *
 * For secondary IconMgrs, .nextv seems to be always NULL.
 *
 * WorkSpace.iconmgr points to the primary IconManager that belongs to
 * that workspace.
 *
 * There does not seem to be a need to track the replicated versions of
 * the same IconMgr both via .nextv and WorkSpace.iconmgr.
 *
 * In GotoWorkspace(), there is a "reorganisation" of WLists.
 * I am not 100% sure what that means.
 * Probably it is doing the job that more logically should be done in
 * ChangeOccupation(): put windows (WLists) in icon managers and take
 * them out, depending on their occupation.
 */

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl    -- 'this bath is too hot.'

Attachment: pgphYVY0TOIZC.pgp
Description: PGP signature

Reply via email to