viewport definition glitch

[Teika Kazura]

Hi. Let me report another viewport definition glitch.

It's the dimension. We had had only one, "the dimension". Now we also
have "minimum" to support dynamic viewport. But what we really need is
one, "the initial dimension". And current VP size should be a plain
global variable, not a customizable one.  (It might be better not to
change the defcustom name for users.)  Thus, the # of options is one,
regardless the dynamic VP is used or not.

What makes the thing difficult is the sawfish-config (former
sawfish-ui). Currently it only supports defcustoms, and they are
saved. But it must be able to change the current VP size with
sawfish-config, if the user doesn't use dynamic viewport.

Well, it'll be easy if we simply drop the current VP size switch
from sawfish-config, and make user use dynamic VP to enlarge one.
(Shrink is not supported then.)

One problem is that what should be the size at restart. I think the VP
should be big enough to cover all windows.

It is bad to delete once accepted defcustom. Please be cautious.

Thank you for reading.
Teika (Teika kazura)

[Jeremy Hankins]

Teika Kazura <teika@...> writes:
> Hi. Let me report another viewport definition glitch.
>
> It's the dimension. We had had only one, "the dimension". Now we also
> have "minimum" to support dynamic viewport. But what we really need is
> one, "the initial dimension". And current VP size should be a plain
> global variable, not a customizable one.  (It might be better not to
> change the defcustom name for users.)  Thus, the # of options is one,
> regardless the dynamic VP is used or not.

Yes, this is a problem I did not know what to do with when I wrote the
dynamic viewports patch.

Currently if you set viewport-dimensions to less than
viewport-minimum-dimensions it decreases v-m-d, and if you set v-m-d to
more than v-d it increases v-d.  All this is whether you are using
dynamic viewports or not.

I thought about naming it viewport-default-dimensions, but chose
viewport-minimum-dimensions because v-d can be more than, but never less
than, v-m-d.

> What makes the thing difficult is the sawfish-config (former
> sawfish-ui). Currently it only supports defcustoms, and they are
> saved. But it must be able to change the current VP size with
> sawfish-config, if the user doesn't use dynamic viewport.

I don't know that this is a problem.  The custom interface can call a
function (and in this case it does) when the variable is set, so the
variable could be a minimum if dynamic viewports is used, and a set
value otherwise.  That wouldn't be a big change from current behavior; a
fairly minor change to the code and removing viewport-dimensions from
the config interface would do it.  But my worry is what will happen to
the ~/.sawfish/custom files that specify viewport-dimensions.  What will
happen when those custom files specify changes to viewport-dimensions,
but that's no longer the way things are done?

> Well, it'll be easy if we simply drop the current VP size switch
> from sawfish-config, and make user use dynamic VP to enlarge one.
> (Shrink is not supported then.)

Under dynamic viewports shrinking is supported -- as soon as a row or
column is no longer in use it is removed, down to
viewport-minimum-dimensions.

> One problem is that what should be the size at restart. I think the VP
> should be big enough to cover all windows.

Yes, this is something that shouldn't be hard to fix, I just haven't yet
tracked down how to do it.  The viewport-dynamic-resize function does
exactly that: resize the virtual workspace (i.e., viewport-dimensions,
viewport-[xy]-offset, etc.) to include all windows as well as the
current viewport.  It just needs to be run immediately on restart, and I
haven't yet figured out what hook, or where to make changes, to have
that happen.

> It is bad to delete once accepted defcustom. Please be cautious.

Yes!  ;)

--
Jeremy Hankins <nowan@...>