I've been having this problem of late, and I finally got around to
trying to track it down.  A while back, I noticed after an upgrade
that the f.occupy window tended to be mostly invisible when I pulled
it up (see <http://www.over-yonder.net/~fullermd/dl/occupy.png>).
When I hit where the 'All' button should be, the workspace buttons
suddenly appear (see
<http://www.over-yonder.net/~fullermd/dl/occupy2.png>).  And I can
then unselect workspaces, and the buttons still show up just fine
(popped out), so it's not just the 'up' position is somehow screwy.
And, of course, the control buttons at the bottom of the window don't
show up either.

Odd.  I wondered if maybe it was just a bogon because my 'upgrade' had
involved simply f.restart'ing a running instance, so I fired up an
Xnest and tried it out, and it worked just fine and normal-like there.
So I ignored it.

Since, though, I've started my session from scratch, and it's still
doing it.  It still works normally in Xnest, but it falls apart in a
normal X session.  Decidedly odd.

Now, one interesting feature you'll note if you're paying attention is
that I have 9 workspaces in a 3x3 grid.  That means there's 3 columns
in the Occupy window.  There's also 3 columns of the 'OK/Cancel/All'
buttons, but they're wider than the workspace buttons, so part of the
'All' button is actually chopped off.  But that doesn't seem to bear
directly on the problem.

I discovered, entirely by accident, that resizing the window suddenly
makes everything appear, even if I size it back to the same size (see
<http://www.over-yonder.net/~fullermd/dl/occupy3.png>).  But any time
it has to remap, like if I push it down below another window and pull
it back up, it doesn't redraw the portions right (see
<http://www.over-yonder.net/~fullermd/dl/occupy4.png>).

That is, as long as it's that default size or smaller.  If I make it
LARGER, so that the right border of the window is beyond the right
border of the top buttons, it draws just fine, and will redraw itself
when I bury it and bring it back up.  It'll even save that new size,
so I can 'Cancel' it and pull it back up later, and it'll draw just
fine with that new size (see
<http://www.over-yonder.net/~fullermd/dl/occupy5.png> -- Note the red
background showing through to the right of the buttons).

Now, note also that the 'All' button is still cut off, so it's not
just that the window doesn't draw right when the control buttons
aren't all displayed.  And I'm sure if it were ALWAYS doing this,
somebody else would have piped up by now.  So it seems to be some
weird combination of the workspace buttons being narrower than the
control buttons, AND the window size being only as big or smaller than
the workspace buttons.


And here I run out of steam.  I've tracked the window sizing down to
workmgr.c:CreateOccupyWindow(), around line 1828-1863 (in 3.7b5), but
I can't make heads or tails of it.  There's width and bwidth and
owidth and min_width and min_bwidth, and width seems to be the one
that's used, and it's calculated twice in a row using the exact same
formula...  there's some real oddity happening in that if/else at the
end of those lines.  The problem does NOT, by the way, appear to have
anything to do with I18N; it shows up both with and without it
defined.

However, if I heavy-handedly go in after all that and manually add 3
to width (the next step to which it'll actually size; 2 or 1 leave it
at the old size, which is 105), it'll pull up the window with that
little extra size, and draw it just fine from scratch.  So,
presumably, it's coming up with too small a number in this particular
case, even though it looks to the eye to be big enough (barely, but
big enough) to hold all the workspace buttons.

Interestingly, in this case it also creates a 'ledge' at that width in
the background, which is visible if you pull the window further out
(see <http://www.over-yonder.net/~fullermd/dl/occupy6.png>).  I'm not
sure what that means, either.  Note that I tried pushing the 'ledge'
out further (say, to +10), and then sizing the window back down so it
was smaller than that ledge-width, and it kept drawing just fine until
I got the width back down to flush with the right side of the buttons,
where it's been failing.  Yet more odd.


Anyway, it's left my head completely spinning trying to figure out
what all the different width variables mean, and for that matter what
some of the other variables are supposed to hold and where all these
values are ultimately coming from.  Can somebody who understands the
way these pieces all fit together shed a little light on this?


-- 
Matthew Fuller     (MF4839)   |  [EMAIL PROTECTED]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.

Reply via email to