Signed-off-by: Federico Mena Quintero <federico@novell.com>

Signed-off-by: Federico Mena Quintero <federico@novell.com>

Inside the X server, RRGetScreenSizeRange depends on information that was fetched
from a RRGetScreenResources.  So, we update the screen resources first to ensure
that we get up-to-date info for the screen size range.

Signed-off-by: Federico Mena Quintero <federico@novell.com>

The X server sent us a RANDR event, in fact, because it knows the latest
state of the outputs and it knows that something changed.

Signed-off-by: Federico Mena Quintero <federico@novell.com>

Signed-off-by: Federico Mena Quintero <federico@novell.com>

Gnome-settings-daemon will need these timestamps to distinguish between
RANDR events due to change-requests that it performs itself, from events
due to requests that happened from other clients (or from hotplug notifications).

Signed-off-by: Federico Mena Quintero <federico@novell.com>

Add _with_time() versions to the GnomeRR and GnomeRRConfig functions that change the RANDR configuration

We used to always pass CurrentTime to XRRSetCrtcConfig(), but we'll
need to distinguish real timestamps in gnome-settings-daemon.

Signed-off-by: Federico Mena Quintero <federico@novell.com>

If the caller of GnomeRR specifies a NULL callback, it means that the
caller is not interested in RANDR events.  In that case, it is not
necessary to actually ask the X server for those events, or to register
RANDR's events with GDK.

This prevents spurious events from being generated by gnome-settings-daemon
and gnome-control-center when they create a temporary GnomeRRScreen to save
the current configuration for backup purposes.

Signed-off-by: Federico Mena Quintero <federico@novell.com>

We don't care about property changes on outputs, as we only handle the
EDID_DATA property.  That property isn't likely to change on an
output, anyway.

Then, we don't do anything special when an individual output or CRTC
changes.  We just care if the screen layout changed in general; in
that case, we simply re-probe the outputs and call the caller's
callback.  The X server will emit RRScreenChangeNotify in conjunction
with the more detailed events, anyway, so we are guaranteed to know
when things change.

Signed-off-by: Federico Mena Quintero <federico@novell.com>

The labels are always drawn against a light pastel background.  When using an
inverse-colored theme (with text nearly white, backgrounds nearly black), we
want GnomeRRLabeler's labels to still be black.  Otherwise, the color from
the theme will be hard to read against the light pastel background in the
per-monitor labels.

Signed-off-by: Federico Mena Quintero <federico@novell.com>

Signed-off-by: Federico Mena Quintero <federico@novell.com>

This is why Laptop displays would appear taller in both GnomeRRLabeler and in
gnome-display-properties, as they were rendering the extra newline.

Signed-off-by: Federico Mena Quintero <federico@novell.com>

In some places GnomeDesktopThumbnailFactory uses two steps to generate
the thumbnail file path. The first produced the path and the second
appended the filename. This merges the second step into the first.
This also completes bug #580791.

Use GObject to allocate the private data structurue together with
public structure and automatically deallocate it at object destruction.

Make the application name (used for failed thumbnails) a static constant
to allow sharing it across instances.

This makes the display name heuristics work much better and makes
my monitor not 'Unknown' anymore.

This fixes the symptoms described in bug 578111 where rotations
get lost after applying one rotation. Thanks for Federicos help
in tracking this down.

We stopped building them a long time ago already...

See http://git.lespiau.name/cgit/shave/tree/README for more details.