Viewport scrambling bug

[Jeremy Hankins]

Ok, I think I've fixed the viewport scrambling bug.  There were two,
actually: one that maximizing a window shifted the viewport, the other
was that the position setter would always put a window in the first
viewport.

I've got a local branch with fixes for these, as well as a minor tweak
to infinite-desktop (stop-at-workspace-borders is no longer a settable
option, instead it depends on whether viewport-boundary-mode is
dynamic).  But I'd appreciate it if particularly the maximize/unmaximize
stuff could be tested by others than myself.  Shall I go ahead and push
it to origin/master, send out a patch, figure out how to create a new
branch on the git server, or what?

--
Jeremy Hankins <nowan@...>

[Flashrider]

Am Sonntag, den 11.10.2009, 20:45 -0500 schrieb Jeremy Hankins:

> Ok, I think I've fixed the viewport scrambling bug.  There were two,
> actually: one that maximizing a window shifted the viewport, the other
> was that the position setter would always put a window in the first
> viewport.
>
> I've got a local branch with fixes for these, as well as a minor tweak
> to infinite-desktop (stop-at-workspace-borders is no longer a settable
> option, instead it depends on whether viewport-boundary-mode is
> dynamic).  But I'd appreciate it if particularly the maximize/unmaximize
> stuff could be tested by others than myself.  Shall I go ahead and push
> it to origin/master, send out a patch, figure out how to create a new
> branch on the git server, or what?
>

patch or new branch.

[Jeremy Hankins]

Christopher Roy Bratusek <zanghar@...> writes:

> patch or new branch.

Ok, it's up on the server as the 'viewport' branch.

--
Jeremy Hankins <nowan@...>

[Flashrider]

Am Montag, den 12.10.2009, 07:55 -0500 schrieb Jeremy Hankins:
> Christopher Roy Bratusek <zanghar@...> writes:
>
> > patch or new branch.
>
> Ok, it's up on the server as the 'viewport' branch.
>

Just tried it, and found two issues:

a) maximized windows not on vp 0:0 become unmaximized
        (if the window on 0:0 is maximized it stays so)
        that led to another column of viewports beeing
        created on my system as synaptic got positioned
        overlapping it's viewports edges while unmaximize
        that should be fixed, forgetting maximized state
        is sub-optimal.

b) I have window-history activated and when starting
        evolution it gave me:
                Bad argument: #<subr head-dimensions>, (), 1
        that should also be fixed, as I haven't been able to perform
        any action on evolution (WM action) before I let sawfish
        forget its state. Though that may be hard to reproduce.

except that, good work.

Chris

PS: don't forget man/sawfish.texi when adding new stuff ;)

[Jeremy Hankins]

Christopher Roy Bratusek <zanghar@...> writes:

> Just tried it, and found two issues:
>
> a) maximized windows not on vp 0:0 become unmaximized
> (if the window on 0:0 is maximized it stays so)
> that led to another column of viewports beeing
> created on my system as synaptic got positioned
> overlapping it's viewports edges while unmaximize
> that should be fixed, forgetting maximized state
> is sub-optimal.

You mean that maximized windows on other viewports become unmaximized on
restart?  Hmm...  I hadn't seen that, but after some playing around I've
been able to reproduce it.  Seems to happen when a window is maximized
in one direction and then maximized in another as well....

> b) I have window-history activated and when starting
> evolution it gave me:
> Bad argument: #<subr head-dimensions>, (), 1
> that should also be fixed, as I haven't been able to perform
> any action on evolution (WM action) before I let sawfish
> forget its state. Though that may be hard to reproduce.

I saw the same error once (when maximizing virtualbox on a new
workspace), but haven't been able to reproduce it since.  It's probably
in maximize-window-fullscreen, probably because the find-head call there
is returning nil for some reason.  Maybe some kind of timing issue --
both virtualbox and evolution are rather heavy...?  If you can come up
with a way to reproduce it let me know.

> PS: don't forget man/sawfish.texi when adding new stuff ;)

Oh, yeah, I should do that.  Thanks!

--
Jeremy Hankins <nowan@...>

[Flashrider]

Am Freitag, den 16.10.2009, 14:06 -0500 schrieb Jeremy Hankins:

> Christopher Roy Bratusek <zanghar@...> writes:
>
> > Just tried it, and found two issues:
> >
> > a) maximized windows not on vp 0:0 become unmaximized
> > (if the window on 0:0 is maximized it stays so)
> > that led to another column of viewports beeing
> > created on my system as synaptic got positioned
> > overlapping it's viewports edges while unmaximize
> > that should be fixed, forgetting maximized state
> > is sub-optimal.
>
> You mean that maximized windows on other viewports become unmaximized on
> restart?  Hmm...  I hadn't seen that, but after some playing around I've
> been able to reproduce it.  Seems to happen when a window is maximized
> in one direction and then maximized in another as well....
>
> > b) I have window-history activated and when starting
> > evolution it gave me:
> > Bad argument: #<subr head-dimensions>, (), 1
> > that should also be fixed, as I haven't been able to perform
> > any action on evolution (WM action) before I let sawfish
> > forget its state. Though that may be hard to reproduce.
>
> I saw the same error once (when maximizing virtualbox on a new
> workspace), but haven't been able to reproduce it since.  It's probably
> in maximize-window-fullscreen, probably because the find-head call there
> is returning nil for some reason.  Maybe some kind of timing issue --
> both virtualbox and evolution are rather heavy...?  If you can come up
> with a way to reproduce it let me know.

same for iceweasel (artist formerly known as firefox for debian).
        `rm -f .sawfish/window-history'
solves the issue, though not recommended, it so or so wanted to do it,
as my version of the file was pretty old and it stored values for all
the apps I've tested, well know I have a minimal install (1 app for
everything), so I wanted to get rid of that file so or so.

> > PS: don't forget man/sawfish.texi when adding new stuff ;)
>
> Oh, yeah, I should do that.  Thanks!
>

[Jeremy Hankins]

Christopher Roy Bratusek <zanghar@...> writes:
> Am Freitag, den 16.10.2009, 14:06 -0500 schrieb Jeremy Hankins:
>> Christopher Roy Bratusek <zanghar@...> writes:

>> > b) I have window-history activated and when starting
>> > evolution it gave me:
>> > Bad argument: #<subr head-dimensions>, (), 1
>> > that should also be fixed, as I haven't been able to perform
>> > any action on evolution (WM action) before I let sawfish
>> > forget its state. Though that may be hard to reproduce.
>>
>> I saw the same error once (when maximizing virtualbox on a new
>> workspace), but haven't been able to reproduce it since.  It's probably
>> in maximize-window-fullscreen, probably because the find-head call there
>> is returning nil for some reason.  Maybe some kind of timing issue --
>> both virtualbox and evolution are rather heavy...?  If you can come up
>> with a way to reproduce it let me know.
>
> same for iceweasel (artist formerly known as firefox for debian).
> `rm -f .sawfish/window-history'
> solves the issue, though not recommended, it so or so wanted to do it,
> as my version of the file was pretty old and it stored values for all
> the apps I've tested, well know I have a minimal install (1 app for
> everything), so I wanted to get rid of that file so or so.

So now that you've deleted the history file the problem has gone away
entirely, or do you have to delete it every time?

--
Jeremy Hankins <nowan@...>

[Flashrider]

Am Freitag, den 16.10.2009, 14:23 -0500 schrieb Jeremy Hankins:

> Christopher Roy Bratusek <zanghar@...> writes:
> > Am Freitag, den 16.10.2009, 14:06 -0500 schrieb Jeremy Hankins:
> >> Christopher Roy Bratusek <zanghar@...> writes:
>
> >> > b) I have window-history activated and when starting
> >> > evolution it gave me:
> >> > Bad argument: #<subr head-dimensions>, (), 1
> >> > that should also be fixed, as I haven't been able to perform
> >> > any action on evolution (WM action) before I let sawfish
> >> > forget its state. Though that may be hard to reproduce.
> >>
> >> I saw the same error once (when maximizing virtualbox on a new
> >> workspace), but haven't been able to reproduce it since.  It's probably
> >> in maximize-window-fullscreen, probably because the find-head call there
> >> is returning nil for some reason.  Maybe some kind of timing issue --
> >> both virtualbox and evolution are rather heavy...?  If you can come up
> >> with a way to reproduce it let me know.
> >
> > same for iceweasel (artist formerly known as firefox for debian).
> > `rm -f .sawfish/window-history'
> > solves the issue, though not recommended, it so or so wanted to do it,
> > as my version of the file was pretty old and it stored values for all
> > the apps I've tested, well know I have a minimal install (1 app for
> > everything), so I wanted to get rid of that file so or so.
>
> So now that you've deleted the history file the problem has gone away
> entirely, or do you have to delete it every time?
>

entirely.

[Teika Kazura]

Hi.

On Fri, 16 Oct 2009 14:06:45 -0500, Jeremy Hankins wrote:

>> a) maximized windows not on vp 0:0 become unmaximized
>> (if the window on 0:0 is maximized it stays so)
>> that led to another column of viewports beeing
>> created on my system as synaptic got positioned
>> overlapping it's viewports edges while unmaximize
>> that should be fixed, forgetting maximized state
>> is sub-optimal.
>
> You mean that maximized windows on other viewports become unmaximized on
> restart?  Hmm...  I hadn't seen that, but after some playing around I've
> been able to reproduce it.  Seems to happen when a window is maximized
> in one direction and then maximized in another as well....

In fact, (window-maximized-p w) returns t for them. So they are maximized,
but Only the size is set wrongly.

It doesn't matter what maximizes the window - if it is the matcher or
not. For me, it's the only loose end. Thanks a lot!

Any guess for the cause? (Me nothing ;) Thank you beforehand.
Teika (Teika kazura)

[Teika Kazura]

Hi.

On Sun, 11 Oct 2009 20:45:05 -0500, Jeremy Hankins wrote:
> a minor tweak to infinite-desktop (stop-at-workspace-borders is no
> longer a settable option, instead it depends on whether
> viewport-boundary-mode is dynamic).

Oh, this is not minor. Previously, the default behavior of ID was to
ignore the VP size. But now, it is confined, and explicitly needs
dynamic VP to go far endlessly.

This is a good change. Smooth scroll of the virtual desktop by mouse
has nothing to do with VP infiniteness.

Thus the name 'infinite-desktop' does not make sense any more. But if
the name is to be changed, it should be done carefully.

And Jeremy, it's a bit buggy. Some users put in ~/.sawfishrc,
(define-special-variable infinite-desktop.stop-at-workspace-borders
nil) because it was a variable. (nil can be t) But now, it is a
function, so (infinite-desktop.stop-at-workspace-borders) returns an
error, as Invalid function: ()

Elisp can bind one name to both function and variable, but librep is
not. So (setq foo (lambda ...)) (foo) works. (I guess you know.:)

I propose to rename 'infinite-desktop.stop-at-workspace-borders' to
'stop-at-workspace-borders' (prefix is dropped), and move it into
viewport.jl.  So, if user sets a value to
'infinite-desktop.stop-at-workspace-borders', then it has no effect.

It's because since in future, edge-flip should be combined to other VP
features. My proposal enables for edge-flip functions to use
'stop-at-workspace-borders'


If you put an unused custom-var in wm/util/compat.jl, then the var is
deleted from ~/.sawfish/custom, and the value is not upon reading, as
it seems. So let's do it. What I said above is explicit setq blah,
and it can't be prevented with compat.jl, though.

Thanks a lot, Jeremy. Now VP is far better than it used to be.

Regards,
Teika (Teika kazura)

[Jeremy Hankins]

Teika Kazura <teika@...> writes:

> Hi.
>
> On Sun, 11 Oct 2009 20:45:05 -0500, Jeremy Hankins wrote:
>> a minor tweak to infinite-desktop (stop-at-workspace-borders is no
>> longer a settable option, instead it depends on whether
>> viewport-boundary-mode is dynamic).
>
> Oh, this is not minor. Previously, the default behavior of ID was to
> ignore the VP size. But now, it is confined, and explicitly needs
> dynamic VP to go far endlessly.

This is true -- for some reason I thought the previous default was to
stop, but apparently it was not.  So the default behavior will change,
since the default is not to have dynamic viewports.  I've added a note
in man/news.texi to that effect.

> This is a good change. Smooth scroll of the virtual desktop by mouse
> has nothing to do with VP infiniteness.
>
> Thus the name 'infinite-desktop' does not make sense any more. But if
> the name is to be changed, it should be done carefully.

This should probably be part of the general rationalization of module
names that Chris talked about.  Frankly I don't see any way of doing it
that doesn't cause problems, so better that all changes happen at the
same time so that users can be warned.

> And Jeremy, it's a bit buggy. Some users put in ~/.sawfishrc,
> (define-special-variable infinite-desktop.stop-at-workspace-borders
> nil) because it was a variable. (nil can be t) But now, it is a
> function, so (infinite-desktop.stop-at-workspace-borders) returns an
> error, as Invalid function: ()

This I don't think is a problem.  I get scope issues wrong from time to
time with rep, but my understanding is that since
infinite-desktop.stop-at-workspace-borders is a define (not a defun) and
not included in the export statement it should override any other
definition of the same symbol while in infinite-desktop.  When I tested
it just now, by opening up sawfish-client and running:

(define-special-variable infinite-desktop.stop-at-workspace-borders nil)
(require 'sawfish.wm.ext.infinite-desktop)

I got the expected behavior -- that smooth scroll didn't stop at
workspace borders, since I have dynamic viewports on.  Turning dynamic
viewports off changed the behavior, as I expected.  If you know of a way
to trigger a bug I'd be interested -- to improve my understanding of rep
scope... ;)

> I propose to rename 'infinite-desktop.stop-at-workspace-borders' to
> 'stop-at-workspace-borders' (prefix is dropped), and move it into
> viewport.jl.  So, if user sets a value to
> 'infinite-desktop.stop-at-workspace-borders', then it has no effect.

Making the name change is probably a good idea even if I'm right about
the scope, for reasons of readability.  And I think you're right, it
should be in viewports, so that anything else that might need that
information can use it.

So in my local branch I've changed it viewport-honor-workspace-edges (to
make it clear it's a viewport function).  It'll be included in my next
push to the viewport branch, once I get the current bugs figured out.

> If you put an unused custom-var in wm/util/compat.jl, then the var is
> deleted from ~/.sawfish/custom, and the value is not upon reading, as
> it seems. So let's do it. What I said above is explicit setq blah,
> and it can't be prevented with compat.jl, though.

I'll make this change as well.

--
Jeremy Hankins <nowan@...>

[Jeremy Hankins]

Teika Kazura <teika@...> writes:

> In fact, (window-maximized-p w) returns t for them. So they are
> maximized, but Only the size is set wrongly.
>
> It doesn't matter what maximizes the window - if it is the matcher or
> not. For me, it's the only loose end. Thanks a lot!
>
> Any guess for the cause? (Me nothing ;) Thank you beforehand.
> Teika (Teika kazura)

My only guess so far is that it has something to do with the way in
which the unmaximized position and dimensions are saved.  I've also
noticed some inconsistent behavior when windows are unmaximized -- it
seems to be remembering old inaccurate positions.

I think I've got the other one fixed, though; it was triggered when a
window stuck off the edge of virtual-workspace to the top or left.
window-viewport would return the "wrong" viewport -- should be -1
(invalid viewport, but correct), but it gave 0 instead.

--
Jeremy Hankins <nowan@...>

[Jeremy Hankins]

What's proper behavior when maximizing a window that's across two
viewports?  Should it:

 1) maximize into the viewport of it's position -- i.e., of its upper
    left corner?  (Or of its gravity-determined corner?)

 2) maximize into the current viewport?  Presumably not unless at least
    one of the viewports it is currently visible from is the currently
    active viewport, so what about when it's not visible at all?  Fall
    back to #1?

 3) maximize into the viewport it's mostly in -- so if it's 30% in one
    and 70% in the other the 70% viewport gets the window.  That still
    leaves 50/50 cases, of course -- presumably this would fall back to
    #1 or #2.

The last option is definitely the most complicated, but it could be done
if that's really the best option.  The first option is the easiest
(that's the current behavior of my local branch), but probably not the
best.  I lean toward option #2, with a fall-back to #1 when the window
isn't visible at all.  This is closest to current behavior (in master),
I believe.

Bear in mind that this applies when a window is maximized by the user,
but it also applies when maximized windows are initially taken over at
sawfish (re)start -- this last will be the typical scenario for
maximizing windows that aren't visible.

--
Jeremy Hankins <nowan@...>

[Jeremy Hankins]

Jeremy Hankins <nowan@...> writes:

> What's proper behavior when maximizing a window that's across two
> viewports?  Should it:
>
>  1) maximize into the viewport of it's position -- i.e., of its upper
>     left corner?  (Or of its gravity-determined corner?)
>
>  2) maximize into the current viewport?  Presumably not unless at least
>     one of the viewports it is currently visible from is the currently
>     active viewport, so what about when it's not visible at all?  Fall
>     back to #1?
>
>  3) maximize into the viewport it's mostly in -- so if it's 30% in one
>     and 70% in the other the 70% viewport gets the window.  That still
>     leaves 50/50 cases, of course -- presumably this would fall back to
>     #1 or #2.

After having thought about this some more I decided that #3 with a
fallback to #1 is the best option.  #2 is bad because it makes it
unpredictable where the window will maximize since it depends on which
viewport is active.  #1 is bad because the typical case is probably
where a window is just a few pixels into the next viewport over -- a
viewport with just a few pixels of a window is definitely not the
viewport the window is in.

--
Jeremy Hankins <nowan@...>

[Flashrider]

Am Dienstag, den 20.10.2009, 09:40 -0500 schrieb Jeremy Hankins:

> Jeremy Hankins <nowan@...> writes:
> > What's proper behavior when maximizing a window that's across two
> > viewports?  Should it:
> >
> >  1) maximize into the viewport of it's position -- i.e., of its upper
> >     left corner?  (Or of its gravity-determined corner?)
> >
> >  2) maximize into the current viewport?  Presumably not unless at least
> >     one of the viewports it is currently visible from is the currently
> >     active viewport, so what about when it's not visible at all?  Fall
> >     back to #1?
> >
> >  3) maximize into the viewport it's mostly in -- so if it's 30% in one
> >     and 70% in the other the 70% viewport gets the window.  That still
> >     leaves 50/50 cases, of course -- presumably this would fall back to
> >     #1 or #2.
>
> After having thought about this some more I decided that #3 with a
> fallback to #1 is the best option.  #2 is bad because it makes it
> unpredictable where the window will maximize since it depends on which
> viewport is active.  #1 is bad because the typical case is probably
> where a window is just a few pixels into the next viewport over -- a
> viewport with just a few pixels of a window is definitely not the
> viewport the window is in.
>

+1