Re: NEWS on 1.6.0, restart+viewports = mess.

[Jeremy Hankins <nowan nowan org>]

Teika Kazura <teika lavabit com> writes:
> Hi.
>
> On Mon, 05 Oct 2009 15:51:48 -0500, Jeremy Hankins wrote:
>> Though why whether the window is maximized would be relevant is beyond
>> me.
>
> The root of evil must be matcher. When sawfish exits, all maximized
> windows are unmaximized.  And when it (re)starts, it maximizes
> again. Where?  In *current* viewport.  (It seems that actually there's
> no *current* viewport in this context. In maximization, the
> coordinates seems to be simply set to the (0,0) and (xmax-1, ymax-1),
> *on the screen* = in current viewport. So, not only maximization, but
> specifying coordinates to the window has the same effect.  But I don't
> understand VP, either. It's a guess.)

That makes a lot of sense.  Fundamentally, viewports are only
coordinates that aren't part of the visible display.  When the viewport
code switches viewports it does two things:

 - Updates some bookkeeping data -- the most important of which are
   x-offset and y-offset, which indicate the distance between the actual
   0,0 point of the display and the logical 0,0 point of the
   virtual-desktop (i.e., all viewports put together).

 - Every window in the current desktop (in 1.5 it was literally every
   non-viewport-sticky window) is moved in the opposite direction of the
   viewport-movement, to make it appear as if the display has moved.

So viewports are a logical overlay to make navigation easier, and to
help the pager display properly.  Really all that's going on is that
windows are at various locations off and on screen, and the
viewport-movement commands just shift them around so that some come
on-screen and others go off-screen.

> Now what's current? It depends. Suppose one window rule is "appear in
> viewport Z" After processing that window, the current viewport is Z,
> not (0, 0).

The current viewport is always the coordinates from 0,0 to
screen-width,screen-height.  To put a window in a viewport other than
the current one the coordinates should be somewhere outside of that
range.  Probably the simplest thing to do would be to come up with a way
to place a window in a vp without moving the current vp -- after all,
all that's needed is to place the window in the appropriate location
off-screen.  When the viewport changes the location data of all the
yet-to-be-managed windows is no longer correct, so shifting viewports is
problematic.

But to do that I need to find where the current confused setting of the
location is happening -- possibly the best thing to do is nothing,
really, but there may be some other reason for adjusting the coordinates
of the window.  I'll look for that, but if someone knows already maybe
you can let me know where to look?

> Again the same question: what's the current viewport? If infinite
> desktop is there, the Sawfish's conventional VP doesn't make sense.
> We need a new definition, absorbing the old. This is the reason I did
> a bit of poll on VP and ID. (Sorry I haven't analyzed it.)

Infinite-desktop isn't really at odds with conventional viewports; it
just bypasses some of the restrictions and safeguards of the
conventional viewport system.  It's true that when x-offset and y-offset
aren't multiples of screen-width and screen-height (respectively) you're
not actually at a particular point on the viewport grid, but that's not
really a problem.  And if you've got dynamic viewports turned on there
isn't even a problem going off the edge of the current virtual desktop
since the viewport-tracking variables will be automatically updated.

-- 
Jeremy Hankins <nowan nowan org>