Teika Kazura <[email protected]> writes: > Hi, Jeremy. Let me ask you a question on dynamic VP. > > In dynamic VP, when you go left or up and the VP is enlarged, all > windows are "shifted" to right or down, right? (And the opposite for > top/left part shrinking.)
Sort of. All windows are shifted _every_ time the vp is moved, so it's true that windows are shifted when the vp moves past the top or left virtual-workspace boundary, but I don't think that's what you mean. Dynamic viewports work by: - Eliminating the checks for virtual-workspace-boundaries. So the user is allowed to move the viewport around without any restrictions. - Every time the viewport is shifted the appropriate virtual-workspace boundaries are calculated to include (a) the current viewport (in case it's empty) and (b) all windows in the current workspace (including those off-screen). This is done by the viewport-dynamic-resize function in viewport.jl in a way that ensures that the screen-boundary grid isn't shifted around. (Calculating the appropriate virtual-workspace boundaries means that the values for viewport-dimensions and viewport-x-offset and viewport-y-offset are calculated.) This is also done whenever the workspace is changed, since there's a new set of visible windows. The best way to think of a viewport is as a particular origin for the coordinate grid -- a particular x=0,y=0 point. Given a collection of window locations (with some being negative) and window dimensions it's easy enough to calculate the size of the box needed to hold them all, and the offset between the upper-left of the screen and the upper-left of the box can be calculated as well. Ensuring that the vp grid boundaries don't migrate around makes it a bit more complicated, but not too much. > Is it possible to detect these "shifts"? If not, I think we need > 'viewport-shifted-hook' which passes (list workspace x-increase > y-increase) to hook functions. At first I didn't understand why this would be useful, but see below. > An alternative is to set the value to new global variable > 'viewport-shift' during the call of viewport-resize-hook. Hmm.. viewport-resized-hook may be badly named; it should perhaps be viewport-maybe-resized-hook since it's sometimes called even when the viewport size hasn't changed. > I don't understand workspace things well, since I don't use multiple > workspaces. But it seems that VP size is common to all WS, so shift is > common, too? No, though before dynamic workspaces it was. In order to fix a bug for dynamic viewports I had to separate them: viewport dimensions and offsets are stored in the workspace-viewport-data variable by viewport-leave-workspace-handler (called from leave-workspace-hook). They're then restored (if they exist) by viewport-enter-workspace-handler when a workspace is entered. > I've written a small script which "remembers" the formerly focused window > and the pointer position in each viewport. (I switch VP with shift + arrow, > and it enables to resume the stopped work in each VP.) But it doesn't > work if VP gets shifted. Ahh, so this is why you want to know when the virtual workspace is expanded to the top or left -- because that changes the row/col coords. So the problem is that with dynamic viewports a viewport doesn't have a stable identifier over time. Hmmm.. It might be possible to stick a check in viewport-dynamic-resize to see if the offsets increased. But there are other times when viewport-dynamic-resize is called -- when changing workspaces or when changing the size of the virt. workspace (e.g., via the configuration interface). Workspace switching, for example, might lead to a jump in the offsets as well, and incorrectly indicate the change you're looking for. One way around the problem would be to use relative vp coordinates (e.g., column=-1 means the column to the left of the current one) and update them all whenever the vp is changed. You'd also have to have separate data sets for each workspace, if you intend to support workspaces. Another option would be to provide a stable identifier for viewports, i.e., a way to give a particular viewport (or viewport/workspace combination) a name. But this isn't really a separate option, because the same problem would have to be solved here. Hmm.. One other idea that may do what you want: you could forget about workspaces and viewports, and simply keep a stack of recently-focused windows. When switching to a new workspace or viewport go down the stack until you find a window that's currently displayed (excluding sticky windows, probably). This option seems easiest to me, and would make your code independent of any future changes to the viewport/workspace code. -- Jeremy Hankins <[email protected]>
