NEWS on 1.6.0

[Flashrider]

Hi all,

Half of the time for Sawfish 1.6 has passed, so it's time for some news
for those who didn't follow the HEAD.

(refer to ChangeLog/NEWS to know who is responsible for what)

* Removed built-in Audio Support
        - Instead we rely on an extern playbin ("/usr/bin/paplay")
        - important customization options:
                ° audio-events-enabled (bool)
                ° play-sample-program
                        ^ there's more, check OPTIONS ("audio options")
        - So we got rid of ESounD and LibAudioFile dependencies
                ° Sawfish is now Deprecated-GNOME-Cruft free
                        ^ Project Ridley finished for Sawfish

* Themes in tar.xz and tar.lzma formats are now supported (librep .90.1)

* SawfishUI ("sawfish-ui") is now SawfishConfig ("sawfish-config")
        - modules moved from sawfish.ui.* to sawfish.cfg.*

* SawfishConfig non-ASCII string issue has been fixed
        - bug in librep < .90.2

* An own implementation of the FDO Applicationmenu is now shipped
        - it's automagically beeing used
                ° if there's no customized apps-menu


* SawfishConfig/Sawfish UI improvements
        - GtkColorButton instead of semi-deprecated widget-combination
        - GtkLinkButton instead of custom widget
        - Revamped the Root and Window menus
        - GtkSpinButton (type :number) now support
                ° an initial value
                ° negative values all the way
        - Grab-Button and Labels justified left in match-window dialog

* SawfishConfig Config improvements
        - New Window Matchers
                ° new-viewport
                        ^ open window on it's own VP
                ° new-workspace
                        ^ open window on it's own WS
                ° fullscreen
                        ^ make window fullscreen on map
                ° fullscreen-xinerama
                        ^ make window fullscreen-xinerama on map
                ° window-name
                        ^ change the WM_NAME and WM_ICON props
                                + this is not ICCCM compliant
                ° keymap-trans
                        ^ convert keystrokes
                                + eg press C-e but window receives W-e
                                + unchangeable bindings = gone
        - Ability to change font-colors theme-independently

* Reduced GNOME-Specific Code to the minimum
        - brakes GNOME 1.x support
                ° and perhaps very very early 2.x (<2.2)
                        ^ which got so or so is broken with 1.5 somehow

* Added KDE-Integration Module
        - exact equivalent of the GNOME-Integration Module

* When entering a different WS it's now possible to display it's name
        - like in Enlightenment DR17

* New Frame Classes (for Theme-Creators)
        - lock-button
        - sticky-button
        - rename-button
        - move-resize-button
        - raise-lower-button

This is just an overview, there's more (also check librep and rep-gtk)!

Feature Freeze begins on 6th December 2009 (~ 20 o'clock CEST).

Get your new features/request done until when, then let's squash bugs.

Sawfish 1.6.0 will be released on 22nd December 2009

Along with rep-gtk 0.90.1 and either librep 0.90.3 or 0.90.4 on the 20th
December 2009.

^_^

Have a lot of fun (and spread the word),
Chris

[Janek Kozicki]

Christopher Roy Bratusek said:     (by the date of Thu, 01 Oct 2009 20:02:13 +0200)

> * When entering a different WS it's now possible to display it's name
> - like in Enlightenment DR17

How about displaying Viewport name when changing a Viewport?

Oh, do you also plan to fix

  http://sawfish.wikia.com/wiki/Proposed_Goals#Restart_and_viewport

for 1.6.0 ? I suffer from this one too...



Maybe (just maybe..) I will sit down this sunday to fix that

  http://sawfish.wikia.com/wiki/Proposed_Goals#Crash_fix

And I wanted to skip installing 1.6.0 now, because I have just
installed 1.5.0.

I hope that if I fix this in 1.5.0, will it be portable to 1.6.0?
How do you think?

Stupid problem, is that I can only manage one day for doing this, and
it's sunday. So waiting for some answers from the mailing list, when
I hit an obstacle when fixing this bug is not an option :/

--
Janek Kozicki                                                         |

[Jeremy Hankins]

Janek Kozicki <janek_listy@...> writes:
> Christopher Roy Bratusek said:     (by the date of Thu, 01 Oct 2009 20:02:13 +0200)
>
>> * When entering a different WS it's now possible to display it's name
>> - like in Enlightenment DR17
>
> How about displaying Viewport name when changing a Viewport?

Viewports don't really have names, they have coordinates.  I guess you
could display those.  But wouldn't a pager make more sense?

> Oh, do you also plan to fix
>
>   http://sawfish.wikia.com/wiki/Proposed_Goals#Restart_and_viewport
>
> for 1.6.0 ? I suffer from this one too...

Yeah, me too.

> Maybe (just maybe..) I will sit down this sunday to fix that
>
>   http://sawfish.wikia.com/wiki/Proposed_Goals#Crash_fix
>
> And I wanted to skip installing 1.6.0 now, because I have just
> installed 1.5.0.
>
> I hope that if I fix this in 1.5.0, will it be portable to 1.6.0?
> How do you think?

Hmm..  I'm not sure whether the changes I made when I added dynamic
boundary mode would cause problems for that or not, but they may.  One
difference besides dynamic viewport support itself is that in 1.6.0 each
desktop has it's own active viewport, which should probably be saved as
well.

There is code in viewport to save state, and it's not obvious to me why
it's not working, though it clearly needs to be updated for dynamic
viewport mode.  If you fix it for 1.5 I'll look at porting it to 1.6.
Or if you don't get to it I'll take a look myself.

--
Jeremy Hankins <nowan@...>

[Janek Kozicki]

Jeremy Hankins said:     (by the date of Fri, 02 Oct 2009 08:41:27 -0500)

> Janek Kozicki <janek_listy@...> writes:
> > Christopher Roy Bratusek said:     (by the date of Thu, 01 Oct 2009 20:02:13 +0200)
> >
> >> * When entering a different WS it's now possible to display it's name
> >> - like in Enlightenment DR17
> >
> > How about displaying Viewport name when changing a Viewport?
>
> Viewports don't really have names, they have coordinates.  I guess you
> could display those.  But wouldn't a pager make more sense?

yes I have a pager. But you could assign names to those "coordinates"
and call viewport 1,4 "email" or such. Those would be displayed in
similar manner as assigning name "email" to workspace number 3.

> > I hope that if I fix this in 1.5.0, will it be portable to 1.6.0?
> > How do you think?
>
> Hmm..  I'm not sure whether the changes I made when I added dynamic
> boundary mode would cause problems for that or not, but they may.  One
> difference besides dynamic viewport support itself is that in 1.6.0 each
> desktop has it's own active viewport, which should probably be saved as
> well.
>
> There is code in viewport to save state, and it's not obvious to me why
> it's not working, though it clearly needs to be updated for dynamic
> viewport mode.  If you fix it for 1.5 I'll look at porting it to 1.6.
> Or if you don't get to it I'll take a look myself.

This crash actually isn't related to viewports. It happens when some
window is closed. And I guess it is closed in some illegal way, maybe
when unmapped from wm. Of course closing windows in illegal way is
illegal, but sawfish isn't supposed to crash at this. Thanks for your
interest in the issue.

--
Janek Kozicki                                                         |

[Jeremy Hankins]

Janek Kozicki <janek_listy@...> writes:
> Jeremy Hankins said:     (by the date of Fri, 02 Oct 2009 08:41:27 -0500)

>> There is code in viewport to save state, and it's not obvious to me
>> why it's not working, though it clearly needs to be updated for
>> dynamic viewport mode.  If you fix it for 1.5 I'll look at porting it
>> to 1.6.  Or if you don't get to it I'll take a look myself.
>
> This crash actually isn't related to viewports. It happens when some
> window is closed. And I guess it is closed in some illegal way, maybe
> when unmapped from wm. Of course closing windows in illegal way is
> illegal, but sawfish isn't supposed to crash at this. Thanks for your
> interest in the issue.

Sorry, I quoted your text badly -- I was talking about saving viewport
state across restart, not the crash.  I shouldn't have included that
part of your text in my reply.

--
Jeremy Hankins <nowan@...>

[Teika Kazura]

Hi.

On Fri, 2 Oct 2009 09:42:53 +0200, Janek Kozicki wrote:
> Oh, do you also plan to fix
>
>   http://sawfish.wikia.com/wiki/Proposed_Goals#Restart_and_viewport
>
> for 1.6.0 ? I suffer from this one too...

Hi, Janek. I proposed this, but I won't. The sawfish init is a
labyrinth to me. It also requires viewport knowledge. Anyone?

On Fri, 02 Oct 2009 08:41:27 -0500, Jeremy Hankins wrote:
> Yeah, me too.
Please report, in some format, what you find inconvenient/bad/buggy...
Try to be keen on your sense, detecting a slight feeling of
strangeness.  And don't try to solve all by yourself :)
Don't fear dup report. If it hasn't been a topic for a while, then
it's worth remembering.

> Maybe (just maybe..) I will sit down this sunday to fix that
>
>   http://sawfish.wikia.com/wiki/Proposed_Goals#Crash_fix
>
> And I wanted to skip installing 1.6.0 now, because I have just
> installed 1.5.0.
>
> I hope that if I fix this in 1.5.0, will it be portable to 1.6.0?
> How do you think?

Because the core part of librep and sawfish have not changed so much,
it must apply for 1.6.0, I guess.

Thanks a lot beforehand. I was about to ask if someone will be
interested in it, before too many changes are done.

> Stupid problem, is that I can only manage one day for doing this, and
> it's sunday. So waiting for some answers from the mailing list, when
> I hit an obstacle when fixing this bug is not an option :/

Hmm, I'm not C / C++ guy. And I may be asleep already. Japan is +0900
;)

Best regards.
Teika (Teika kazura)

[Jeremy Hankins]

Teika Kazura <teika@...> writes:
> On Fri, 2 Oct 2009 09:42:53 +0200, Janek Kozicki wrote:

>>   http://sawfish.wikia.com/wiki/Proposed_Goals#Restart_and_viewport>
>> for 1.6.0 ? I suffer from this one too...
>
> Hi, Janek. I proposed this, but I won't. The sawfish init is a
> labyrinth to me. It also requires viewport knowledge. Anyone?
>
> On Fri, 02 Oct 2009 08:41:27 -0500, Jeremy Hankins wrote:
>> Yeah, me too.

> Please report, in some format, what you find inconvenient/bad/buggy...
> Try to be keen on your sense, detecting a slight feeling of
> strangeness.  And don't try to solve all by yourself :) Don't fear dup
> report. If it hasn't been a topic for a while, then it's worth
> remembering.

Sure; when I restart sawfish everything ends up on vp 0,0, no matter
what viewport it started out on.  So I guess my problem isn't quite the
same as the one in the bug report, and perhaps not even exactly a bug.
My problem is evidently that I don't have a session manager (i.e., I
don't run Gnome or KDE), and so none of the code to save and restore
window properties actually gets run.

I don't think this is something I could fix anyway, really.  If I'm
understanding the code right the session module relies on a callback
from the C side to tell it to save state, but that callback can't be set
up unless the lisp side tells the C side how to talk to the session
manager -- which is of course impossible if there isn't one.

--
Jeremy Hankins <nowan@...>

[Flashrider]

Am Samstag, den 03.10.2009, 08:59 -0500 schrieb Jeremy Hankins:

Teika Kazura <teika@...> writes:
> On Fri, 2 Oct 2009 09:42:53 +0200, Janek Kozicki wrote:

>>   http://sawfish.wikia.com/wiki/Proposed_Goals#Restart_and_viewport> 
>> for 1.6.0 ? I suffer from this one too...
>
> Hi, Janek. I proposed this, but I won't. The sawfish init is a
> labyrinth to me. It also requires viewport knowledge. Anyone?
>
> On Fri, 02 Oct 2009 08:41:27 -0500, Jeremy Hankins wrote:
>> Yeah, me too.

> Please report, in some format, what you find inconvenient/bad/buggy...
> Try to be keen on your sense, detecting a slight feeling of
> strangeness.  And don't try to solve all by yourself :) Don't fear dup
> report. If it hasn't been a topic for a while, then it's worth
> remembering.

Sure; when I restart sawfish everything ends up on vp 0,0, no matter
what viewport it started out on.  So I guess my problem isn't quite the
same as the one in the bug report, and perhaps not even exactly a bug.
My problem is evidently that I don't have a session manager (i.e., I
don't run Gnome or KDE), and so none of the code to save and restore
window properties actually gets run.

I don't think this is something I could fix anyway, really.  If I'm
understanding the code right the session module relies on a callback
from the C side to tell it to save state, but that callback can't be set
up unless the lisp side tells the C side how to talk to the session
manager -- which is of course impossible if there isn't one.

Have no fear, WindowManager-Hero-X is here, Kupo!

a) You need to use window-history to save atttrs
b) The following attrs are saved by default:
    ° sticky ignored never-focus type maximized frame-style cycle-skip window-list-skip

c) Just make it aware to save the VP attr by adding 'viewport' to the list, as example my value (not-yet-uploaded rev11 of my .sawfishrc):

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

Regards,
Chris

[Janek Kozicki]

Teika Kazura said:     (by the date of Sat, 03 Oct 2009 15:12:15 +0900 (JST))

> > Maybe (just maybe..) I will sit down this sunday to fix that
> >
> >   http://sawfish.wikia.com/wiki/Proposed_Goals#Crash_fix
> Hmm, I'm not C / C++ guy. And I may be asleep already. Japan is +0900

I have found the bug. Exact place.

Problem is that in a very short piece of code sawfish does not expect
a newly created window to disappear. If it does - then sawfish will
crash.

The segfaults were usually more frequent under high system load,
because sawfish was running slower and the critical section took
longer time to execute.

But it is in fact a race condition. I don't see a _perfect_ way to
fix this. Unless we employ some serious multithreaded locks to talk
between X and wm. Or find a way to lock X for a very short period of
time. Maybe there is a way to do that, which I'm unaware of.

So I have created a patch which is not perfect. But works most of the
time. I didn't manage to crash sawfish any more when using it, but in
theory it is still possible. We are left with hope that more frequent
checks if a window was deleted will result in less frequent sawfish
crashes. Please review the patch here:

  http://sawfish.wikia.com/wiki/Create_and_quickly_destroy_a_window_-_a_patch_to_almost_fix_the_sawfish_segfault

Sorry for the long patch name. I felt that it is necessary to name it
in such a descriptive way...

--
Janek Kozicki                                                         |

[Janek Kozicki]

Christopher Roy Bratusek said:     (by the date of Sun, 04 Oct 2009 17:27:57 +0200)

> Have no fear, WindowManager-Hero-X is here, Kupo!
>
> a) You need to use window-history to save atttrs
> b) The following attrs are saved by default:
>     ° sticky ignored never-focus type maximized frame-style cycle-skip
> window-list-skip
>
> c) Just make it aware to save the VP attr by adding 'viewport' to the
> list, as example my value (not-yet-uploaded rev11 of my .sawfishrc):
>
> ( define-special-variable window-history-states '( sticky
> sticky-viewport ignored never-focus type fixed-position dimensions
>    maximized frame-style cycle-skip window-list-skip viewport
> workspace ) )

Let me get this clear - are you saying that you have fixed
 
  http://sawfish.wikia.com/wiki/Proposed_Goals#Restart_and_viewport

in your .sawfishrc ?

You can test by simply creating lots of viewports, like 5x5. Opening
window on each viewport (eg. an xterm with text indicating on which
viewport you did open it). Then restarting sawfish multiple times.

When currently I restart sawfish, all the windows are messed up, and
they don't even go to viewport 0,0. Each of them goes to a random
viewport. Some even go "outside" - they have coordinates out of all
viewports range. Total mess :)

--
Janek Kozicki                                                         |

[Flashrider]

Am Sonntag, den 04.10.2009, 18:27 +0200 schrieb Janek Kozicki:

> Christopher Roy Bratusek said:     (by the date of Sun, 04 Oct 2009 17:27:57 +0200)
>
> > Have no fear, WindowManager-Hero-X is here, Kupo!
> >
> > a) You need to use window-history to save atttrs
> > b) The following attrs are saved by default:
> >     ° sticky ignored never-focus type maximized frame-style cycle-skip
> > window-list-skip
> >
> > c) Just make it aware to save the VP attr by adding 'viewport' to the
> > list, as example my value (not-yet-uploaded rev11 of my .sawfishrc):
> >
> > ( define-special-variable window-history-states '( sticky
> > sticky-viewport ignored never-focus type fixed-position dimensions
> >    maximized frame-style cycle-skip window-list-skip viewport
> > workspace ) )
>
> Let me get this clear - are you saying that you have fixed
>  
>   http://sawfish.wikia.com/wiki/Proposed_Goals#Restart_and_viewport
>
> in your .sawfishrc ?
>
> You can test by simply creating lots of viewports, like 5x5. Opening
> window on each viewport (eg. an xterm with text indicating on which
> viewport you did open it). Then restarting sawfish multiple times.
>
> When currently I restart sawfish, all the windows are messed up, and
> they don't even go to viewport 0,0. Each of them goes to a random
> viewport. Some even go "outside" - they have coordinates out of all
> viewports range. Total mess :)
>

... With many windows it's not working, but if there less it does, but
so or so sawfish doesn't save viewport attr, so you'll have to adjust
window-history-states so or so. But the code restoring it is ugly.

Well, I thought that would fix it, as I don't tend to have more than 3
windows open. (I open an app to do something, and immediately close it
after I've finished, even if that causes starting the same app x-times,
I want to keep the overview)

Chris

[Timo Korvola-2]

On Sunday 04 October 2009 19:21:04 Janek Kozicki wrote:
> Or find a way to lock X for a very short period of
> time. Maybe there is a way to do that, which I'm unaware of.

XGrabServer?

--
        Timo Korvola <URL:http://www.iki.fi/tkorvola>

[Jeremy Hankins]

Christopher Roy Bratusek <zanghar@...> writes:
> Am Sonntag, den 04.10.2009, 18:27 +0200 schrieb Janek Kozicki:

> ... With many windows it's not working, but if there less it does, but
> so or so sawfish doesn't save viewport attr, so you'll have to adjust
> window-history-states so or so. But the code restoring it is ugly.

It's not working for me, even with only six or seven windows.  viewport
doesn't even show up in the history file, though it's in the list.

window-history also doesn't seem to be quite what I want.  Most all of
my windows are either xterms or emacs frames.  window-history doesn't
differentiate between different windows with the same class, so if I
have windows of the same class in different places/viewports those
positions wont be kept.

--
Jeremy Hankins <nowan@...>

[Jeremy Hankins]

Janek Kozicki <janek_listy@...> writes:

> When currently I restart sawfish, all the windows are messed up, and
> they don't even go to viewport 0,0. Each of them goes to a random
> viewport. Some even go "outside" - they have coordinates out of all
> viewports range. Total mess :)

After a bit of playing around, I think that all maximized (vertically,
horizontally, or both) windows end up in vp 0,0, and only if I'm in vp
0,0 when I restart.  Otherwise these maximized windows follow a definite
pattern:

 - If I'm in a 0,x vp where x>0, a maximized window is placed every x
   viewports, all in a single column.
 - If I'm in a x,0 vp the pattern is the same, but in a single row.
 - And the pattern seems to extend to x,y viewports.

Though why whether the window is maximized would be relevant is beyond
me.

--
Jeremy Hankins <nowan@...>

[Timo Korvola-2]

On Sunday 04 October 2009 19:21:04 Janek Kozicki wrote:
> I have found the bug. Exact place.

I hope it is the only place.  Wouldn't bet on it though.  There may be
more instances, perhaps with so narrow time windows that they have never
been seen.

> Problem is that in a very short piece of code sawfish does not expect
> a newly created window to disappear. If it does - then sawfish will
> crash.

But why, precisely?  One of the Xlib calls may have triggered
error_handler, which sets w->id = 0, but is that enough to cause a SEGV?  
Is it possible that w gets garbage-collected before add_window is
finished?  That would explain a lot.  It seems that the garbage
collection would then have to occur after emit_pending_destroys.

I am not really familiar with the Librep C API and it is not too well
documented, thus I am guessing here.  The enclosed patch tries to
protect w from gc (you can also fetch branch "race" from my repository).  
People affected by the bug might want to test it.  Being unable to
reproduce the bug myself, I can't say whether it helps.

--
        Timo Korvola <URL:http://www.iki.fi/tkorvola>

[sawfish-race.patch]

---

From c3235edd1f570d543c1b60f2f70ce27cca08fd26 Mon Sep 17 00:00:00 2001
From: Timo Korvola <tkorvola@...>
Date: Tue, 6 Oct 2009 00:28:33 +0300
Subject: [PATCH] Wrap most of add_window in rep_PUSHGC/rep_POPGC.

There have been crashes that might be due to a window being
destroyed, garbage collected and then accessed, all during
add_window (client destroys window really quickly after mapping).
---
 src/windows.c |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/src/windows.c b/src/windows.c
index baf924a..ca98b13 100644
--- a/src/windows.c
+++ b/src/windows.c
@@ -459,6 +459,10 @@ add_window (Window id)
  w->net_name = Qnil;
  w->net_icon_name = Qnil;
 
+        /* Don't garbage collect the window before we are done. */
+        /* Note: must not return without rep_POPGC. */
+ rep_PUSHGC(gc_win, win);
+
  /* have to put it somewhere until it finds the right place */
  insert_in_stacking_list_above_all (w);
  restack_window (w);
@@ -527,10 +531,8 @@ add_window (Window id)
   }
 
  /* ..then call the add-window-hook's.. */
- rep_PUSHGC(gc_win, win);
  Fcall_window_hook (Qbefore_add_window_hook, rep_VAL(w), Qnil, Qnil);
  Fcall_window_hook (Qadd_window_hook, rep_VAL(w), Qnil, Qnil);
- rep_POPGC;
 
  /* In case the window disappeared during the hook call */
  if (!WINDOW_IS_GONE_P (w))
@@ -551,13 +553,11 @@ add_window (Window id)
 
  if (!WINDOW_IS_GONE_P (w))
  {
-           repv tem = Fwindow_get (rep_VAL(w), Qplaced, Qnil);
+            repv tem = Fwindow_get (rep_VAL(w), Qplaced, Qnil);
     if (initialising || (tem && tem == Qnil))
     {
  /* ..then the place-window-hook.. */
- rep_PUSHGC(gc_win, win);
  Fcall_window_hook (Qplace_window_hook, rep_VAL(w), Qnil, Qor);
- rep_POPGC;
     }
  }
  Fwindow_put (rep_VAL(w), Qplaced, Qt);
@@ -570,6 +570,7 @@ add_window (Window id)
     /* Tell the window where it ended up.. */
     send_synthetic_configure (w);
  }
+        rep_POPGC;
     }
     return w;
 }
--
1.6.3.3

---

[Teika Kazura]

Hi.

On Mon, 05 Oct 2009 15:51:48 -0500, Jeremy Hankins wrote:
> Though why whether the window is maximized would be relevant is beyond
> me.

The root of evil must be matcher. When sawfish exits, all maximized
windows are unmaximized.  And when it (re)starts, it maximizes
again. Where?  In *current* viewport.  (It seems that actually there's
no *current* viewport in this context. In maximization, the
coordinates seems to be simply set to the (0,0) and (xmax-1, ymax-1),
*on the screen* = in current viewport. So, not only maximization, but
specifying coordinates to the window has the same effect.  But I don't
understand VP, either. It's a guess.)

Now what's current? It depends. Suppose one window rule is "appear in
viewport Z" After processing that window, the current viewport is Z,
not (0, 0).

Again the same question: what's the current viewport? If infinite
desktop is there, the Sawfish's conventional VP doesn't make sense.
We need a new definition, absorbing the old. This is the reason I did
a bit of poll on VP and ID. (Sorry I haven't analyzed it.)

My biggest concern is the news rewritement and review of 1.6-changes,
and I can scarecely spare time for it. :(

Regards,
Teika (Teika kazura)

[Teika Kazura]

Hi.

On Thu, 01 Oct 2009 20:02:13 +0200, Christopher Roy Bratusek wrote:
> Half of the time for Sawfish 1.6 has passed, so it's time for some news
> for those who didn't follow the HEAD.

Thanks a lot! Now you're accustomed to be our leader. In fact,
a *good* leader.

> * Reduced GNOME-Specific Code to the minimum

What is 'minimum'? (I don't know the previous status either since I
don't have Gnome.) Could you describe more on it? I can't do anything
on this item in news.texi.

> Feature Freeze begins on 6th December 2009 (~ 20 o'clock CEST).
> [...] Sawfish 1.6.0 will be released on 22nd December 2009

I don't know if I can polish the news.texi by the deadline. I may ask
longer period between freeze and release, when the time has come.
But let's wait and see.

> Have a lot of fun (and spread the word),

To Linus? :)
Teika (Teika kazura)

[Jeremy Hankins]

Teika Kazura <teika@...> writes:

> Hi.
>
> On Mon, 05 Oct 2009 15:51:48 -0500, Jeremy Hankins wrote:
>> Though why whether the window is maximized would be relevant is beyond
>> me.
>
> The root of evil must be matcher. When sawfish exits, all maximized
> windows are unmaximized.  And when it (re)starts, it maximizes
> again. Where?  In *current* viewport.  (It seems that actually there's
> no *current* viewport in this context. In maximization, the
> coordinates seems to be simply set to the (0,0) and (xmax-1, ymax-1),
> *on the screen* = in current viewport. So, not only maximization, but
> specifying coordinates to the window has the same effect.  But I don't
> understand VP, either. It's a guess.)

That makes a lot of sense.  Fundamentally, viewports are only
coordinates that aren't part of the visible display.  When the viewport
code switches viewports it does two things:

 - Updates some bookkeeping data -- the most important of which are
   x-offset and y-offset, which indicate the distance between the actual
   0,0 point of the display and the logical 0,0 point of the
   virtual-desktop (i.e., all viewports put together).

 - Every window in the current desktop (in 1.5 it was literally every
   non-viewport-sticky window) is moved in the opposite direction of the
   viewport-movement, to make it appear as if the display has moved.

So viewports are a logical overlay to make navigation easier, and to
help the pager display properly.  Really all that's going on is that
windows are at various locations off and on screen, and the
viewport-movement commands just shift them around so that some come
on-screen and others go off-screen.

> Now what's current? It depends. Suppose one window rule is "appear in
> viewport Z" After processing that window, the current viewport is Z,
> not (0, 0).

The current viewport is always the coordinates from 0,0 to
screen-width,screen-height.  To put a window in a viewport other than
the current one the coordinates should be somewhere outside of that
range.  Probably the simplest thing to do would be to come up with a way
to place a window in a vp without moving the current vp -- after all,
all that's needed is to place the window in the appropriate location
off-screen.  When the viewport changes the location data of all the
yet-to-be-managed windows is no longer correct, so shifting viewports is
problematic.

But to do that I need to find where the current confused setting of the
location is happening -- possibly the best thing to do is nothing,
really, but there may be some other reason for adjusting the coordinates
of the window.  I'll look for that, but if someone knows already maybe
you can let me know where to look?

> Again the same question: what's the current viewport? If infinite
> desktop is there, the Sawfish's conventional VP doesn't make sense.
> We need a new definition, absorbing the old. This is the reason I did
> a bit of poll on VP and ID. (Sorry I haven't analyzed it.)

Infinite-desktop isn't really at odds with conventional viewports; it
just bypasses some of the restrictions and safeguards of the
conventional viewport system.  It's true that when x-offset and y-offset
aren't multiples of screen-width and screen-height (respectively) you're
not actually at a particular point on the viewport grid, but that's not
really a problem.  And if you've got dynamic viewports turned on there
isn't even a problem going off the edge of the current virtual desktop
since the viewport-tracking variables will be automatically updated.

--
Jeremy Hankins <nowan@...>

[Jeremy Hankins]

Teika Kazura <teika@...> writes:
> Hi.
>
> On Mon, 05 Oct 2009 15:51:48 -0500, Jeremy Hankins wrote:
>> Though why whether the window is maximized would be relevant is beyond
>> me.
>
> The root of evil must be matcher. When sawfish exits, all maximized
> windows are unmaximized.

I think I've found the problem: maximize calls
display-window-without-focusing, and display-window-without-focusing
calls move-viewport-to-window and move-window-to-current-viewport.

This means that as windows are taken up by sawfish the viewport keeps
getting moved, which means that all currently-managed windows are
shifted to suit that movement.  But the coordinates of each newly
managed window are understood to be relative to the *current* viewport,
even though that's constantly changing.

--
Jeremy Hankins <nowan@...>

[Jeremy Hankins]

I said:

> I think I've found the problem: maximize calls
> display-window-without-focusing, and display-window-without-focusing
> calls move-viewport-to-window and move-window-to-current-viewport.

One way to fix this would be to modify maximize so that it doesn't
switch to the viewport of the window that it's maximizing.  This would
involve minor modifications to maximize-window and slightly less minor
modifications to maximize-window-fullscreen (the main issue there is
that I'm not sure of the relationship between head-offset and head-dims
and the 0,0 point and screen dimensions -- I guess they're not always
necessarily the same?  If not, how do they relate to the offset and
dimensions of viewports?)

But the real issue, I think, would be get-visible-window-edges, in
sawfish.wm.util.edges.  We'd need a replacement that didn't return
visible edges, but instead gave edges visible from a specified viewport.
This ought to be possible, but it doesn't look very easy (at least for
me).


So before I put a lot of effort into trying to do this, does anyone have
a better idea?  It would of course be possible to have maximize-window
switch to the viewport of a window and then (conditionally) switch back
once the window is maximized, but besides the fact that this would
involve a lot of windows being moved and then moved back I worry about
screen flicker.  Is there a way to prevent the display from updating
during a process like that?

Or does anyone have another idea?

--
Jeremy Hankins <nowan@...>