Though I think this is an application specific issue rather than in GTK+, I'm not sure.

*** Bug 711343 has been marked as a duplicate of this bug. ***

I'll post here in 12 hours time what I have in Cinnamon, but you can see the referenced bug in the above comment, which shows you aren't alone here.

Created attachment 259391 [details]
Shutdown Dialog - Cinnamon

Shutdown Dialog - Cinnamon

Created attachment 259392 [details]
Open FIle Dialog - Cinnamon

Created attachment 259393 [details]
Cinnamon Settings - Cinnamon

Created attachment 259394 [details]
pkexec Authentication Dialog

As you can see in my pictures, I also have buttons which have the bottoms cut off in Cinnamon with GTK 3.10. These are taken in ArchLinux.

Created attachment 259698 [details]
Interactive GNOME screenshot 1

With update to gtk3.10.3-1 in ArchLinux:
Shutdown Dialog now fine.
Open Dialog now fine.
Cinnamon Startup Application Preferences now fine.
pkexec Authentication Dialog now fine.

However, Interactive GNOME screenshot still playing up (this is one of two).

Created attachment 259699 [details]
Interactive GNOME screenshot 2

With update to gtk3.10.3-1 in ArchLinux, second of two screenshots.

that does not really look like gnome-screenshot. There's an extra black title up top, 'Screenshot' - where does that come from ?

Matthias, that is gnome-screenshot, in interactive mode, in Cinnamon 2.0.10 on ArchLinux.

Created attachment 259706 [details]
gnome-screenshot

Here is a screenshot of gnome-screenshot on my system - notice the absence of that black bar with the label 'Screenshot'. I don't know what adds that on your system, and I'm somewhat suspicious that it may push the content down just far enough to cut the buttons off.

oh, I know - thats the fallback app menu - is it not ?

indeed, I've reproduced it now.

Latest update to gnome-screenshot on ArchLinux with Cinnamon resolves issue.

I'd like to ask you to re-open this bugreport. I can reproduce the issue with the cut buttons with all themes that use the default gtk engine, in Ubuntu using 3.10.7-0ubuntu1.

Themes using other engines (i.e. Adwaita) or svg assets don't have that problem.

As far as I can tell, only GtkDialog is affected.

I can also submit a new bugreport for this problem, but at least the symptoms seem to be the same.

I can confirm that this bug is still present with GTK3 3.10.7. I found it on my Archlinux + GNOME install using Numix as theme and I can reproduce it on Archlinux + Xfce using Greybird as theme.

Please, re-open this since it's far away from being fixed.

fwiw, I can't reproduce this with Gtk out of git.

@desrt: I presume you didn't test with Adwaita but with a theme that uses only the default gtk engine?

I used adwaita.

(In reply to comment #21)
> I used adwaita.

Can you please try with Greybird as theme?
What application did you tried to tell that you can't reproduce the bug?

@des(In reply to comment #21)
> I used adwaita.

Yeah, as I mentioned above it's not reproducible with Adwaita or Ambiance (unico-engine). This is a problem with Gtk3.10, GtkDialog and the default gtk engine.

I also don't see the problem with the default theme.

(In reply to comment #24)
> I also don't see the problem with the default theme.

No, not the default theme. Simon is referring to the built in engine i.e. not adwaita engine.

Greybird, Numix etc use the built in GTK3 engine and the button borders are drawn by CSS unlike Adwaita, where they are drawn by SVG assets.

> (In reply to comment #24)
> > I also don't see the problem with the default theme.
> 
> No, not the default theme. Simon is referring to the built in engine i.e. not
> adwaita engine.

that's what "default theme" means.
 
> Greybird, Numix etc use the built in GTK3 engine and the button borders are
> drawn by CSS unlike Adwaita, where they are drawn by SVG assets.

given that two different themes do not expose this issue, are you sure this isn't a bug in the Numix and Greybird theme engines, instead?

in any case, don't change to VERIFIED INCOMPLETE.

(In reply to comment #26)
> given that two different themes do not expose this issue, are you sure this
> isn't a bug in the Numix and Greybird theme engines, instead?

Just to keep things clear, Numix and Greybird don't have "theme engines", only css-code which gets rendered by the builtin Gtk3 engine.

(In reply to comment #26)
> > (In reply to comment #24)
> > > I also don't see the problem with the default theme.
> > 
> > No, not the default theme. Simon is referring to the built in engine i.e. not
> > adwaita engine.
> 
> that's what "default theme" means.

Well, he said "default engine", not "default theme".

> > Greybird, Numix etc use the built in GTK3 engine and the button borders are
> > drawn by CSS unlike Adwaita, where they are drawn by SVG assets.
> 
> given that two different themes do not expose this issue, are you sure this
> isn't a bug in the Numix and Greybird theme engines, instead?

Numix, Greybird etc use the in-built engine in GTK. So if this is a bug with their theme engine, it's a bug in GTK.

Also, I've also seen the issue in Adwaita, as you can see in https://bug710909.bugzilla-attachments.gnome.org/attachment.cgi?id=258156

As a sidenote, Adwaita and Ambiance use SVG assets for drawing the borders, while Numix, Greybird etc. draw the border with CSS. That means Adwaita has a more wide border than 1px, so this issue might be cloaked in it.

> in any case, don't change to VERIFIED INCOMPLETE.

Ok. But it's not RESOLVED FIXED either.

I'm attaching a screenshot showing an instance of this bug on
(fully updated) Fedora 20. The code uses gtk_dialog_new_with_buttons
for the Cancel and OK buttons, and (for this particular use of
the dialog) adds a Help button using gtk_container_add and
gtk_button_box_set_child_secondary on the dialog's action_area.
The Help button displays correctly but the other two are broken
as described by others.

Created attachment 269039 [details]
picture of bad buttons

re-opening, as per last comments.

(In reply to comment #28)
> Ok. But it's not RESOLVED FIXED either.

According to comment #24 it is for GTK+ master / 3.11.x - have you been able to reproduce the issue with a current development snapshot / unstable version?

curious, that screenshot shows supposedly aligned buttons, some of which are cut off and some are not

(In reply to comment #29)
> The code uses gtk_dialog_new_with_buttons
> for the Cancel and OK buttons, and (for this particular use of
> the dialog) adds a Help button using gtk_container_add and
> gtk_button_box_set_child_secondary on the dialog's action_area.

I just checked, and cutting out the call to gtk_button_box_set_child_secondary doesn't help. Simply, adding the Help button to the dialog's action area via gtk_container_add somehow pushes the other buttons out of alignment: they appear to be shifted down a pixel or two so their bottoms are cut off.

No such problem with GTK 2.

(In reply to comment #33)
> curious, that screenshot shows supposedly aligned buttons, some of which are
> cut off and some are not

Ah, the cut-off disappears if I use gtk_button_box_set_child_non_homogeneous
on the added Help button. This exposes the fact that the Cancel and OK buttons are "naturally" less tall than the Help button. The resulting appearance is not very pleasing (looks a bit odd that the buttons are of different y dimensions).
I'll attach another screenshot.

Created attachment 269051 [details]
with non-homogeneous buttons

I have found that the buttons are cut from sides in various dialogs. Using GTK3.11 on Fedora rawhide.

Created attachment 269934 [details]
Buttons cut from sides in GTK dialogs

I just noticed (and got other to confirm) that being able to reproduce this issue seems to be connected to font-settings.

I can reproduce it with: Droid Sans <=10, 96 DPI, font hinting: slight

I can't reproduce it with: Droid Sans 11, 96 DPI, font hinting: slight

For other fonts, size 10 also works, e.g. Open Sans 10, 96 DPI, font hinting: slight.

So seems like some calculations on the label-text are going wrong and then the bottom of the widget gets pushed out of the allocated size or something?

(In reply to comment #38)
> Created an attachment (id=269934) [details]
> Buttons cut from sides in GTK dialogs

This is rather a mismatch between the theme and the way gtkmessagedialog buttons are now placed.

To make any progress here, we need a very explicit set of reproduction instructions.

- What version of GTK+
- What theme
- What fonts
- What dialog in what application

I've tried in vain to reproduce cut-off buttons with Adwaita, Ambiance, Radiance, Raleigh, Droid Sans 9, 10, 11...

(In reply to comment #41)
> To make any progress here, we need a very explicit set of reproduction
> instructions.
> 
> - What version of GTK+
> - What theme
> - What fonts
> - What dialog in what application

Speaking for comments #34 and #35:

gtk 3.10.6
Adwaita
DejaVu Sans 10
gretl: /Variable/X-12-ARIMA analysis

> This is rather a mismatch between the theme and the way gtkmessagedialog
buttons are now placed.

So how are they placed and what can I do to fix the placement with the default gtk engine?
(I'm happy to change the theme-code, but I didn't know I have to from Gtk3.8 to 3.10.)


My setup:
Gtk3.10.7
Greybird (https://github.com/shimmerproject/Greybird)
Droid Sans 9/10 (96 DPI)
GtkFileChooserDialog, e.g. in Gedit or Evince

This is the gtkfilechooser-dialog in Evince with the above setup, exhibiting the problem: http://www.zimagez.com/zimage/screenshot-2014-03-04-103522.php

I meanwhile tested various ways of adding padding to those buttons like -GtkButton-default-border=2 or -inner-border=2 fix it, but then the label is vertically not centered anymore, as can be seen here in Gedit: http://www.zimagez.com/zimage/screenshot-2014-03-04-103717.php.

@mclasen: thanks for not giving up on this!

Created attachment 270920 [details]
Minimal test case

I'm attaching a minimal case which displays "cut" buttons with gtk 3.10.7 + Adwaita + DejaVu Sans, and also shows a (not fully satisfactory) workaround.

@matthias I have just the following code for button,

* {
    -GtkButton-child-displacement-x: 0;
    -GtkButton-child-displacement-y: 0;
    -GtkButton-default-border: 0;
    -GtkButton-image-spacing: 0;
    -GtkButton-inner-border: 1;
    -GtkButton-interior-focus: true;
}

.button {
    -GtkWidget-focus-padding: 1;
    -GtkWidget-focus-line-width: 0;

    padding: 3px;
    border-width: 1px;
    border-radius: 2px;
    border-style: solid;
    border-color: shade(@theme_bg_color, 0.8);
    background-color: shade(@theme_bg_color, 1.08);
    background-image: none;
    color: @theme_fg_color;
}

What I'm doing wrong?

(In reply to comment #44)
> Created an attachment (id=270920) [details]
> Minimal test case
> 
> I'm attaching a minimal case which displays "cut" buttons with gtk 3.10.7 +
> Adwaita + DejaVu Sans, and also shows a (not fully satisfactory) workaround.

Thanks for the test case ! It works fine here with gtk master and either Raleigh or Adwaita.

I don't have the time to build 3.10 right now, unfortunately.

@mclasen: Even if the buttons aren't cut here with Adwaita, the labels on the buttons are clearly not vertically centered (which seems to be part of the problem): http://www.zimagez.com/zimage/screenshot-2014-03-06-005000.php

Ok, a bit more information that I've gathered over the last week:

1) labels are now baseline-aligned, so this might be related to the cutting off.
2) I found a workaround for the problem in the theme, see here: https://github.com/shimmerproject/Greybird/commit/e235cb445f29a2443fdfb90014e9b28af3c73caa

After being informed about 1), I understand why even Adwaita looks "off" for me, because in Gnome3 you don't have ButtonImages=1, so the different look between Gtk2 and Gtk3 isn't visible. Maybe that change should also be made in Gtk2 to ad least preserve a bit of consistency for those who still use a desktop with a mix of both 2 and 3 (just as an example, Xfce is still completely on Gtk2, but Xubuntu obviously ships many Gtk3 apps).

So with the patch from 2) my buttons don't get cut off anymore and when disabling ButtonImages, I get the look I expect.

Is anybody still having problems with this ?

Well it's pretty simple: since I applied the workaround I'm fine. Without it, the bug is still there.

Whether or not this is the desired behavior is up to you I guess. As mentioned above, it'd be nice in terms of consistency to see Gtk2 being patched for simple – but visually noticeable – changes like this one.

I'm seeing this problem with 3.14.9 on MacOS 10.10.  I filed the following bug report: Bug 745930.

Hi,
Playing with the inspector found a small detail, that perhaps is relevant. Maybe not, but prefer share it.. ;)

The primary button has the property valign=GTK_ALIGN_BASELINE
The second button has the property valign=GTK_ALIGN_FILL

Setting the primary button with GTK_ALIGN_FILL, stop cutting it.

I do not know the reasons to use GTK_ALIGN_BASELINE, but would make sense that both buttons use the same VALIGN.

Regards

Various baseline handling issues have been fixed in 3.20. I hope this is fixed. If you still see it with 3.20, please reopen