Re: Property Comments

To make it short, you know my opinion! *g*
If you want to take the second route, with labeled properties, you have 
to create compiletime labeled properties, no prob with c++ :)
But imo that is too much power for the user to shot himself in the foot! 
I didnt really want to make the foreground color etc customisable on a 
per widget basis, you very seldom need to do that, the same goes for 
font name/type, you really only need to change the size.
I mean if you allow to much changes on a by widget base, the 
applications look incosistent. We might talk about changeable color in 
the theme though!  I agree with you that we should move the font_size 
property up the hierachie to widget. So the really interesting question 
is, what properties should be set on a per widget base, and which should 
be set globally in the theme. Imo font size is one of the rarer 
occassion where you need to change it on each widget, another 
possibility would be to define styles like in high level text processing 
(latex style) so you have a headline label, or something like this, 
might be a viable alternative too!.
Lets discuss it (without resorting to stupid ideas about labels *g* )

Darren V Hart wrote:
> Regarding Properties:
> 
> What did you have in mind marc?  I properties interface like GTK doesn't
> sound like your style.  It does make sense to store a font_properties
> object (using the class we already have) and a color_properties object
> (again, existing object) to force the theme to use those rather than the
> defaults.  But do we want to write all the property methods in every
> widget?  Or would something like this be reasonable:
> 
> void widget::foreground_color(color_properties::ptr color_props);
> void widget::background_color(color_properties::ptr color_props);
> void widget::font(font_properties::ptr font_props);
> color_properties::ptr widget::foreground_color();
> color_properties::ptr widget::background_color();
> font_properties::ptr widget::font();
> 
> 
> There would be a few more, perhaps adding ones for the widget states
> focused and hover.  Or, we could make it a bit more generic and do it
> like this:
> 
> void widget::color_property(const std::string& label,
> 	color_properties::ptr color_props);
> void widget::font_property(const std::string& label,
> 	color_properties::ptr color_props);
> color_properties::ptr widget::color_property(const std::string& label);
> font_properties::ptr widget::font_property(const std::string& label);
> 
> 
> which of course would be used like this:
> 
> widget::ptr my_widget;
> 
> // assign my_widget to something in the tree...
> 
> my_widget.font("foreground", my_font_props);
> my_widget.color("hover_selected", my_font_props);
> 
> This latter methods puts much less strain on the API, but does allow for
> unexpected behavior (unless of course we document it well and make it
> blatantly obvious that a null smart pointer is returned if a property is
> requested that has not been assigned).  Each widget would then simply
> have to define what property labels are valid for that widget.
> 
> I am a fan of the second approach with the labels, opinions?  Come on
> Marc, I know you have one!!!  *gggg*
> 
> Darren