Re: New 'viewport shifted hook' ?

[Jeremy Hankins <nowan nowan org>]

Teika Kazura <teika lavabit com> writes:

> But on second thought, the solution I insisted may be a bad way; I
> said "since the top-left is always (0, 0), shift is there." But the
> correct way is to set it as (-1, 0), and there's no shift. Will this
> way cause another difficulty?

Hmm..  This would be better, I think.  It would involve replacing
viewport-dimensions with a combination of row-(min|max) and
col-(min|max), and would complicate the code in a few places (e.g., it's
important to realize that VP 0,0 may not exist).  Or perhaps it would be
better to make all low-level stuff coordinate based, and leave
row/column calculations as an overlay rather than the current mixture...
Anyway, this approach would transparently handle cases where dimensions
are increased by more than one row or column at a time.

My only question (and I'm happy to be guided by others here) is whether
it's worth it.  This is a significant change, and it's all for the sake
of having a unique identifier for a region of the virtual workspace, and
I'm not sure that's all that useful.  But this is something for later.

> For example, virtual desktop size is unique if you don't use dynamic
> viewport, but it is multi-valued in DVP (dynamic VP), per workspace,
> so, 'viewport-dimensions' is the *size of the current WS*.  But I
> think it's better to have a sole definition, not affected by whether
> VP is dynamic or not. (So the obvious solution is that even without
> DVP, each WS has its own size, and there's no global VP size. But
> this will need another brain exercise, and I don't like to do it.)

Technically it's multi-valued (i.e., per-WS values are stored) whether
or not you use DVP.  But if you aren't using DVP then dimension values
get reset when you enter the WS.  So viewport-dimensions is always the
size of the current WS.  There's only one use-scenario that would reveal
that values are stored when not using DVP:

 - On WS 2 create windows on multiple viewports.
 - Go to WS 1 and turn off DVP (if on) and set viewport-dimensions to 1,1.

Now if you immediately go to WS 2 both windows will be on the same
viewport, but if you switch back to DVP (or increase
viewport-dimensions) before doing so they will still be on separate
viewports.

> Now let me propose this: let's put in the news section, "dynamic
> viewport is experimental. The specification and the implementation
> may change. But outside of dynamic VP, nothing has changed. Please
> let us know your opinions."

One thing has changed apart from dynamic VP, and that's that the current
VP is remembered for each workspace.  Besides, the big change that we've
talked about for the future is the viewport-dimensions variable, which
will affect anyone who uses viewports, not just those using dynamic
viewports (in fact, it will affect those using dynamic viewports very
little).

>> No, I'm not doing much of anything lately -- personal stuff has
>> intervened.
>
> It may be obvious, but no one forces nothing. :)

True, but I had hoped to be around to deal with any viewport issues.

-- 
Jeremy Hankins <nowan nowan org>