Created attachment 120086 [details]
gtkmessagearea.h

Created attachment 120087 [details]
gtkmessagearea.c

Open questions:

- Is there a better name than GtkMessageArea ? 
  GtkMessagePanel ? GtkMessageBar ?

- The current widget is more or less on the GtkDialog level of generality with
  a content area. Would a less flexible, GtkMessageDialog-like approach with
  icon+text+secondary text be better ?

- Should we consider a future possibility of displaying the message area as
  an "overlay" on top of the content, instead of requiring manual packing 
  in a vbox and manual visibility management ?

- Maybe don't inherit from GtkHBox ?

- Can this be made visually more appealing / shinier ?

In eog we had to do this change[1] in order to fix bug #504538. I skimmed briefly your implementation and don't think that the size allocation is handled, so it may be useful.

[1] http://svn.gnome.org/viewvc/eog/trunk/src/eog-message-area.c?r1=4576&r2=4723

(In reply to comment #3)
> Open questions:
> 
> - Is there a better name than GtkMessageArea ? 
>   GtkMessagePanel ? GtkMessageBar ?

Before learning the name, I personally used to call this an info bar. To me "area" refers to a part of something, ie. the content area of a dialog. The term "panel" feels also better, however I would think a panel is usually a very large kind of bar, ie. making up a quarter or third of the window.

> - The current widget is more or less on the GtkDialog level of generality with
>   a content area. Would a less flexible, GtkMessageDialog-like approach with
>   icon+text+secondary text be better ?

There's a bug, I fail to find it right now, about making access to GtkMessageDialog's area more flexible because the strictly simplified interface isn't always sufficient. I think the MessageDialog extras would be very nice here as well.
Maybe even as an interface shared with the dialog?

> - Should we consider a future possibility of displaying the message area as
>   an "overlay" on top of the content, instead of requiring manual packing 
>   in a vbox and manual visibility management ?
> 
> - Maybe don't inherit from GtkHBox ?

I would wonder, what about a vertical version? Most widgets can be vertical and this message widget could very well also do it.

Note that a cut-down interface similar to message-dialog would not be enough for gedit, for instance when opening a file with the wrong encoding we also allow to select the correct encoding from a combo.

Created attachment 121971 [details] [review]
patch

Here is a patch that also includes the necessary glue, and adds an example to gtk-demo and a testcase to gtk/tests/builder.c.

In the widget code itself, it fixes up some details, e.g allows theming independent from tooltip theming while still using tooltip colors by default.

It also make the widget a GtkBuildable.

The one thing left to do: find a better name

Some comments:

 - these days it should inherit from GtkBox with "orientable" set to horizontal instead of HBox, or is that just gtk3?

 - if we inherit from (H)Box, a name I like is GtkMessageBox (similar to how you have GtkMessageDialog inherit from GtkDialog).

 - the GeditMessageArea has an open bug about style properties http://bugzilla.gnome.org/show_bug.cgi?id=472647

 - "gtk_message_area_add_stock_button_with_text", while I obviously like that utility function (since we use it in gedit), I think we either should remove it or also add it to gtkdialog, since the API are pretty much designed to be the same.

(In reply to comment #8)
> Some comments:
> [...]
>  - if we inherit from (H)Box, a name I like is GtkMessageBox (similar to how
> you have GtkMessageDialog inherit from GtkDialog).

Incidentally MessageBox immediately makes me think of a classic Win32 API function going by that name, see http://msdn.microsoft.com/en-us/library/ms645505(VS.85).aspx . I wonder if that's relevant in terms of possible confusion to new developers.
I do still find MessageArea wrong, though.

> - these days it should inherit from GtkBox with "orientable" set to horizontal
> instead of HBox, or is that just gtk3?

I was trying to do that, but found that GtkBox is still abstract in current trunk.
Not sure whats up with that. Need to ask tim/mitch

> - the GeditMessageArea has an open bug about style properties
> http://bugzilla.gnome.org/show_bug.cgi?id=472647

We have all those style properties, and then some...

>  - "gtk_message_area_add_stock_button_with_text", while I obviously like that
> utility function (since we use it in gedit), I think we either should remove it
> or also add it to gtkdialog, since the API are pretty much designed to be the
> same.

Yeah, that makes sense. Lets remove it...


Wrt to the naming question, I'm leaning toward GtkInfoBar, for 2 reasons:
a) it avoids the the false parallel with GtkMessageDialog and b) we've plenty of prior art for Bars in GTK+. Discuss.

GtkMessageBar? The "Area" doesn't sound much like the yellow bar, it makes me think that it is something related to GtkMessageDialog, just like an action area is related to a GtkDialog.

Created attachment 132022 [details] [review]
new version

Slightly updated version. Changes include:

- remove gtk_message_area_add_stock_button_with_text

- add a message-type property

- use symbolic colors to pick bg/fg depending on message-type

+ * Adds the @contents widget to the contents area of #GtkMessageArea.
+ */
+void
+gtk_message_area_set_contents (GtkMessageArea *message_area,
+                               GtkWidget      *contents)
+{
+  g_return_if_fail (GTK_IS_MESSAGE_AREA (message_area));
+  g_return_if_fail (GTK_IS_WIDGET (contents));
+
+  gtk_box_pack_start (GTK_BOX (message_area->priv->content_area),
+                      contents, TRUE, TRUE, 0);
+}

I think _set_contents is misnamed. It does not *set*, it *adds* a widget.

Makes me wonder about _get_content_area just like GtkMessageDialog has.

Created attachment 132058 [details] [review]
new patch

- Added a11y
- Fixed up docs
- Renamed to GtkInfoBar
- replaced set_contents with get_content_area/gtk_action_area

It occurs to me that the fg symbolic colors are somewhat pointless, since labels inside the message area use their own fg color anyway.

I am not sure if the tooltip code actually gives much of an advantage. It feels pretty useless for themes that natively support the message area widget, and others may even break with regard to the text color.

One thing that one could consider is to provide two default colors for the background. This way it is possible to pick a good default for both themes with a dark and light text color.

The fg symbolic colors may still be usefull for themes to draw a colored border around the message area though.


One thing I just noticed. Themes based on the pixmap engines will not be able to theme the drawing of the message area, and follow the symbolic colors. But I guess that is just what one gets for using pixmaps ...

(In reply to comment #16)
> I am not sure if the tooltip code actually gives much of an advantage. It feels
> pretty useless for themes that natively support the message area widget, and
> others may even break with regard to the text color.

Of course it is not useful for themes that support GtkInfoBar natively. The very point of that code is to make the info bar work somewhat better _without_ native support. 

I don't think there is a bit danger of this breaking wrt to text color, since tooltips are actually in the exact same situation as GtkInfoBar: the labels are drawn with there own text color on top of the tooltip bg color. 
 
> One thing that one could consider is to provide two default colors for the
> background. This way it is possible to pick a good default for both themes with
> a dark and light text color.

Who would be responsible for making the choice ? And how ?

 
> The fg symbolic colors may still be usefull for themes to draw a colored border around the message area though.

> 
> One thing I just noticed. Themes based on the pixmap engines will not be able
> to theme the drawing of the message area, and follow the symbolic colors. But I
> guess that is just what one gets for using pixmaps ...

Why not ? We pass an "infobar" detail to draw_flat_box, so engines can certainly draw whatever they want, using the provided colors or otherwise. Admittedly, you will have to look at the message-type property to make your rendering depend on that. Would you prefer to have that folded into the detail string, a la infobar-info, infobar-warning, etc ?

(In reply to comment #17)
> (In reply to comment #16)
> > I am not sure if the tooltip code actually gives much of an advantage. It feels
> > pretty useless for themes that natively support the message area widget, and
> > others may even break with regard to the text color.
> 
> Of course it is not useful for themes that support GtkInfoBar natively. The
> very point of that code is to make the info bar work somewhat better _without_
> native support. 
> 
> I don't think there is a bit danger of this breaking wrt to text color, since
> tooltips are actually in the exact same situation as GtkInfoBar: the labels are
> drawn with there own text color on top of the tooltip bg color. 

The danger is there, but low. If a theme changes the text color of widgets inside a tooltip, that same change will not be applied to the widgets inside the info bar. However, I guess that only a very small amount of themes will be affected so one could just ignore the issues, and those themes need to be adapted.

> > One thing that one could consider is to provide two default colors for the
> > background. This way it is possible to pick a good default for both themes with
> > a dark and light text color.
> 
> Who would be responsible for making the choice ? And how ?

GTK+ would need to do that based on the foreground color of the GtkInfoBar widget. 

> > One thing I just noticed. Themes based on the pixmap engines will not be able
> > to theme the drawing of the message area, and follow the symbolic colors. But I
> > guess that is just what one gets for using pixmaps ...
> 
> Why not ? We pass an "infobar" detail to draw_flat_box, so engines can
> certainly draw whatever they want, using the provided colors or otherwise.
> Admittedly, you will have to look at the message-type property to make your
> rendering depend on that. Would you prefer to have that folded into the detail
> string, a la infobar-info, infobar-warning, etc ?

All theme engines except for the pixmap based ones can just use the foreground/background colors and are done. Only the pixmap engine has an issue, because it does not use these colors.
Folding the information into the detail string sounds like a pretty good idea.

Ok, I have changed it to use different detail strings per message type, and committed it.

Is it me, or gtk_info_bar_set_contents is missing? The docs point to that func but that func it isn't in the code. Is it?