There have been a couple of release candidates put out on 2.23.* ready for the 2.24.0 release, which will be part of GNOME 2.24.0 (we keep sync with GNOME’s version numbering). The only changes are a fix to GNOME bug 549479, which is about where desktop entries go and took a few tries to get right.
-
Development
-
Categories
- 2.20
- 2.21
- 2.22
- 2.23
- 2.24
- 2.25
- 2.26
- 2.27
- Bug hitlist
- Bug of the day
- Bugs and issues
- Compositing
- EWMH
- How-to
- Iain's compositor
- ICCCM
- journal
- Letters
- Metacity Labs
- nargery
- overview
- Policy
- Regressions
- releases
- Switching
- Testing
- Themes
- Themes v3
- Thought experiments
- Tools
- Translation
- Uncategorized
- Vectacity
-
Blogroll
-
Distro tweaks
-
Playground
-
Rationale
-
Things
-
Wikipedia
-
Archives
syndicate
2 Comments
I read http://blogs.gnome.org/metacity/2008/08/15/communicating-with-metacity/ and wrote a small program to tile windows (like Windows), which works as expected for normal windows. For gnome-terminal, gvim, and emacs windows, however, the windows are resized (subject to increments constraints) but not moved. If I change the WM_NORMAL_HINTS of those windows and immediately try to move/resize again, I get the same failure. If I first reload metacity after changing the WM_NORMAL_HINTS, then those windows can be moved/resized like normal windows. How do I make metacity reload the new WM_NORMAL_HINTS?
Nevermind that last comment. The problem was between my keyboard and my chair, and it has been corrected. I had mistakenly passed WM_NORMAL_HINTS around in the wrong format, although I’m not sure why restarting metacity was a workaround.