Re: New 'viewport shifted hook' ?

[Teika Kazura <teika lavabit com>]

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)