Created attachment 112099 [details] [review]
patch

I should have mentioned that we plan to use the same approach to system-wide settings in other places (primarily for settings that are relevant on the login screen, such as power management preferences).

I should also say that the gconfd part of this patch is due to Behdad Esfahbod. 

This looks pretty good; some comments

 - should probably handle the case where the background is in the users
   home directory. Mostly because $HOME is not world-readable on most
   systems (Fedora in particular) and partly because the user may move
   the file. The easy solution here is to just make the "Set Default"
   button insensitive.. a better solution may include copying it to
   /usr/share/backgrounds/gnome-gconf-default.<file-extension>

 - another possibly useful thing would be the ability to set a background
   as mandatory. However, if we do that we probably need an easy way
   to clear the mandatory setting as well. Which would mean three buttons:

   [Make Default] [Make Mandatory] [Clear Mandatory]

   where the last button is insensitive unless something is mandatory
   already. And the first button is insensitive if something is mandatory.
   It might be better to use a browser-back-ish button, e.g. something
   like

     [Make Default |V]

   but we don't have GtkBrowserBackButton just yet (I need it in Nautilus
   for the clue bar too!)

Probably better to use /var/lib/backgrounds/gnome-gconf-backgrounds.<extension> since that is guaranteed to be writeable [1].

[1] : http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY

If I saw a "Make Default" button, I'm not sure I would understand that as the same thing as "set as login wallpaper". What's the usability rationale for including this across the desktop rather than in a centralised location such as Sabayon already provides?

In fact, "Make Default" is not the same as "Set as login wallpaper". 
It sets the system-wide default, not a login screen specific configuration.

I don't know that there is an elaborate 'usability rationale', but as far
as setting defaults goes, I think it is pretty natural to look for a way to do that in the same place where you configure the per-session settings. And
the gconf defaults mechanism allows us to do this in a very uniform way with
minimal overhead. Just look how small the patch is...

Also, the UI clutter is minimal. If you are not allowed to change the default background, the button will simply not show up.

Sabayon doesn't provide a centralized way to configure the login screen and has its own set of usability concerns.

Well, your use case was "allow the user to set the login screen background" and the proposed solution was "add a 'Set as Default' button to the background chooser". 

How does the user know that the login background uses the default background?

If the user wants to change the login background, won't they be looking for a "login window preferences" dialog?

What percentage of users actually want to set the default background if they don't know it changes the login background?

I agree the impact of adding this button is probably minimal, but I'm not convinced it addresses the original use case effectively.

(In reply to comment #7)
> Also, the UI clutter is minimal.

Well. Now we add a button to set the default wallpaper. Next we'll add buttons to set the default gtk theme, metacity theme, and fonts (and probably half of the other settings in g-c-c). And the only use case (apart from system administrators who, as Thomas pointed out, should use other tools and probably need more than just the wallaper setting, anyway), seems to be the gdm login screen.

I am very much unconvinced. I can't even begin to think of reasons why we would want to add mandatory settings.

I think the point is to make the experience more integrated.  having two wallpaper capplets would be silly.

We shouldn't have a settings dialog per app, but one per task.

Elevating a setting to be system wide shouldn't require doing a completely different set of steps, logging in as root, or running sabayon.

Sabayon is about making complete login profiles, not for changing one off settings.

I personally think there should be "Make Default" buttons everywhere.

Yes, two wallpaper capplets would be silly. But so would be putting "Make default" buttons everywhere.

I don't buy the "tighter integration" argument. Setting the GConf defaults is only marginally useful in the first place. The only valid non-admin use case I've seen so far is the gdm wallpaper, and in that case it's IMO the wrong solution, because

a) as Thomas pointed out, "Make Default" is obnoxious if you really want to say "Set Login Manager Wallpaper"
b) "Set Login Manager Wallpaper" is bad, too, because the action has side-effects
c) it may not even set the login manager wallpaper at all if e.g. a distro would configure the wallpaper by setting the key in the gdm user gconf source (which seems to be the correct thing to do) instead of abusing the GConf default.

In the end, it looks to me like we're trying to expose a gdm implementation detail in obnoxious and even broken ways. I won't oppose a "Set Login Manager Wallpaper" button, but it needs to work and actually do what it advertises.

I don't think having "Make default" buttons everywhere would be silly.  It would be useful.

I think this bug should be viewed somewhat independently from gdm.  It's a separate problem that just happens to have some overlap.  Being able to change the system defaults shouldn't require loading up a profile editor.

In Ubuntu Intrepid we have added (and offered upstream) a pair of buttons, "App[l]y System-Wide…" and "Reset", in both the Keyboard Preferences and the Network Proxy Preferences. The former button (with PolicyKit authentication) applies your current settings to GDM and to user accounts created from then on, while the latter changes your settings back to those currently used by GDM.

I'm not particularly happy with this design, for much the same reason as Jens: for the common scenario of a computer used by a single person, the controls are redundant (of course I want my settings to be used for the login screen too) and too prominent.

In the medium term I think the solution to this is for system settings windows to have a small set of menus, for generic but unobtrusive commands. This would:
*   include an "Edit" menu, solving the long-standing problem of where to put
    "Undo" (bug 97416);
*   include an "Apply" or similarly-named menu, if appropriate for the particular
    type of settings, with items for copying your personal settings to/from the
    login screen etc, solving the issue in this bug report;
*   include a "Help" menu, solving the problem of where to move the Help
    function if/when the redundant "Close" buttons are removed (bug 302076
    comment 6).

(Sorry, the problem of where to put "Undo" is actually bug 95110.)

Hi, it's now 6 months on since the last comment, 2.26 has been released, and both gdm-2.26 and gnome-screensaver make use of the default background without any way to specify this through the gui.  Comment 13 suggests that the code to deal with this exists, can that be integrated into upstream?

If there's difficulty in making a decision over how to access this, there was previously a gdmsetup tool for just specifying this.  Could that be reinstated if only for setting the system wallpaper?  Could pessulus be used?

The default background is stored in /etc/gconf/gconf.xml.defaults/%gconf-tree.xml, but I'd rather not edit that manually.  Is there a gconftool-2 command that can be used to specify defaults?

Any clearly specified tool for setting defaults (not necessarily just the wallpaper) would be appreciated, whether commandline or gui, but at the moment it appears to be randomly editing system XML files.  Have I missed something?

Hi,

You can set defaults in gconf using gconftool.  e.g.,

gconftool-2 --direct --config-source=$(gconftool-2 --get-default-source) --set /desktop/gnome/background/picture_filename --type string "/usr/share/backgrounds/foo.png"

or by running gconf-editor as root, changing a key there, right clicking on that key and choosing "set as default"

Created attachment 136237 [details] [review]
port to PolicyKit 1

Created attachment 136465 [details] [review]
updated patch

Adapt to changes in the GConf defaults api

The patch won't apply to master, it's a patch against a non-upstreamed patch...

Split off the PK 1.0 port of about-me to Bug 591796.

Created attachment 140764 [details] [review]
Updated patch against master

GDM uses the grey texture "system" background now, so there is no need to configure it.

Don't we still show a shield in some cases though?