Viewport scrambling

[Jeremy Hankins]

I've pushed my latest viewport branch to the server.

It should fix the two bugs in the previous push, as well as another bug
due to a typo.  Also, since fixing the bug about maximizing windows in
both directions had me going through sawfish.wm.util.rects (which I'd
never looked at before) I went ahead and added a node to
man/sawfish.texi on it.

If it turns out that the current-head function is viewport-aware (though
I rather doubt it) I should remove the window-head-any-viewport
function.  But for now it's in there as well.

Please test, especially if you've got multiple heads.  A lot of the
stuff I was changing had to do with managing multiple heads, and I can't
test any of that myself.

--
Jeremy Hankins <nowan@...>

[Flashrider]

Am Mittwoch, den 21.10.2009, 10:20 -0500 schrieb Jeremy Hankins:

> I've pushed my latest viewport branch to the server.
>
> It should fix the two bugs in the previous push, as well as another bug
> due to a typo.  Also, since fixing the bug about maximizing windows in
> both directions had me going through sawfish.wm.util.rects (which I'd
> never looked at before) I went ahead and added a node to
> man/sawfish.texi on it.
>
> If it turns out that the current-head function is viewport-aware (though
> I rather doubt it) I should remove the window-head-any-viewport
> function.  But for now it's in there as well.
>
> Please test, especially if you've got multiple heads.  A lot of the
> stuff I was changing had to do with managing multiple heads, and I can't
> test any of that myself.
>

Sounds good. I'll be testing it either tommorow or on friday.

merge when things are done.

Thanks for your efforts,
Chris

PS: (not directly related to this message, though)

So one showstopper is gone (SawfishConfig + non-ascii chars),
viewport-scrambling (#2) is almost done, perhaps we reach for a goal
of three? #3 would be XRandR resolution-changed event. 1.6.0 would
become a killer. I'll be reading xlib docs in dec/jan when I got
holidays, so I'll try to change keys.[ch] to "my" needs for 3.0. #4
would be two keyboards at once issues and #5 (not reproducable by me)
that titlebuttons may not work when changing layout from en to ru (maybe
others, too?).

[Teika Kazura]

On Wed, 21 Oct 2009 20:37:39 +0200, Christopher Roy Bratusek wrote:
> I'll try to change keys.[ch] to "my" needs for 3.0.

If you mean NumLock, then please make it optional. Others may want
Sawfish to ignore NumLock.

Well, you can concentrate on the core hack, and I can do option part.
(But if the deadline is so close I'll beg to postpone it.)

Thanks beforehand.
Teika (Teika kazura)

[Teika Kazura]

Hi. With new commit, all maximized windows get restarted in VP (0, 0).
Does anyone experience it?

I set in rc:
( define-special-variable window-history-states
  '( sticky-viewport ignored never-focus type
                     dimensions fixed-position maximized
                     frame-style cycle-skip window-list-skip viewport
                     ) )

Thanks anyway. The goal must be near.
Teika (Teika kazura)

[Jeremy Hankins]

Teika Kazura <teika@...> writes:
> Hi. With new commit, all maximized windows get restarted in VP (0, 0).
> Does anyone experience it?
>
> I set in rc:
> ( define-special-variable window-history-states
>   '( sticky-viewport ignored never-focus type
>     dimensions fixed-position maximized
>     frame-style cycle-skip window-list-skip viewport
>     ) )

I haven't been able to reproduce it.  Are they maximized vertically,
horizontally, both, or fullscreen?

Can you maximize a window in some other viewport than the one you're in
via sawfish-client -- e.g.:

user> (require 'maximize)
t
user> (maximize-window (get-window-by-name "foo"))

This should work, and it shouldn't switch viewports.

The only thing I can think of is maybe there's something in your history
file that's setting the location of the windows?  What happens if you
move it aside temporarily?

> Thanks anyway. The goal must be near.
> Teika (Teika kazura)

--
Jeremy Hankins <nowan@...>

[Flashrider]

Well what I've got in mind is something like:

;; exec true when NumLock is OFF
KP_Left '(system "true &")

;; exec true when NumLock is ON
N-KP_Left '(system "true &")

Deadline is 3.0, which I expect to take 12 months, so there's time until
December 2010

Regards,
Chris

Am Montag, den 26.10.2009, 21:15 +0900 schrieb Teika Kazura:

> On Wed, 21 Oct 2009 20:37:39 +0200, Christopher Roy Bratusek wrote:
> > I'll try to change keys.[ch] to "my" needs for 3.0.
>
> If you mean NumLock, then please make it optional. Others may want
> Sawfish to ignore NumLock.
>
> Well, you can concentrate on the core hack, and I can do option part.
> (But if the deadline is so close I'll beg to postpone it.)
>
> Thanks beforehand.
> Teika (Teika kazura)
>
>

[Teika Kazura]

On Tue, 27 Oct 2009 18:58:10 +0100, Christopher Roy Bratusek wrote:
> Well what I've got in mind is something like:
>
> ;; exec true when NumLock is OFF
> KP_Left '(system "true &")
>
> ;; exec true when NumLock is ON
> N-KP_Left '(system "true &")

Yes, it'll be great. (Thanks for explanation I omitted :) I meant that
someone else may like NumLock gets ignored, so that both KP_Left and
NumLock-KP_Left are treated as "KP_Left".  (This is the current
Sawfish.)

Option to switch between these two is easy, and I'll do it if NumLock
support is done.

Cheers,
Teika (Teika kazura)

[Teika Kazura]

Thanks for reply, Jeremy.


I wrote the answer below the other day. Minutes ago, I changed the
value of 'window-history-states' by dropping 'maximized', and
suddenly it works, *even after* re-enabling 'maximized'.
------------------------------------------------------------------------
On Tue, 27 Oct 2009 08:13:57 -0500, Jeremy Hankins wrote:
> Can you maximize a window in some other viewport than the one you're in
> via sawfish-client -- e.g.:
>
> user> (require 'maximize)
> t
> user> (maximize-window (get-window-by-name "foo"))
>
> This should work, and it shouldn't switch viewports.

The maximized window which was originally in different VP appears in
the current VP, and the current VP doesn't change.

I noticed one more peculiar thing: for urxvt (= rxvt-unicode, an x
term), maximize-window-vertically in other VP doesn't change size (but
maximized-p is true, so after restart, it gets actually maximized),
but in the current VP it works.

And the VP comes back to (0, 0) after restart, but the current VP is
supposed to be kept, right?

> The only thing I can think of is maybe there's something in your history
> file that's setting the location of the windows?  What happens if you
> move it aside temporarily?

No effect. (I did it correctly - I switched off all for histories, and
I checked that window-history isn't created after restart. Then I
switched on all.)
------------------------------------------------------------------------
It may be the bug of history/session, but then why deleting
'window-history' file doesn't work?

By the way, I once discovered that maximize-fill-window-vertically
sometimes fail to avoid other windows. I can't reproduce it now
today, but is it related? (Well, let's forget this issue if it has
nothing to do ;)

Best regards,
Teika (Teika kazura)

On Tue, 27 Oct 2009 08:13:57 -0500, Jeremy Hankins wrote:

> Teika Kazura <teika@...> writes:
>> Hi. With new commit, all maximized windows get restarted in VP (0, 0).
>> Does anyone experience it?
>>
>> I set in rc:
>> ( define-special-variable window-history-states
>>   '( sticky-viewport ignored never-focus type
>>     dimensions fixed-position maximized
>>     frame-style cycle-skip window-list-skip viewport
>>     ) )
>
> I haven't been able to reproduce it.  Are they maximized vertically,
> horizontally, both, or fullscreen?
>
> Can you maximize a window in some other viewport than the one you're in
> via sawfish-client -- e.g.:
>
> user> (require 'maximize)
> t
> user> (maximize-window (get-window-by-name "foo"))
>
> This should work, and it shouldn't switch viewports.
>
> The only thing I can think of is maybe there's something in your history
> file that's setting the location of the windows?  What happens if you
> move it aside temporarily?
>
>> Thanks anyway. The goal must be near.
>> Teika (Teika kazura)
>
> --
> Jeremy Hankins <nowan@...>

[Flashrider]

Am Sat, 31 Oct 2009 13:34:48 +0900 (JST)
schrieb Teika Kazura <teika@...>:

> Thanks for reply, Jeremy.
>
>
> I wrote the answer below the other day. Minutes ago, I changed the
> value of 'window-history-states' by dropping 'maximized', and
> suddenly it works, *even after* re-enabling 'maximized'.
> ------------------------------------------------------------------------
> On Tue, 27 Oct 2009 08:13:57 -0500, Jeremy Hankins wrote:
> > Can you maximize a window in some other viewport than the one
> > you're in via sawfish-client -- e.g.:
> >
> > user> (require 'maximize)
> > t
> > user> (maximize-window (get-window-by-name "foo"))
> >
> > This should work, and it shouldn't switch viewports.
>
> The maximized window which was originally in different VP appears in
> the current VP, and the current VP doesn't change.
>
> I noticed one more peculiar thing: for urxvt (= rxvt-unicode, an x
> term), maximize-window-vertically in other VP doesn't change size (but
> maximized-p is true, so after restart, it gets actually maximized),
> but in the current VP it works.
>
> And the VP comes back to (0, 0) after restart, but the current VP is
> supposed to be kept, right?
>
> > The only thing I can think of is maybe there's something in your
> > history file that's setting the location of the windows?  What
> > happens if you move it aside temporarily?
>
> No effect. (I did it correctly - I switched off all for histories, and
> I checked that window-history isn't created after restart. Then I
> switched on all.)
> ------------------------------------------------------------------------
> It may be the bug of history/session, but then why deleting
> 'window-history' file doesn't work?

Because it gets rewritten on every (restart) and (quit) also before the
file is written sawfish must save it into some variable, so to actually
remove that file you need to quit sawfish and do it while it's *not*
running, btw it's the same sawfish/custom

>
> By the way, I once discovered that maximize-fill-window-vertically
> sometimes fail to avoid other windows. I can't reproduce it now
> today, but is it related? (Well, let's forget this issue if it has
> nothing to do ;)
>
> Best regards,
> Teika (Teika kazura)
>
> On Tue, 27 Oct 2009 08:13:57 -0500, Jeremy Hankins wrote:
> > Teika Kazura <teika@...> writes:
> >> Hi. With new commit, all maximized windows get restarted in VP (0,
> >> 0). Does anyone experience it?
> >>
> >> I set in rc:
> >> ( define-special-variable window-history-states
> >>   '( sticky-viewport ignored never-focus type
> >>     dimensions fixed-position maximized
> >>     frame-style cycle-skip window-list-skip
> >> viewport ) )
> >
> > I haven't been able to reproduce it.  Are they maximized vertically,
> > horizontally, both, or fullscreen?
> >
> > Can you maximize a window in some other viewport than the one
> > you're in via sawfish-client -- e.g.:
> >
> > user> (require 'maximize)
> > t
> > user> (maximize-window (get-window-by-name "foo"))
> >
> > This should work, and it shouldn't switch viewports.
> >
> > The only thing I can think of is maybe there's something in your
> > history file that's setting the location of the windows?  What
> > happens if you move it aside temporarily?
> >
> >> Thanks anyway. The goal must be near.
> >> Teika (Teika kazura)
> >
> > --
> > Jeremy Hankins <nowan@...>
>

[Flashrider]

Am Thu, 29 Oct 2009 14:22:29 +0900 (JST)
schrieb Teika Kazura <teika@...>:

>
>
> On Tue, 27 Oct 2009 18:58:10 +0100, Christopher Roy Bratusek wrote:
> > Well what I've got in mind is something like:
> >
> > ;; exec true when NumLock is OFF
> > KP_Left '(system "true &")
> >
> > ;; exec true when NumLock is ON
> > N-KP_Left '(system "true &")
>
> Yes, it'll be great. (Thanks for explanation I omitted :) I meant that
> someone else may like NumLock gets ignored, so that both KP_Left and
> NumLock-KP_Left are treated as "KP_Left".  (This is the current
> Sawfish.)

X-KP_Left ? or NI-KP_Left ?

> Option to switch between these two is easy, and I'll do it if NumLock
> support is done.
>
> Cheers,
> Teika (Teika kazura)
>

[Jeremy Hankins]

Teika Kazura <teika@...> writes:
> Thanks for reply, Jeremy.
>
>
> I wrote the answer below the other day. Minutes ago, I changed the
> value of 'window-history-states' by dropping 'maximized', and
> suddenly it works, *even after* re-enabling 'maximized'.

That's very strange.  If there is a bug hopefully it will show up
again, but for now I can't think what the problem might be.

--
Jeremy Hankins <nowan@...>

[Teika Kazura]

On Sat, 31 Oct 2009 07:42:12 +0100, Christopher Roy Bratusek wrote:

> Am Thu, 29 Oct 2009 14:22:29 +0900 (JST)
> schrieb Teika Kazura <teika@...>:
>> On Tue, 27 Oct 2009 18:58:10 +0100, Christopher Roy Bratusek wrote:
>> > ;; exec true when NumLock is OFF
>> > KP_Left '(system "true &")
>> >
>> > ;; exec true when NumLock is ON
>> > N-KP_Left '(system "true &")
>>
>> Yes, it'll be great. (Thanks for explanation I omitted :) I meant that
>> someone else may like NumLock gets ignored, so that both KP_Left and
>> NumLock-KP_Left are treated as "KP_Left".  (This is the current
>> Sawfish.)
>
> X-KP_Left ? or NI-KP_Left ?

Sorry, I don't understand your question due to lack of my X
knowledge. If it's worth discussion, could you explain it?

Thank you in advance.
Teika (Teika kazura)

[Teika Kazura]

So, is it ok to merge 'viewport' branch to master now? (It needs some
doc updates to solve conflicts.)

Teika (Teika kazura)

[Jeremy Hankins]

Teika Kazura <teika@...> writes:

> So, is it ok to merge 'viewport' branch to master now? (It needs some
> doc updates to solve conflicts.)

Done.

I left the changelog entries at the dates I originally wrote them,
rather than the merge date....

--
Jeremy Hankins <nowan@...>