Re: saving window states

"Matthias Clasen" <Matthias Clasen poet de> writes: 
> But there is no individual window whose state you could record, unless I 
> misunderstood what you are trying to achieve: Having mozilla main windows
> come up maximized, but mozilla dialogs not.

It varies somewhat by application. For example, a file manager would
save the window state per-directory normally; but all directory
windows have the same class. Mozilla would save the same state for all
its windows, but a word processor or image editor might save the state

> 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

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.

The other problem with doing it based on class, again, is the file
manager example, where we want the same _kind_ of window to have
different state depending on what is being viewed inside the window.

We get a steady stream of bugs against both apps and the window
manager for not saving state in this way. So my question is, how do we
establish where to fix these bugs, what's the realistic solution.

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.

> Now its just a matter of finding the dsssl docbook stylesheet
> parameter for section numbering. If you are not an exerienced DSSSL
> programmer, I can look into producing a customized stylesheet
> tonight. Oh, the db2ps call needs similar treatment.

I'd appreciate it if you looked at this - you have a CVS account on don't you? If not send me a login/crypted passwd.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]