After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 81802 - Metacity doesn't remember window positions (and other state)
Metacity doesn't remember window positions (and other state)
Status: RESOLVED DUPLICATE of bug 91481
Product: metacity
Classification: Other
Component: EWMH specification
unspecified
Other other
: High enhancement
: future
Assigned To: Metacity maintainers list
Metacity maintainers list
: 84984 95199 95234 95247 (view as bug list)
Depends on: 91481
Blocks:
 
 
Reported: 2002-05-14 22:38 UTC by Ryan Muldoon
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
Small write up on my history patch. (3.41 KB, text/plain)
2003-01-09 22:22 UTC, Benjamin Kahn
Details

Description Ryan Muldoon 2002-05-14 22:23:20 UTC
Package: metacity
Severity: normal
Version: 2.3.233.0.200205140359-0
Synopsis: Metacity doesn't remember window positions
Bugzilla-Product: metacity
Bugzilla-Component: general

Description:
I am pretty pleased with Metacity, except that it doesn't remember where
I placed windows the last time I ran them.  I always put my galeon and
evolution in the same place (both position and workspace)....sawfish
never got the workspace right, but it would position things in the same
place.  Maybe this is a session management bug, but I'd imagine it is a
metacity missing feature.




------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-05-14 18:23 -------

Reassigning to the default owner of the component, hp@redhat.com.

Comment 1 Havoc Pennington 2002-05-15 01:08:36 UTC
I consider this an undefined/unspecified area. The best thing 
at the present time is for apps to save their position themselves, but 
I think a specification for handling this may be better in the end.
Apps can't record all relevant state, really.

Anyhow, there's no Metacity coding to be done until someone plans how
it should work.
Comment 2 Luis Villa 2002-05-30 20:34:25 UTC
Is enhancement a fair title for this? As it stands, most of the core
apps are going to have decent sm soon...
Comment 3 Havoc Pennington 2002-09-24 18:24:06 UTC
*** Bug 84984 has been marked as a duplicate of this bug. ***
Comment 4 Havoc Pennington 2002-10-08 18:38:00 UTC
*** Bug 95199 has been marked as a duplicate of this bug. ***
Comment 5 Havoc Pennington 2002-10-09 02:15:35 UTC
*** Bug 95234 has been marked as a duplicate of this bug. ***
Comment 6 Havoc Pennington 2002-10-09 02:21:42 UTC
BTW, for people who want a workaround, Ross Burton wrote a tool called
"Devil's Pie" which uses libwnck to control metacity remotely and
provide "matched window" type functionality.
Comment 7 Havoc Pennington 2002-10-09 04:37:13 UTC
*** Bug 95247 has been marked as a duplicate of this bug. ***
Comment 8 Benjamin Kahn 2002-11-20 06:14:33 UTC
I've made a patch which impliments some of this behavior:

http://bugzilla.gnome.org/showattachment.cgi?attach_id=12419

Window history is stored in ~/.metacity/window_history using XML. This
is a sample of the format:

<metacity_history>
  <window id="bar" class="XTerm" name="xterm" title="/foo/bar"
role="blah" type="normal" num="0">
     <geometry x="100" y="100" width="200" height="200"
gravity="northwest"/>
  </window>
  <window ....>
  </window>
   :
</metacity_session>

Metacity loads this file once during initialization right after it
opens the display.  The file is written to as Metacity is exiting.  It
needs to load the file after it has possibly replaced an already
running window manager so any changes to the history file are commited.

Window history is not consulted or updated on windows which exist when
Metacity is starting.

When a window is mapped, it is given a number of -1 which means
undefined.  During placement, the list of windows on the current
workspace is scanned for windows with similar class/name/role
characteristics.  (Scan for windows like that with num 0, 1, 2, 3,
etc.)  Assign num to the next open slot.  Check the history for an
entry matching class/name/role/num and retrieve the saved position of
the window, if any.  

If a match is found, scan the list of windows to make sure no window
is already in the stored position.  If it is, fall back to other
placement routines.  (First fit then cascade)

If a match is not found, fall back to other placement routines.

When a window is moved, check the list of similar windows and try to
find a lower number which isn't allocated currently.  Update the saved
state with the new window position.

We try to find a smaller window number for this reason:

   - Open 3 calculators.  Move them around and then close the first
     two.  Use the third for a while and move it to a nice spot.
     Close the final calculator.  Where should the calculator start if
     you open a new one now?  It should start where you last left the
     final calculator before you closed it.  Renumbering accomplished
     that.

At the moment, I store the window size as well as the window position,
but I make no attempt to restore it.  I'm not convinced that should be
restored.
Comment 9 Heath Harrelson 2002-11-22 03:22:30 UTC
*** Bug 97922 has been marked as a duplicate of this bug. ***
Comment 10 gemi 2002-12-02 01:01:09 UTC
I support the request the support for placement history as in
sawfish. It is especially important for older software that don't
do it themselves. Indeed most apps that I use don't save their
window position.
Comment 11 Havoc Pennington 2002-12-02 01:20:55 UTC
gemi - there's no need to "me too" on bug reports.
I have always been in favor of this feature, but only if 
it can be implemented reliably. Benjamin is working on it.
We'll see how it goes.
Comment 12 Benjamin Kahn 2003-01-07 23:27:54 UTC
http://bugzilla.gnome.org/showattachment.cgi?attach_id=13409

This version of the patch works well for me and has been getting good
testing.  
Comment 13 Benjamin Kahn 2003-01-09 22:22:04 UTC
Created attachment 13455 [details]
Small write up on my history patch.
Comment 14 Havoc Pennington 2003-02-25 08:02:02 UTC
Benjamin - is this the most recent version of your patch, or is that 
on another bug? (if so should we dup one bug on the other?)
I hope to look at this patch in the next week or so.
Comment 15 Havoc Pennington 2003-02-26 20:06:02 UTC
argh, I'm asking people questions when they aren't on the cc list...
Comment 16 Benjamin Kahn 2003-02-26 20:16:08 UTC
The patch is in bug 91481.  

We could dupe or make one bug depend on the other...
Comment 17 Rob Adams 2003-03-31 16:13:09 UTC

*** This bug has been marked as a duplicate of 91481 ***