Re: input only event boxes

On Thu, 2003-08-28 at 06:33, Alexander Larsson wrote:
> On Tue, 2003-08-26 at 17:57, Owen Taylor wrote:
> > The main API issue that came to mind is that input-only event boxes
> > are different from normal event boxes along two different axes:
> > 
> >  A) They aren't visible
> >  B) They trap events to the child before they get to the child.
> > 
> > While for a non-selectable label or image, B) isn't relevant, it might
> > be relevant in some other uses - say, trying to put a tooltip on
> > a container with multiple buttons in it.
> > 
> > So, I wonder if we should offer separate properties:
> > 
> >  "input-only"
> >  "above-child"
> Here is a new version with these.

Looking good, I have some comments about the docs and see
one apparent bug. Otherwise looks good to commit.


+                                   g_param_spec_boolean
+                                                        _("Visible
+                                                        _(" Whether the
event box is visible, or invisible and only used to trap events."),

 "Whether the event box is visible, as opposed to invisible and only
  used to trap events."

would be clearer. The answer to "Would you like coffee or tea?" is
not "yes" or "no".

+                                                        _("Whether the
event-trapping window of the eventbox is above or below the window of
the child widget."),

Same here.

+ * gtk_event_box_get_visible_window:
+ * @event_box: a #GtkEventBox
+ *
+ * Return whether the event box has a visible window.

gtk doc style is 'returns' 'sets', etc.

+ * There is one unexpected issue for invisible event boxes that
+ * have the window below its children (see
+ * %gtk_event_box_set_above_child). Since the input-only window is

Markup for functions is gtk_event_box_set_above_child() - the
% markup is for enumerations. # is for structures.

+ * not a parent window of the child windows the event box won't
                                            ^ comma here
+ * get events happening inside a child window unless the child
+ * window has the event in its event mask.

Reads a bit unevenly with 'children' 'child windows' 'child window'

 There is one unexpected issue for an invisible event box that has its
 window below the child. (See gtk_event_box_set_above_child().)
 Since the input-only window is not an ancestor window of any windows
 that descendent widgets of the event box create, events on these 
 windows aren't propagated up by the windowing system, but only by GTK+.
 The practical effect of this is if an event isn't in the event
 mask for the descendant window (see gtk_widget_add_events()),  
 it won't be received by the event box. 

 This problem doesn't occur for visible event boxes, because in
 that case, the event box window is actually the ancestor of the
 descendant windows, not just at the same place on the screen.

+ * gtk_event_box_set_above_child:
+ * @event_box: a #GtkEventBox
+ * @above_child: boolean value

Should be something like "%TRUE if the event box window is above
the windows of its child"

+ * Set whether the event box window is positioned above or below the
+ * windows of its child.

Same comment as for the property.

+  if (priv->above_child != above_child)
+    {
+      if (GTK_WIDGET_REALIZED (widget))
+	{
+	  gboolean visible = GTK_WIDGET_VISIBLE (widget);
+	  if (visible)
+	    gtk_widget_hide (widget);
+	  gtk_widget_unrealize (widget);
+	  priv->above_child = above_child;
+	  gtk_widget_realize (widget);
+	  if (visible)
+	    gtk_widget_show (widget);

I think it might be worth an optimization of:

 if (GTK_WIDGET_NO_WINDOW (widget))
    if (above_child)
     gdk_window_raise (priv->event_window);
     gdk_window_lower (priv->event_window);

I can see people wanting to switch this on the fly in some
cases. (Bonobo does something like that.)

+      if (priv->event_window != NULL)
+	gdk_window_move_resize (priv->event_window,
+				allocation->x + GTK_CONTAINER (widget)->border_width,
+				allocation->y + GTK_CONTAINER (widget)->border_width,
+				child_allocation.width,
+				child_allocation.height);

Coordinates look wrong here for the case of visible && above_child.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]