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

The theme on purpose removes frames which are not in a GtkScrolledWindow, favouring whitespace instead. Why/where do you need a different behaviour (as in, is there any application which is rendered poorly because of this)?

Any program where the designer considers a GtkFrame object in the UI is required to make the program most easily usable, by grouping things together visually for the user, is going to present itself poorly.

I really do question whether a theme author should take the view that she knows better than the UI designer for the program that visual grouping in that program is wrong and that the GtkFrame objects the program designer provided are dispensable.

(In reply to comment #3)
> Any program where the designer considers a GtkFrame object in the UI is
> required to make the program most easily usable, by grouping things together
> visually for the user, is going to present itself poorly.

Do you have any concrete example of applications doing this?

> I really do question whether a theme author should take the view that she knows
> better than the UI designer for the program that visual grouping in that
> program is wrong and that the GtkFrame objects the program designer provided
> are dispensable.

The theme doesn't decide about how UI elements are grouped; that's a job of the toolkit's layout manager.
I don't see anything wrong in the theme rendering elements as it wants, as long as things look good (transparent is "just another color"), that's why I am asking for a real world app.

Reply to comment #4

"The theme doesn't decide about how UI elements are grouped; that's a job of the
toolkit's layout manager."

I am afraid that this shows that you are missing the point.  I did not refer to layout grouping, I referred to "visual grouping".  The purpose of a GtkFrame object is to draw a border round a group of widgets to provide a visual clue to the user of the program that each of the elements in the group have some logical connection to each other.

I suggest you look at the GTK+ documentation on GtkFrame.

"Do you have any concrete example of applications doing this?"

Again, I think you are missing the point.  Any program in which the author considers the user would be assisted in using the UI by visual grouping will be disadvantaged if the theme author things he knows better.

My particular program, efax-gtk, does not appear as usable without frames (both the main UI and the configuration dialog), but there are likely to be more compelling cases.  You will most often find frames are of greatest value in configuration dialogs, where it is a natural fit.

I use several OSS gtk2 programs that use frames. One example is easytag.

My proprietary app that I ported from gtk2 to gtk3 also used frames to separate UI areas to make it clear and direct to users what each section needs from them.

What's frustrating is that the gtk2 adwaita theme has visible frames, but the gtk3 ones does not. Please don't go changing the gtk2 theme now that I've mentioned it.

I forgot to add that one major area frames are used are around GtkTreeView widgets to give it an inset, distinct look. The Pidgin account manager window is a good example. In GTK3 it would look all flat and hard to read.

Fair enough, I'm convinced we want to revisit this, but we'll have to wait until these [1] GTK+ fixes land for how GtkFrame handles border-width.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=664342

I pushed a fix for this to git master now.