Re: New 'viewport shifted hook' ?

[Jeremy Hankins <nowan nowan org>]

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