Re: Pluggable widget types and implementations

On Fri, 8 Dec 2006, Tristan Van Berkom wrote:

On Fri, 2006-12-08 at 16:27 +0100, Tim Janik wrote:

gtk_stock_appoint_type ("file-chooser",

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.

i hope you understood the part where i said that you can't refer to
types (by name or by reference) before their corresponding _get_type
function has been called. which, for many object types, my be *never*
during a programs runtime.

 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.

there is no point in having an extra naming scheme for widget types.
we have one already: widget type names.
there is also no point in having an extra naming scheme for interface
types (what you call "identifier" above).
we have one already: interface type names.

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,

we will not do that. never ever. i've adressed that in another
email already:
i.e. we guarantee that:
holds, you may assert that in your code. we will not break that guarantee.

let me use your words: we will not substitute types at the GType level.

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.

in that same email, i did also suggest a proper abstraction.
it's just not a string, it's a factory API that you use to create
objects conforming to a certain type, but not necessarily exactly
of that type (g_object_new would be good for that):

  /* craete instance conforming to prerequisite_type */
  g_factory_create (GType prerequisite_type);

  /* appoint an implementaiton_type for a prerequisite_type */
  g_factory_appoint_type (GType prerequisite_type,
                          GType implementation_type);

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 ?

i don't quite understand that paragraph. but i hope the above
helped you with your fears. basically, my suggestion was to *not*
change (break) existing GType/GObject API, but to create objects
with g_factory_create() which creates instances conforming to the
type passed in, but not necessarily of exactly the same type.

Best regards,


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