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 545115 - should ask for confirmation before writting the changes
should ask for confirmation before writting the changes
Status: RESOLVED FIXED
Product: gnome-control-center
Classification: Core
Component: Display
2.23.x
Other Linux
: Normal normal
: ---
Assigned To: Federico Mena Quintero
Control-Center Maintainers
: 565760 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-07-28 09:48 UTC by Sebastien Bacher
Modified: 2009-01-27 21:45 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
Screenshot of a 640*480 desktop where the Apply button is hided below the screen border (58.02 KB, image/png)
2008-11-26 23:10 UTC, mdiagom
  Details
gnome-desktop-bnc545115-randr-backup-configuration.diff (18.90 KB, patch)
2009-01-27 20:34 UTC, Federico Mena Quintero
none Details | Review
gnome-desktop-bnc545115-randr-backup-configuration.diff (18.90 KB, patch)
2009-01-27 20:34 UTC, Federico Mena Quintero
committed Details | Review
gnome-settings-daemon-bgo545115-randr-confirmation.diff (28.65 KB, patch)
2009-01-27 21:43 UTC, Federico Mena Quintero
committed Details | Review

Description Sebastien Bacher 2008-07-28 09:48:56 UTC
there is still lot of cases where the video drivers are buggy when using xrandr, the new xrandr capplet should ask for confirmation and revert automatically after 15 seconds if the changes are not confirmed. Right now if some setting crash xorg the user will not be able to log in again until having used the command line to remove the configuration
Comment 1 mdiagom 2008-11-26 23:10:05 UTC
Created attachment 123503 [details]
Screenshot of a 640*480 desktop where the Apply button is hided below the screen border
Comment 2 mdiagom 2008-11-26 23:10:59 UTC
Or simply imagine that the user selects by mistake a resolution so small (let's say 640*480) that the Apply button of the resolution window goes below the screen border, so it's impossible to select again a good resolution and click on Apply. See the attached screenshot in comment 1 if the problem is not clear :)

There should really be a confirmation message somewhere...
Comment 3 Jens Granseuer 2008-12-27 12:23:20 UTC
*** Bug 565760 has been marked as a duplicate of this bug. ***
Comment 4 Luke Faraone 2009-01-12 21:05:11 UTC
By the way, Ubuntu had implemented a patch in Hardy: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-control-center/+bug/197673
Comment 5 Federico Mena Quintero 2009-01-27 20:34:24 UTC
Created attachment 127358 [details] [review]
gnome-desktop-bnc545115-randr-backup-configuration.diff

This is the patchset I committed to gnome-desktop for this.  It adds a filename argument to gnome_rr_apply_stored() so that gnome-settings-daemon can try the backup file if it exists.

I'll commit the corresponding patch for gnome-settings-daemon in a second.
Comment 6 Federico Mena Quintero 2009-01-27 20:34:40 UTC
Created attachment 127359 [details] [review]
gnome-desktop-bnc545115-randr-backup-configuration.diff

This is the patchset I committed to gnome-desktop for this.  It adds a filename argument to gnome_rr_apply_stored() so that gnome-settings-daemon can try the backup file if it exists.

I'll commit the corresponding patch for gnome-settings-daemon in a second.
Comment 7 Federico Mena Quintero 2009-01-27 21:43:55 UTC
Created attachment 127361 [details] [review]
gnome-settings-daemon-bgo545115-randr-confirmation.diff

This is in gnome-settings-daemon now.
Comment 8 Federico Mena Quintero 2009-01-27 21:45:09 UTC
Fixed now in trunk for both gnome-desktop and gnome-settings-daemon.

From gnome-desktop:

2009-01-27  Federico Mena Quintero  <federico@novell.com>

	http://bugzilla.gnome.org/show_bug.cgi?id=545115 - Ask for
	confirmation, with a timeout, after changing the RANDR
	configuration for if we leave the user with an unusable display.
	This also handles the case where the machine may crash after
	changing the configuration; the old/known-good configuration will
	be restored when the user restarts his session.

	Add public API to get to $(XDG_CONFIG_HOME)/monitors.xml and a
	backup of that file (monitors.xml.backup):

	* libgnomeui/gnome-rr-config.h
	(gnome_rr_config_get_backup_filename,
	gnome_rr_config_get_intended_filename): New prototypes.

	* gnome-rr-config.c (gnome_rr_config_get_backup_filename): Implement.
	(gnome_rr_config_get_intended_filename): Implement.
	(get_config_filename): Replaced by gnome_rr_config_get_intended_filename().

	Create the backup file:

	* gnome-rr-config.c (gnome_rr_config_save): Create a backup file
	of monitors.xml when saving a new configuration.

	Remove the use of the "old" version of the configuration format
	(which was never in a public release):

	* gnome-rr-config.c (get_old_config_filename): Removed.
	(configurations_read): Don't fall back to the pre-XDG location of
	the configuration file.
	(gnome_rr_config_save): Don't delete the pre-XDG configuration
	file anymore.

	Pass a filename argument to gnome_rr_config_apply_stored() so we
	can try the backup configuration from gnome-settings-daemon, for
	recovery after a failed reconfiguration:

	* gnome-rr-config.c (configurations_read): Removed, as
	configurations_read_from_file() does everything we need now.
	(gnome_rr_config_apply_stored): Take a filename argument; this
	indicates from which file the configuration will be read.

	* libgnomeui/gnome-rr-config.h (gnome_rr_config_apply_stored):
	Update prototype with the filename argument.
	

From gnome-settings-daemon:

2009-01-27  Federico Mena Quintero  <federico@novell.com>

	http://bugzilla.gnome.org/show_bug.cgi?id=545115 - Ask for
	confirmation, with a timeout, after changing the RANDR
	configuration for if we leave the user with an unusable display.
	This also handles the case where the machine may crash after
	changing the configuration; the old/known-good configuration will
	be restored when the user restarts his session.

	Refactor:

	* plugins/xrandr/gsd-xrandr-manager.c
	(apply_stored_configuration_at_startup): Factor out the logic to
	apply the stored configuration at startup.
	(gsd_xrandr_manager_start): Use the function above.

	During startup, restore the backup configuration if it existed, to
	recover from the case when the machine crashes while applying an
	intended configuration.

	* plugins/xrandr/gsd-xrandr-manager.c
	(apply_stored_configuration_at_startup): First see if we have a
	backup configuration; if so, it means the machine or g-s-d crashed
	while changing the RANDR parameters.  If there is no backup
	configuration, then we have a known-good configuration which we
	can use.
	(apply_intended_configuration): New function, used to load the
	intended configuration (i.e. the non-backup one).
	(restore_backup_configuration): Utility function to overwrite the
	known-bad configuration with the known-good backup one.

	Use a timeout-confirmation dialog after changing the display
	configuration:

	* plugins/xrandr/gsd-xrandr-manager.c
	(try_to_apply_intended_configuration): New function; applies the
	intended configuration, restores the backup configuration if that
	fails, or asks the user to confirm if the intended configuration
	is usable.
	(gsd_xrandr_manager_apply_configuration): Use
	try_to_apply_intended_configuration() in the implementation of the
	D-Bus method to apply RANDR configurations.  This way all apps
	which use this D-Bus method will get confirmation for free.
	(output_rotation_item_activate_cb): Use
	try_to_apply_intended_configuration() so that the RANDR tray-icon
	also uses the confirmation/backup logic.
	(restore_backup_configuration): Restore the screen configuration
	itself in addition to restoring the file on disk from the backup.
	(user_says_things_are_ok): New utility function to handle a
	timeout-confirmation dialog.

	Fix error reporting at startup:

	* plugins/xrandr/gsd-xrandr-manager.c (error_message): Handle the
	case where the status_icon is not created yet; this happens during
	startup or when the status_icon is disabled by the user.

	Handle the case where there is no matching configuration at
	startup; this is not an error:

	* plugins/xrandr/gsd-xrandr-manager.c
	(apply_intended_configuration): "no matching configuration" is not
	an error when looking for a suitable configuration in
	monitors.xml; it simply means that the user has a different set of
	monitors than the ones that are available in that file.