Re: Setting/style-property enhancements

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On 1 Apr 2001, Owen Taylor wrote:
> 
> > 
> > Here are some additions that I'd find useful for using the style
> > properties mechanism for themes.
> > 
> > The intent here is to avoid having the 6 properties currently
> > for the option-menu-tab - left/right/top/bottom/width/height
> > by combining them into 2 properties - the border and the
> > size.
> 
> am i missing something? i don't know what properties you refer to,
> maybe you could outline what these are for?

You can see them in GTK+-2.0:

====
  props->indicator_width = gtk_style_get_prop_experimental (widget->style,
							    "GtkOptionMenu::indicator_width",
							    default_props.indicator_width);

  props->indicator_height = gtk_style_get_prop_experimental (widget->style,
							     "GtkOptionMenu::indicator_height",
							     default_props.indicator_height);

  props->indicator_top_spacing = gtk_style_get_prop_experimental (widget->style,
								  "GtkOptionMenu::indicator_top_spacing",
								  default_props.indicator_top_spacing);
  props->indicator_bottom_spacing = gtk_style_get_prop_experimental (widget->style,
								     "GtkOptionMenu::indicator_bottom_spacing",
								     default_props.indicator_bottom_spacing);
  props->indicator_left_spacing = gtk_style_get_prop_experimental (widget->style,
							       "GtkOptionMenu::indicator_left_spacing",
							       default_props.indicator_left_spacing);
  props->indicator_right_spacing = gtk_style_get_prop_experimental (widget->style,
								    "GtkOptionMenu::indicator_right_spacing",
								    default_props.indicator_right_spacing);
}
===

My GTK+-2.0 patch to do this is at home, so you don't get the docs,
ranges, defaults ;-)

> ok, i see you have:
> 
> +struct _GtkBorder
> +{
> +  gint left;
> +  gint right;
> +  gint top;
> +  gint bottom;
> +};
> 
> unless you want to deal with negative borders as well (not in the
> style property parser, but if people start using that as widget
> properties), this should probably have an own param_spec type
> that does validation.

I don't think we need to be that paranoid at this point, and
and when fooling around with theme geometry parameters I actually
found it useful on occasion to use negative borders, though
I usually found that was a bad idea in the end ;-)

> > 	* gtk/gtkwidget.c (gtk_widget_class_install_style_property):
> > 	Support automatic parser selection like
> > 	gtk_settings_install_property_parser().
> 
> erk, sure, forgot that. though, i'd prefer _gtk_rc_property_parser_from_type()
> rather than _gtk_rc_property_select_parser(), don't you think?

I don't particular care - just a private function. Sure, from_type()
or maybe for_type() is fine.
 
> > 	* gtk/gtksettings.c (_gtk_rc_property_select_parser): Export
> > 	functionality for use by gtk_widget_class_install_style_property.
> > 	Support GTK_TYPE_BORDER, GTK_TYPE_REQUISITION.
> > 
> > One thing I noticed here was that I wanted to make
> > gtk_rc_parser_border() support '3' as equivalent to { 3, 3, 3, 3 },
> > but couldn't.
> 
> why?

Well, I could have set up value transformation form int to GTK_TYPE_BORDER,
but that didn't seem like quite what I wanted - I wanted to do this
as a RC file format thing, not as a general equivalence....
 
> > And it doesn't look like gtk_rc_parse_color() supports the "#fffff"
> > formats for similar reason.
> 
> well, the color parser is currently untested because i didn't know of
> a color property to add and then test things for.
> 
> but, i think i know now what went wrong.
> GtkSettingsValue -> GValue conversions are first attempted via gvalue
> transforms, and only if that couldn't be done, parsers are invoked
> with the code assuming a GString, that's a bit hosed and needs to be
> fixed.

If you are OK with the border boxed type, I'll convert my theme patch
to use that and commit.

> can you add a color or border property to some widget, so i can test
> and fix parser invocation?
> (you could get this to work with the current code even by adding
> string->gdkcolor and int->gtkborder transforms, but that'd be
> an ugly hack and shouldn't be done because those transforms aren't
> usefull beyond rc parsing)

Exactly.
 
> > Perhaps the parser functions should take GtkSettingsValue
> > instead of GValue?
> 
> that doesn't make a whole lot of sense, a GtkSettingsValue is there
> in the first place, what we want is to convert that into a GValue
> that can be queried through the gtk_widget_style_property* functions,
> not another GtkSettingsValue.
>
> lemme just fix the parser code, so parsers always get precedence
> over value transforms.

You are going to change the GtkSettingsValue back into a string
before passing it to the parser?... sounds a little convoluted,
but I guess it works...
 
> btw, i don't quite understand why you use goto's in your code:
> 
> +gboolean
> +gtk_rc_property_parse_requisition  (const GParamSpec *pspec,
> +                                   const GString    *gstring,
> +                                   GValue           *property_value)
> +{
> +  GtkRequisition requisition;
> +  GScanner *scanner;
> +  gboolean success = FALSE;
> +
> +  g_return_val_if_fail (G_IS_PARAM_SPEC (pspec), FALSE);
> +  g_return_val_if_fail (G_VALUE_HOLDS_BOXED (property_value), FALSE);
> +
> +  scanner = gtk_rc_scanner_new ();
> +  g_scanner_input_text (scanner, gstring->str, gstring->len);
> +
> +  if (!get_braced_int (scanner, TRUE, FALSE, &requisition.width))
> +    goto out;
> +  if (!get_braced_int (scanner, FALSE, TRUE, &requisition.height))
> +    goto out;
> +
> +  g_value_set_boxed (property_value, &requisition);
> +  success = TRUE;
> +
> + out:
> +  g_scanner_destroy (scanner);
> +
> +  return success;
> +}
> 
> i think:
> 
> gboolean
> gtk_rc_property_parse_requisition  (const GParamSpec *pspec,
>                                     const GString    *gstring,
>                                     GValue           *property_value)
> {
>   GtkRequisition requisition;
>   GScanner *scanner;
>   gboolean success = FALSE;
> 
>   g_return_val_if_fail (G_IS_PARAM_SPEC (pspec), FALSE);
>   g_return_val_if_fail (G_VALUE_HOLDS_BOXED (property_value), FALSE);
> 
>   scanner = gtk_rc_scanner_new ();
>   g_scanner_input_text (scanner, gstring->str, gstring->len);
> 
>   if (get_braced_int (scanner, TRUE, FALSE, &requisition.width) &&
>       get_braced_int (scanner, FALSE, TRUE, &requisition.height))
>     {
>       g_value_set_boxed (property_value, &requisition);
>       success = TRUE;
>     }
>   g_scanner_destroy (scanner);
> 
>   return success;
> }
> 
> doesn't read so bad, does it?

Sure, that's fine here. I wrote it first without the get_braced_int()
helper, and when it was done that way, it was far cleaner with
the gotos then without.

Regards,
                                        Owen