Re: saving window states

["Matthias Clasen" <Matthias Clasen poet de>]

> > I consider that configuration, because you would typically put 
something 
> > like the
> > following (for fvwm2) in the wm config file:
> > 
> > Style   "Mozilla"       StartsMaximized, StartsRaised
> 
> What I'm trying to achieve is that this happens automatically; if the
> user maximizes mozilla, then it should be maximized next time they
> open it. Or if they put their home directory folder window in a
> or evolution main window in a certain spot, it comes back in that
> spot.

I would be seriously annoyed if the wm would start maximizing all new 
mozilla
windows just because I happened to close the last one while it was 
maximized.

The functionality you want can already be provided on both sides: the wm 
can
add an "Remember to maximize similar windows" item to its frame menu; the
app can add a preference "Start maximized". Just drop the idea that any of
this should happen automatically, it doesn't make sense. 

> However, I can't just automatically save state for all windows,
> because in the real world, this means that many applications
> break. Mozilla has the same class on everything. Java sets the class
> based on which widget is used for the toplevel, so a similar thing
> happens. There are too many bugs introduced by enabling
> auto-save-state for all windows based on class.

Another argument for dropping the "automatic" bit. I wonder why you expect
broken apps to pick up your new state saving mechanisms, but not fix the 
more
fundamental brokenness of not assigning the proper types to their dialogs.

> Right now many apps already have their own ad hoc code to save/restore
> state. For example Mozilla does. Do we consider that a bug in Mozilla?
> If yes, how will we automatically save/restore state for Mozilla? If
> no, we just need to write in the spec that apps should save/restore
> their own state. If we put that in the spec, how does the user 
> request a placement algorithm be used instead?
>
> I think it's clear that app authors consider saved state to be a
> requirement for their apps, thus I would like the spec to specify
> unambiguously how this should be done.

I think your use cases clearly indicate that different apps have vastly 
different
expectations about what and how state is to be saved. Thus I think it is
best to let apps maintain such state if they think they need to - of 
course, I 
think such app authors are seriously confused about the division of labor 
between
client and wm. 

Regarding the placement algorithm vs. same place question: I think the 
best 
would be to add an app preference: "Open new windows at the same 
position", 
which users could just turn off to let windows be placed by whatever 
algorithm 
their wm uses. I don't think we want to start standardizing placement 
algorithms, 
do we ?