New 'viewport shifted hook' ?

[Teika Kazura]

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.)

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.

An alternative is to set the value to new global variable
'viewport-shift' during the call of viewport-resize-hook.

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?

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.

Regards,
Teika (Teika kazura)

[Jeremy Hankins]

Teika Kazura <teika@...> 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@...>

[Teika Kazura]

Thanks, Jeremy, for close reply. (I have to learn from your attitude. :)

On Sun, 01 Nov 2009 09:40:44 -0600, Jeremy Hankins wrote:
>> In dynamic VP, when you go left or up and the VP is enlarged, all
>> windows are "shifted" to right or down, right?
>
>Sort of.  All windows are shifted _every_ time the vp is moved,

My question was ambiguous, but at the same time, it was "intuitively
correct".

# I think we need nomenclature refinement and better VP concept
# tutorial in future. E.g. VP can mean both 'the current VP' and 'the
# whole virtual desktop'. Not only distinction, but concise and
# self-descriptive names are wanted.

Maybe I've mixed up the question by referring to WS, and have confused
you, but I think the shift that I asked you about is inherent to each
WS, and that simply emitting shift signal, via hook or global variable
works. In another words, shift *is there* if it's done within WS.
On the other hand, shift accompanied when witching the WS has to be
hidden from users.

> One other idea [...]: 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).

Thanks for proposal, but I asked since I just wanted "better Sawfish",
and I don't need dynamic VP now. :) The API I asked is quite natural,
isn't it?

In fact, if I remember correctly, I first implemented the way you
said, but it didn't work, so I chose to explicitly keep record of the
former window. (Remember "stack/focus code via hook doesn't work!"
argument?)  And I want to keep the mouse pointer location for each VP,
so shift detection is desired.

Anyway, it's not critical, so we don't have to hurry.


Now let's continue VP discussion.

>> VP size is common to all WS, so shift is common, too?
>
> No, though before dynamic workspaces it was.

Ah. (sigh) I've browsed VP-*-WS-handler functions in wm/viewport.jl.
You were careful enough not to break the conventional
definition. Thanks a lot for that. But my first impression is that
there must be a better definition, by being consistent - not affected
whether it is dynamic or not - so that it's clearer for coders. Of
course, definition changes annoy people and make existing scripts
unavailable, so you can't say it's unconditionally better.

Logically, it's possible desing that each WS has independent VP
size, but I don't know if it's desired in practice. Unnecesarily
extension will be the waste of our limited power.

We shouldn't embark on this problem right now, because it can take
long. (And I'm tired right now. ;) I've been seeking what will be good
VP definitions. (Seen little progress from the beginning of '09. :-P
I was already perplexed before dynamic VP was introduced, mainly due
to infinite-desktop. You relaxed ID's difficutly a bit with dynamic VP,
but the latter is difficult, too.)

For one thing, it seems to me that there must be better distinctions
between what should be disclosed and what's internal to the
module. For example, I think VP dim shouldn't be a global
variable. Instead, it has to be accessed via funcs.

If the current implementation is to stay, we have to write down the
spec in the news.texi. But I'm inclined to mark the dynamic VP as:
"the specification may change in future". It's not bad at all to ship
experimental features, as long as it's declared as experimental, and
it will be settled.

> 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 didn't know that, but it must not be a problem at all. If nothing
is necessary, then each hook function doesn't do anything, if they're
correctly written. (My understanding is not enough to think of
a counterexample, though.)

I'll review unread ML messages on VP in Sep and Oct. That's all for
now.

Regards,
Teika (Teika kazura)

[Jeremy Hankins]

Teika Kazura <teika@...> writes:

> Thanks, Jeremy, for close reply. (I have to learn from your
> attitude. :)
>
> On Sun, 01 Nov 2009 09:40:44 -0600, Jeremy Hankins wrote:
>>> In dynamic VP, when you go left or up and the VP is enlarged, all
>>> windows are "shifted" to right or down, right?
>>
>>Sort of.  All windows are shifted _every_ time the vp is moved,
>
> My question was ambiguous, but at the same time, it was "intuitively
> correct".
>
> # I think we need nomenclature refinement and better VP concept
> # tutorial in future. E.g. VP can mean both 'the current VP' and 'the
> # whole virtual desktop'. Not only distinction, but concise and
> # self-descriptive names are wanted.

Hm?  I'm not sure I understand.  My understanding:

 - virtual workspace: a larger-than-screen-size working area where
   windows can be placed.
 - viewport: a screen-sized subsection of a virtual workspace

Of course, both of these are part of the viewports subsystem, and
separate from the workspaces subsystem....  So yeah, there's a bit of
confusing terminology.  ;) I don't know better terms, though.

> Maybe I've mixed up the question by referring to WS, and have confused
> you, but I think the shift that I asked you about is inherent to each
> WS, and that simply emitting shift signal, via hook or global variable
> works. In another words, shift *is there* if it's done within WS.
> On the other hand, shift accompanied when witching the WS has to be
> hidden from users.

If I understand what you were asking, the shift you were asking about
doesn't happen at all.  From the perspective of the code there's nothing
different about increasing the virt. workspace size to the left or top
than there is to the right or bottom.  Every time you switch from one
viewport to another the entire virtual workspace boundaries are
recalculated.

>> One other idea [...]: 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).
>
> Thanks for proposal, but I asked since I just wanted "better Sawfish",
> and I don't need dynamic VP now. :) The API I asked is quite natural,
> isn't it?

Personally I don't see the need for viewports to have static/persistent
addresses or names.  If you want that you should use workspaces.  Giving
viewports static addresses could be done, I guess, but it doesn't seem
worth it to me, and it doesn't really make sense in the viewport
framework.  What's the static address for a viewport halfway between 0,0
and 0,1 -- i.e., overlapping both?

> In fact, if I remember correctly, I first implemented the way you
> said, but it didn't work, so I chose to explicitly keep record of the
> former window. (Remember "stack/focus code via hook doesn't work!"
> argument?)  And I want to keep the mouse pointer location for each VP,
> so shift detection is desired.

Is it that a window was focused in the new vp before the script had a
chance to choose one?

> Anyway, it's not critical, so we don't have to hurry.

Ok.

> Now let's continue VP discussion.
>
>>> VP size is common to all WS, so shift is common, too?
>>
>> No, though before dynamic workspaces it was.
                             ^^^^^^^^^^

Woops -- that should be dynamic viewports, not workspaces.  Is that what
you meant by breaking conventional definitions?  I mis-typed, I'm
afraid... :P

> Ah. (sigh) I've browsed VP-*-WS-handler functions in wm/viewport.jl.
> You were careful enough not to break the conventional
> definition. Thanks a lot for that. But my first impression is that
> there must be a better definition, by being consistent - not affected
> whether it is dynamic or not - so that it's clearer for coders. Of
> course, definition changes annoy people and make existing scripts
> unavailable, so you can't say it's unconditionally better.

I don't know what you're referring to.

> Logically, it's possible desing that each WS has independent VP
> size, but I don't know if it's desired in practice. Unnecesarily
> extension will be the waste of our limited power.

Giving each workspace an independent vp setup was necessary, and not
difficult.  The problem before was that the virtual workspaces on two
different workspaces (I see what you mean about confusing terminology!)
could drift apart.  If on one workspace you always are deleting
viewports on the left and creating them on the right, but on another
you're deleting them on the right and creating them on the left,
switching from one workspace to the other would leave you several
viewports away from any windows.

There are some somewhat complicated corner cases, from a user interface
perspective, and unfortunately I'm not certain I've got them worked out
properly.  For example, if you turn dynamic viewports on, create windows
in multiple viewports in different workspaces, and then turn dynamic
viewports off you can end up with differently sized virtual workspaces
on different workspaces despite the fact that you have a set viewport
size.  But such a scenario can't be all that common, and frankly I don't
know what would be the proper thing to do to avoid it.

> We shouldn't embark on this problem right now, because it can take
> long. (And I'm tired right now. ;) I've been seeking what will be good
> VP definitions. (Seen little progress from the beginning of '09. :-P
> I was already perplexed before dynamic VP was introduced, mainly due
> to infinite-desktop. You relaxed ID's difficutly a bit with dynamic VP,
> but the latter is difficult, too.)

No, I'm not doing much of anything lately -- personal stuff has
intervened.

> For one thing, it seems to me that there must be better distinctions
> between what should be disclosed and what's internal to the
> module. For example, I think VP dim shouldn't be a global
> variable. Instead, it has to be accessed via funcs.

That's true.  If it were only settable via function calls that would
make things much simpler.

--
Jeremy Hankins <nowan@...>

[Teika Kazura]

On Tue, 03 Nov 2009 14:07:38 -0600, Jeremy Hankins wrote:

> Teika Kazura <teika@...> writes:
>> # I think we need nomenclature refinement and better VP concept
>> # tutorial in future. E.g. VP can mean both 'the current VP' and 'the
>> # whole virtual desktop'. Not only distinction, but concise and
>> # self-descriptive names are wanted.
>
> Hm?  I'm not sure I understand.  My understanding:
>
>  - virtual workspace: a larger-than-screen-size working area where
>    windows can be placed.
>  - viewport: a screen-sized subsection of a virtual workspace

Now I've had a browse in ewmh-1.4, and it uses "large desktop" and
"viewport". OK. But the "virtual desktop" is used for Sawfish's
"workspace". Wow. I used to use "virtual desktop" for "large
desktop". (Sorry for bringing in another headache. Let's forget it
until 1.6 release. ;)

The current Sawfish's definition is wrong, as I pointed out. For
example, 'viewport-dimensions' is used, which should really be named
'virtual-desktop-dimension' or so. (For this example, both "large
desktop" and "virtual desktop" are acceptable.)

And it is better to let developers and users know which concepts are
confusing, and how mistakes are avoided. Good manuals should cover
such things, too. (We don't do it right now.)

>> I think the shift that I asked you about is inherent to each WS,
>> and that simply emitting shift signal, via hook or global variable
>> works. In another words, shift *is there* if it's done within WS.
>> On the other hand, shift accompanied when witching the WS has to be
>> hidden from users.
>
> If I understand what you were asking, the shift you were asking about
> doesn't happen at all.

You know, assume that (screen-viewport) returns '(0. 0). Now you go
left, and it remains '(0 . 0). (Sorry, from the beginning I
should have said this.) Perhaps both you and I are correct, and the
definition lacks consistency. But I haven't dug into VP codes, and I'm
not sure.

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?

>> Ah. (sigh) I've browsed VP-*-WS-handler functions in wm/viewport.jl.
>> You were careful enough not to break the conventional
>> definition. Thanks a lot for that. But my first impression is that
>> there must be a better definition, by being consistent - not affected
>> whether it is dynamic or not - so that it's clearer for coders. Of
>> course, definition changes annoy people and make existing scripts
>> unavailable, so you can't say it's unconditionally better.
>
> I don't know what you're referring to.

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.)

It is a hidden spec change, so it must be described. (Well, but it has
been implicitly assumed that virtual desktop size is common to all
WS. One reason is that John Harper didn't like VP, and hid it from
users. It's recent that Chris resurrected it.)

> There are some somewhat complicated corner cases, from a user interface
> perspective, and unfortunately I'm not certain I've got them worked out
> properly.  For example, if you turn dynamic viewports on, create windows
> in multiple viewports in different workspaces, and then turn dynamic
> viewports off you can end up with differently sized virtual workspaces
> on different workspaces despite the fact that you have a set viewport
> size.  But such a scenario can't be all that common, and frankly I don't
> know what would be the proper thing to do to avoid it.

Let's forget it. Dynamic-or-not is "usually" a "slow" option which
users don't change so often. If you're perfectionist, you have to do
really many things. But let's not do this kind of things.


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."

The dynamic, and plain VP is difficult enough for me, and doesn't seem
to be a piece of cake even for Jeremy, either, who understands best
the VP.

> No, I'm not doing much of anything lately -- personal stuff has
> intervened.

It may be obvious, but no one forces nothing. :)

Regards,
Teika (Teika kazura)

[Jeremy Hankins]

Teika Kazura <teika@...> 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@...>