Created attachment 50821 [details]
Screenshot of problem.

I don't have this problem. Perhaps it is a clearlooks or gtk+ 2.8 bug? There
were no layout changes recently, or anything to any code that would affect that.
I'm marking this as notabug.

None of the other capplets have this problem.  I am attaching a small patch
which fixes the problem.

Created attachment 50823 [details] [review]
Proposed patch

First of all, setting the border width on the dialog itself should never be
done. And the border width of the content and action areas of the dialog, are
already being set differently in the code. Applying your patch, I get a 24px
border around the action area. This is not acceptable.

Setting the border width on the dialog should never be done?  Dude, that is not
true.  Setting the border width of the dialog is done all over in GNOME.  One
example is gnome-control-center is found in the following glade file,
capplets/font-properties.glade. Another is capplets/gnome-mouse-properties.glade.  

The fact that some people do something, does not make the practice correct. The
only way to ensure that a dialog follows the HIG spacing requirements for
dialogs, is to embed the content inside a GtkVBox with a border width of 12,
which is embedded in the dialog's main vbox, and to use the following 3 lines of
code:

  gtk_widget_ensure_style (dialog);
  gtk_container_set_border_width (GTK_CONTAINER (GTK_DIALOG (dialog)->vbox), 0);
  gtk_container_set_border_width (GTK_CONTAINER (GTK_DIALOG
(dialog)->action_area), 12);

The capplet was doing something similar, but not exactly the same, before. I
just committed a patch that changes it to do exactly this. If the problem still
occurs, then something changed between gtk+ 2.6 and 2.8, or something in
clearlooks breaks this, and it is not a problem with the capplet, but a case of
broken ABI/API in gtk+, or a broken theme. You claim some recent change made
this happen, but none of the layout code has changed since the capplet was added
to gnome, in 2.6, which only means that the change must have happened outside of
the capplet. So, if it still does not work, then you need to figure out what
changed in gtk+ or clearlooks that broke it, because nothing changed in the
capplet itself, really. I would suspect a problem with the style properties
which it was setting, but even still, I would expect it to at least rever to the
default values for GtkDialog, which would have had no effect on the border of
the action area anyway, since its border width was already being set to 12 in
the code, if anything, it would have added 2px of border around both the action
area and the content.

Anyway, it looks like the problem was that the names of the style properties
changed to use - instead of _ as separators, in the new gtk+, which would be API
breakage between 2.6 and 2.8.

Hmmm, thanks for looking into this issue.  

Unfortunately, the method you used to make a dialog HIG compliant does not work.
 Using your recommendations at least with gtk+ 2.8, the border width around the
action area is actually 7 pixels, and the border width around the dialog->vbox
is actually 14 pixels.  I will attach a screenshot to illustrate.

You might want to take a look at bug #163850.   The method other dialogs in
GNOME use ensure that they are HIG compliant is to set the dialog's border width
to 5 pixels, the border width of the dialog->vbox to 5 pixels, and the spacing
of the dialog->vbox to 2 pixels.  This actually works as the end results are 12
pixels around and between the dialog->vbox and dialog's action areas.

Or rather:

  gtk_container_set_border_width (GTK_CONTAINER (dialog), 5);
  gtk_container_set_border_width (GTK_CONTAINER (GTK_DIALOG (dialog)->vbox), 5);
  gtk_box_set_spacing (GTK_BOX (GTK_DIALOG (dialog)->vbox), 2);

Created attachment 50871 [details]
Illustration of new border width issues

Since the previous attachment demonstrates that the problem is not in the
clearlooks theme.  Would you like it if I reassign the bug to gtk+?

That sounds horrible. Setting 2 opposing items to have border width values that
are an odd number of pixels, and add up to get you an even number of pixels is
just silly. You're basically telling me to do the exact same thing I'm doing
now, except in a worse way. I think there is something seriously wrong with your
system. Maybe in your ~/.gtkrc-2.0 or something. I have a quite abundant supply
of machines where I've tested this, and none of them have the problem, even
those running the new GTK+. I would highly suspect some custom gtkrc settings.

Either way, I can't get the problem to appear on any of my machines, and you're
the only person I've seen a complaint from, so I'm lowering the priority and
severity.

Thanks for responding.  Two small comments:
  
> You're basically telling me to do the exact same thing I'm doing now, except
in a worse way.

This is how it is does in gnome-panel, gnome-applets, gnome-utils, nautilus, and
many more GNOME modules.

> you're the only person I've seen a complaint from

Sorry if you interpret this bug report as a complaint.  I am just using bugzilla
to document a bug.  Really, I am not complaining.  

%cat ~/.gtkrc
# -- THEME AUTO-WRITTEN DO NOT EDIT
include "/usr/share/themes/Bluecurve/gtk/gtkrc"
# -- THEME AUTO-WRITTEN DO NOT EDIT

I don't know if this will help, but on my system setting the border width of the
dialog's action area does not work.  

In gnome-wp-capplet.c, I changed the "12" to "36" (in the line shown below), and
the action area's border still is 7 pixels.  Strange.

gtk_container_set_border_width (GTK_CONTAINER (GTK_DIALOG
(capplet->window)->action_area), 12);

try ~/.gtkrc-2.0 instead. This is a gtk2 app, not gtk1.2 :) I think something is
wrong with your configuration somewhere. It works fine afaict, on every system
I've tried it on (and it's been working fine since gnome 2.6, when it was added,
which was about 18 months ago).

I don't maintain those modules, so I'm not sure how they do things. I know many
dialogs in nautilus have not been even remotely HIG-compliant until now, though,
as I've seen them in action.

I agree.  Many of nautilus' dialogs are not HIG compliant except for its "File
Manager" preference dialog.  I don't have a ~/.gtkrc-2.0 in my home directory.

$ ls -l .gtkrc*
-rw-r--r--  1 develop develop 134 Aug 17 17:12 .gtkrc
-rw-rw-r--  1 develop develop  89 Jul 29 17:29 .gtkrc-1.2-gnome2

Well, maybe the problem will vanish when I do a clean install one of these days.
 I'll close this bug report if it does. 

OK. So I see what the problem is. I have no idea why I haven't been able to
reproduce this on any of the gtk+ 2.8 machines that I've tried it on until now
though.

Anyway, I just installed gtk+ 2.8 on my main machine, and got the same problem.
It seems that the following call has no effect in 2.8 for some reason:

  gtk_container_set_border_width (GTK_CONTAINER (GTK_DIALOG
(capplet->window)->action_area), 12);

I'm tempted to move this to gtk+, since it seems to be API breakage to me.
Anyway, the new patch that I'm about to attach seems to "fix" it. I'm uppping
the priority to blocker/immediate/etc... so we can get this in 2.12.0.

Created attachment 51681 [details] [review]
Patch to set border on action area with gtkrc string snippet

No API breakage here. The border width of the action_area of a dialog is
controlled by the GtkDialog::action-area-border style property, and as far as
I can see, this has been the case since 2001. If GTK+ 2.8 no longer lets you 
get away with overriding the border width, since it gets style-set emitted a
little more often now, that is actually an improvement.

OK. Well. That sucks. The only way to set style properties programmatically is
to do gtk_rc_parse_string (). I don't know why the border widths of things
should ever be set in the theme anyway, especially given that due to the
defaults in GTK+, and what the HIG says it should be, there are multiple ways
that people work around it to make things look somewhat compliant with the HIG.

Whatever though. I've committed my patch, since 2.12.0 was already rolled, and
the code freeze is over with.