Teika Kazura <[email protected]> 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 <[email protected]>
