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, -Tristan _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list