Re: Properties on interfaces



On 15 Feb 2003, Matthias Clasen wrote:

> On Fri, 2003-02-14 at 23:41, Owen Taylor wrote:
> > On Fri, 2003-02-14 at 17:07, Matthias Clasen wrote:
> > > n Fri, 2003-02-14 at 22:45, Owen Taylor wrote:
> > >
> > > > > I guess I meant
> > > > >
> > > > > g_object_class_install_property (file_chooser_dialog_class,
> > > > >                                  PROP_FILENAME,
> > > > >                                  g_param_spec_copy (
> > > > >                                     g_param_spec_pool_lookup
> > > (pspec_pool,
> > > > >                                               "filename",
> > > > >
> > > GTK_TYPE_FILE_CHOOSER)));
> > > > >
> > > > > ie use the interface properties just a some kind of templates
> for
> > > > > ordinary properties.
> > > >
> > > > But wouldn't you like a convenience function to do the above?
> > > > That's basically what I was proposing, though since nick/blurb
> > > > strings can have significant size, a shallow copy of some sort
> > > > may make sense.
> > > >
> > >
> > > Ah, thats what you meant with "proxy" here. I agree a convenience
> > > function would be needed. How do you forsee this to help with
> overriding
> > > defaults and min/max in derived classes ?
> >
> > I don't really have an answer for that, but I do think it
> > is a related issue.
> >
> >  - To override defaults/min/max you need to be able to
> >    copy a param spec.
> >
> >  - To override defaults/min/max you'd like to be able to
> >    copy a param spec in a way that doesn't involve duplicating
> >    the nick/blurb strings.
> >
>
>
> One possibility to avoid duplicated docs would be to make
> g_object_class_install_property a little more clever and let
>
> g_object_class_install_property (class, PROP,
>                                  g_param_spec_foo ("prop",
>                                                     NULL,
>                                                     NULL,
>                                                     ...));
>
> perform the equivalent of
>
> g_object_class_install_property (
>     class, PROP,
>     g_param_spec_foo ("prop",
>                        g_param_spec_get_nick(
>                           g_object_class_find_property(class, "prop")
>                                              ),
>                        g_param_spec_get_blurb(
>                           g_object_class_find_property(class, "prop")
>                                               ),
>                                         ...));
>
> ie if nick/blurb are NULL, try to find inherited values. If using NULL
> for this is considered to dangerous, we could use another invalid
> pointer value, e.g.
>
> #define INHERIT 0x1

heh, kudos. i just lined out something similar to this in another email
and now see you've been there two days earlier ;)
you need to be a bit more generic though, as pspecs can contain vital
information in qdata and have user extended flags. that's also why we
can't genuinely clone/copy pspecs (if at all, 2.0 would have had to
introduce clone() right from the start which it didn't).
so besides G_PARAM_TRANSLUCENT (described in the other email) we need
an accessor providing the pspec that contains the canonical blurb,
nick or qdata to fetch:

GParamSpec* g_param_spec_get_original (GParamSpec *pspec);

the blurb accessor might then look like:

const gchar*
g_param_spec_get_blurb (GParamSpec *pspec)
{
  const gchar *blurb = NULL;
  while (!blurb && pspec)
    {
      pspec->_blurb;
      if (pspec->flags & G_PARAM_TRANSLUCENT)
        pspec = g_param_spec_get_original (pspec);
    }
  return blurb;
}

setting the original to be returned by g_param_spec_get_original() is
something that the param-spec pool can handle automatically once it
spots a G_PARAM_TRANSLUCENT property.

>
> Matthias
>

---
ciaoTJ




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