Re: New 'viewport shifted hook' ?

[Jeremy Hankins <nowan nowan org>]

Teika Kazura <teika lavabit com> 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 <nowan nowan org>