Re: How can I start urxvt as fullscreen ?

[Jeremy Hankins <nowan nowan org>]

Teika Kazura <teika lavabit com> writes:
> Hi, Jeremy.
>
> On Thu, 23 Jul 2009 12:50:50 -0500, Jeremy Hankins wrote:
>> [Nice patch]
>
> I've got some questions on viewport-windows and related.
> 1. Iconified windows are returned, too, but is it ok? I don't 
>    iconify windows, so I'm not sure. I assume that if someone
>    iconifies window, then he/she wants to handle more windows
>    there. window-visible-p filters out iconified window.

My thought was that if an iconified window is in a vp it means that
something is being done there, or has been done there at some point, so
the vp isn't truly unused.  I'm not really sure what use scenario would
leave a vp empty except for an iconified window, but if a new-viewport
window goes there and then the iconified window is uniconified the
window that requested a new vp would be sharing a vp with the
uniconified window, which seems to me contrary to the request for a new
vp.

> 2. Sticky and viewport-sticky windows are returned, too. But for
>    new-viewport, it's better to ignore them. (workspace-empty-p
>    exclueds sticky.) Can you afford to fix them?

I probably should.  For the version in the patch I don't think it makes
much difference -- the only scenario I can think of where it would is
where a sticky window is large and extends into multiple viewports.
Otherwise the sticky window will always be in the current viewport,
which will get the new-viewport window anyway if there isn't another
free vp.  But if a new-viewport is going to be created if an empty vp
isn't found the code should be sure to return the current vp as empty if
it only has sticky windows.

>> That's probably not ideal, but I'm unclear enough on the big picture
>> that I'm not sure what the best behavior would be.
>
> No one is (or they know but don't tell us :). But your code seems to
> give one of correct answers. Maybe we can have (as Chris and I
> suggested) a new option "new-viewport puts window, if no viewport is
> empty, 1. in current VP 2. enlarge VP, and puts there"

Well, my concern is with the fact that the viewport-dimensions would be
growing, but there's no mechanism in place for it to shrink.  So I've
been thinking of doing something like adding a 'dynamic mode for
viewport-boundary-mode, in which any attempt to go past the
viewport-dimensions would grow them, but that they're also shrunk once
viewports aren't in use.  I think I've got the major part of the code to
do this written: a function that resizes viewport-dimensions and adjusts
viewport-x-offset and viewport-y-offset appropriately to include the
current viewport and all windows in the current workspace.  Apart from
that it's just a matter of tweaking set-screen-viewport appropriately,
and handling switching workspaces.

There are a couple problems with it yet (though I think they're limited
to using sawfish-pager), and one thing I'm not sure of: what to do with
user-set viewport-dimensions?  My thought is that they should become a
sort of minimum-viewport-size below which viewport-dimensions will never
shrink.  But should that be done by adding a second customize variable
(e.g., viewport-minimum-dimensions), or by separating the user-requested
viewport-dimensions from the internal (i.e., actual)
viewport-dimensions?  The former would be easier, but possibly more
confusing in terms of user-interface.

-- 
Jeremy Hankins <nowan nowan org>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03