Re: Pluggable widget types and implementations

On Fri, 2006-12-08 at 16:27 +0100, Tim Janik wrote:
> >
> > i.e.
> > gtk_stock_appoint_type ("file-chooser",
> >                         MYLIB_TYPE_SEXY_FILECHOOSER);
> this is simply not possible without introducing a seperate widget type
> naming system which we aren't planning to do (e.g. because it'd be redundant
> to the type names). it can also not be automated because type names are not
> known before the first use of the corresponding _get_type function.

  I really don't intend to start a shouting match here, I just honestly
think you misunderstood the reason for my proposal, so please let me try
and clarify just once.

  A separate naming scheme is exactly what I propose, not a widget
naming scheme but a "stock type" naming scheme, "GtkFileChooser" is a
GType name, the GType name is only related to the stock name insofar as
it happens to be the default implementation of the symbolic
"file-chooser" identifier.

This abstraction would ensure that there is no confusion at the GType
level, if we start substituting types at the GType level then types
will inevidably be substituted underneath unsuspecting code, that
doesnt sound safe to me at all, ensuring that there is a proper
abstraction will ensure that types will only be substituted for
code that was suspecting that a dynamic implementation would be
chosen for the given task.

Maybe you can understand a little more what my concern is, if
you do insist on aliasing types using actual types as aliases
for other types, would you please elaborate on why my fears and
concerns are unfounded ?

Best regards,

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