[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: Pluggable widget types and implementations
From:       Tim Janik <timj () imendio ! com>
Date:       2006-12-08 16:49:01
Message-ID: Pine.LNX.4.62.0612081735270.26260 () master ! birnet ! private
[Download RAW message or body]

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

> 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.

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:
   http://mail.gnome.org/archives/gtk-devel-list/2006-November/msg00133.html
i.e. we guarantee that:
   G_TYPE_FROM_INSTANCE (g_object_new (TYPE_FOO, NULL)) == TYPE_FOO.
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,
>                   -Tristan

---
ciaoTJ
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]