Yasumichi Akahoshi authored Sep 26, 2011 and Cosimo Cecchi committed Sep 26, 2011

https://bugzilla.gnome.org/show_bug.cgi?id=659999

It doesn't make sense to save settings specified on the command line in
GSettings, as the command line use is typically one-shot for a specific
purpose (or inside a script which will always append settings).

https://bugzilla.gnome.org/show_bug.cgi?id=572817

Didier Roche authored Sep 26, 2011 and Cosimo Cecchi committed Sep 26, 2011

Unity has a feature that enables static Quicklist entries. Those
entries are always displayed on right click once the application is
added to the launcher.

https://bugzilla.gnome.org/show_bug.cgi?id=642567

Pick a random name for the temporary file, then unlink it immediately
after it has been loaded into memory.

This way we can unref the flash object immediately instead of waiting
after the mainloop has quit.

If we're running under GNOME Shell, use its interface to get a
screenshot instead of poking X directly.

https://bugzilla.gnome.org/show_bug.cgi?id=657330

Right now we have a somewhat byzantine process for saving files:
- we trigger a child process that saves the screenshot in /tmp as soon
  as the pixbuf is available
- we call into NautilusFileOperations to copy that tmp pixbuf into the
  user-specified file

The only reason why this would be needed nowadays is to support DnD from
the dialog to e.g. the desktop, or a folder. Remove support for that
(we're going towards a completely headless gnome-screenshot anyway) and
refactor the rest of the code to use simple async GIO methods instead.

Simplify and refactor the code around the interactive dialog and use an
unified config object instead of passing around configuration options.

Move the async function that builds a filename into a separate file.

In order to grab a screenshot of a window we currently peek at the WM
decorated X window size and coordinates, and cut a pixbuf from the root
window using those dimensions.

This unfortunately breaks with invisible window borders, as the WM
window is actually bigger than expected, resulting in an unwanted frame
around the image. Mutter now stores the real dimensions of the window
decorated frame in _NET_FRAME_EXTENTS, so we can just use that
information to get the actual region to cut.

Mutter also stopped setting the XShape bounding box on rounded corners,
as they're now properly antialiased. Our code that takes the XShape
rectangles and makes the area outside of their bounding box transparent
also needs to be updated to handle the case where the WM decorated window
size is different from the frame extents.

Tested with GNOME Shell/Mutter and Metacity.

https://bugzilla.gnome.org/show_bug.cgi?id=659885