Teika Kazura <[email protected]> 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 <[email protected]> PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
