On Mon, 2006-12-11 at 22:48 -0700, Mike Cook wrote: > On Fri, 2006-12-11 at 21:32 -0700, David Reveman wrote: > > After looking at this I found the correct solution to be to just snap to > > window struts instead of any workarea. I've pushed out changes that > > should take care of this. I don't have access to a multi-head setup > > right now so I can't verify that it works OK. Please give it a try. > > Hm, somebody will have to donate a couple extra monitors... ;) After a quick > first test on a single head machine I think there's a typo, as it seems to be > ignoring the struts and just snapping to screen edges for me. Also, I'm not > sure if the struts are the best option-- more on that below...
:) Don't worry, I have a multi-head setup at my office. I'm just not there right now. You're right, a typo caused it to not work at all. It should be fixed now. While looking at this I also found an issue that caused snapping to normal windows to be a bit incorrect, it should be correct now. > > > I've included a few more window types in snapping. However, including > > dock windows is probably not a good idea. Sometime windows with dock > > type and below state are used for windows that shouldn't have any > > decorations and stick to the desktop. We don't want to snap to those. > > Ah, yeah, I wasn't sure if dock type might be used like that. > > > > I personally think we should include these "inner" struts when > > > calculating the > > > workarea for each output (which also helps window maximizing), and only > > > ignore them in the screen workarea case (for the _NET_WORKAREA hint). > > > > What do you mean by "inner" struts? Each workarea rectangle should be > > the maximum rectangle that doesn't intersect any struts. If that's > > currently not the case, it should be fixed. > > Sorry, by "inner struts" I was trying to refer to those on the inside edge > between > two outputs. Say I have 2 monitors, and I have a vertical dock covering the > right edge of the left monitor, or the left edge of the right monitor-- > basically > down the middle of the screen. Those type seem to be currently ignored. OK, lets find out why they are ignored then. What struts are those vertical dock windows using? If those windows are not just setting any strut hints, then it's not much we can do. > > > If the workarea isn't good enough for a plugin it should instead look at > > the strut hints for each window like the wobbly plugin is now doing. We > > can add a region to the output struct that is the output area minus all > > window struts if that turns out useful for plugins. > > I can't think of any time the output's workarea wouldn't work, as however > that is > calculated we should probably use it to be consistent. Here are the issues I > ran into as I was trying to work on this: > 1- Struts that are on those "inner" edges like I described before are > currently > ignored in the output workarea calculation. So, for instance, a window > will > maximize to the output edge under that dock. This shouldn't happen. I'll make sure it gets fixed once I know why it currently doesn't work. > 2- A dock may cover the top or bottom of only one output. That strut should > not be considered when snapping or maximizing on a different output. Why this behavior? > 3- In the case of the total screen's workarea we should ignore those in #1 and > clip to those in #2 to have the largest total area (at least until the > workarea > hint can handle multiple regions, or whatever other solution the spec comes > up with). The screen workarea could be the current outputs workarea and be updated as the current output changes. This might confuse desktop windows, though. > 4- Also, say you have two or three panels across the top of an output. You > wouldn't want to snap to each one separately, but just to the lowest one, > which should be what the output workarea calculation would give you. I would want to snap to each one separately and have windows placed smarter then just in the workarea rectangle. Windows should still be maximized to the workarea rectangle, of course. > > 5- And finally, in the patch I was intending that a window also snaps to the > edges of each output, which is the current behavior that I get with > metacity, > I believe. I agree, snapping to output edges makes sense. I can easily make the current wobbly code do that. > > So, in the end, that's why I was thinking that each output workarea would be > the best region to snap to, if they include calculations for all the struts > at any > edge within that output. That then also covers snapping to the output edges > (strut or not). Sorry for the long response... ;) > There's clearly some more work to be done here and I appreciate your help with getting this right. Thanks, -David _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
