1. 15 Mar, 2012 2 commits
  2. 01 Mar, 2012 1 commit
    • Rui Matos's avatar
      window: Remove prefs listener in _unmanage instead of _finalize · 860c2a62
      Rui Matos authored
      After _unmanage the object is semantically dead even if technically it's not,
      so remove the prefs listener here to prevent it being called for a dead
      object.
      
      In particular this fixes a crash when starting up gnome-shell with at least
      one gimp utility window opened which causes mutter to create a MetaWindow for
      it only to immediately get an UnmapNotify afterwards which causes mutter to
      unmanage the MetaWindow. Afterwards prefs_changed_callback is called for this
      dead MetaWindow and tries to dereference the window->monitor pointer which is
      already NULL.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=671087
      860c2a62
  3. 23 Feb, 2012 1 commit
  4. 16 Feb, 2012 1 commit
  5. 18 Jan, 2012 1 commit
  6. 15 Dec, 2011 3 commits
  7. 14 Dec, 2011 1 commit
  8. 12 Dec, 2011 4 commits
  9. 26 Nov, 2011 1 commit
  10. 11 Nov, 2011 1 commit
  11. 08 Nov, 2011 1 commit
  12. 05 Nov, 2011 1 commit
  13. 20 Oct, 2011 1 commit
  14. 18 Oct, 2011 2 commits
  15. 17 Oct, 2011 2 commits
  16. 24 Sep, 2011 2 commits
  17. 14 Sep, 2011 1 commit
  18. 12 Sep, 2011 1 commit
  19. 27 Aug, 2011 2 commits
    • Dan Winship's avatar
      window: only attach dialogs to NORMAL, DIALOG, and MODAL_DIALOG windows · 2be1574e
      Dan Winship authored
      Attaching dialogs to unusual windows (like the desktop) looks bad, so
      don't do it.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=646761
      2be1574e
    • Dan Winship's avatar
      window: make determination of attached dialog windows more consistent · 7f8c5961
      Dan Winship authored
      Different bits of code were using slightly different checks to test
      whether a window was an attached dialog. Add a new
      meta_window_is_attached_dialog(), and use that everywhere.
      
      Also, freeze the is-attached status when the window is first shown,
      rather than recomputing it each time the caller asks, since this could
      cause problems if a window changes its type after it has already been
      attached, etc. However, if an attached window's parent is destroyed,
      or an attached window changes its transient-for, then fix things up by
      destroying the old MetaWindow and creating a new one (causing
      compositor unmap and map events to be fired off, allowing the display
      of the window to be fixed up).
      
      Remove some code in display.c that tried to fix existing windows if
      the gconf setting changed, but which didn't actually do anything (at
      least under gnome-shell). However, if 654643 was fixed then the new
      behavior with this patch would be that changing the gconf setting
      would affect new dialogs, but not existing ones.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=646761
      7f8c5961
  20. 09 Aug, 2011 5 commits
  21. 27 Jul, 2011 1 commit
  22. 07 Jul, 2011 2 commits
  23. 31 May, 2011 1 commit
  24. 25 May, 2011 1 commit
  25. 18 May, 2011 1 commit