On Sat, Oct 09, 2010 at 02:28:11PM +0200, Dominik Vogt wrote:
> The attached patch mostly fixes the problem. However, there is one
> thing left to think about:
Ah -- you're too fast for me. :) I've a similar patch to yours sat here.
> Normally, an application is not allowed to move a shaded window,
> but is is allowed to resize it. That is in order to not confuse
> the user with shaded windows jumping around.
>
> However, if a window has northwest gravity and is shaded to the
> right and the application increases its width by, say, 200 pixels,
> then the window shade jumps 200 pixels to the right. Since
> windows are often shaded to the page's border, the window shade
> even jumps to a different page.
In some cases (perhaps due to snapattraction, not sure; not bothered to
look), if the shaded window was snapped to the screen edge completely, the
window then didn't move at all. (I suppose, I should say then, that if the
window, when shaded was outside the panframe, then it would move, but if it
were inside it, then it didn't move.)
I am unsure if this is a bug in its own right to be honest.
> This effect can always happen if the gravity of the window shade
> is different from the gravity of the unshaded window, e.g. the
> window has north... gravity and is shaded to the bottom,
> bottom left or bottom right etc.
>
> There are thre options that all have drawbacks:
>
> 1. Use the window's gravity if a shaded window is resized.
> ==> The current jumping window effect implemented with the
> patch.
>
>
> 2. Override the window's gravity with the window shade direction,
> i.e. NW becomes NE on a window shaded to the right and SW on a
> window shaded to the bottom etc.
> ==> The window may have moved to a funny place after unshading,
> for example partially off screen.
But doesn't this happen at the moment, anyway? I've seen some odd results
like this with shaded windows, but then I figure that's OK because when I am
moving a shaded window around, and the unshade it again, I never know
necessarily what the overall size of the window is going to be anyway. So I
always expect it to be partially off-screen.
> ==> Requires some careful coding in
> event.c:__handle_cr_on_client().
> 3. Forbid resizing of shaded window (possibly only if gravities do
> not match).
> ==> Limits fvwm's behaviour in many useful cases.
Nah -- this would be too annoying.
> I think I prefer solution 2 because although the window might end
> up in a different position than it would have if it had been
> resized without being shaded, this may be the least surprising
> solution for the user as unshading is a process with a result that
> is easy to understand.
>
> However, I'd like to hear some more opinions.
I'll go with 2.
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
