I don't follow.  A KiwiEntry widget should have a KiwiEntry wrapper and a Entry widget should have an Entry wrapper.  Do you want glade or some other program to suddenly use KiwiEntry widgets instead of Entry widgets?

For instance, if you create a gtk.ComboBoxEntry, entry widget for it is created by GTK+ itself.  I would like that such an entry was wrapped into a sepcified subclass of `gtk.Entry' instead of `gtk.Entry' itself, Kiwi or not.  It should be possible (maybe with not all virtual functions active, though), since it is wrapped somehow into `gtk.Entry'.

Currently, Kiwi, looking through its code, uses a hackish solution by not subclassing `gtk.ComboBoxEntry' and using a custom class derived from `gtk.HBox'.  I think this is wrong in principle, since Kiwi will not benefit from any improvements in the standard combo box implementation at all.

I mention Kiwi just as an example that is publicly available here.  I don't really use it and this proposal should be generic.

I reread your comment once more.  No, by default entries should be wrapped in `gtk.Entry', as now.  It has to require active decision by programmer to register a different wrapper for it.  I just wish there was a possibility to register a different wrapper, I don't propose to change the default.

Do you have a compelling use case?  I worry that it will cause confusion -- extensibility for it's own sake doesn't appeal to me.

BTW, Kiwi may not subclass ComboBoxEntry because they may not want to use it.  I'm not a Kiwi developer so I don't know, but I have a similar ComboBox that avoids problems with the standard one.

FWIW: Kiwi uses a custom ComboBoxEntry just to be able to put a KiwiEntry and not a gtk.Entry. However, the ComboBoxEntry in kiwi is deprecated in favor of ComboEntry, which is a complete combo implementation written in python.

A similar issue to this one was discussed on the gtk-devel mailing list some time ago, people want to be able to replace certain widgets (specifically FileChoserDialog) with a a custom made one.
See bug 356864 for more information.

Is this a dup of that?

I wished to use it if it was available.  My project is Quarry (http://home.gna.org/quarry/), currently completely in C, but I want to reimplemet GUI and some other parts in Python.

Here is a code snippet from deprecated old Kiwi class BaseComboBoxEntry (which does subclass standard class):

        gtk.ComboBox.__init__(self)
        self.entry = KiwiEntry()
        # HACK: We need to set a private variable, this seems to
        #       be the only way of doing so
        self.entry.start_editing(gtk.gdk.Event(gtk.gdk.BUTTON_PRESS))
        self.add(self.entry)
        self.entry.show()

Note how they replace the standard entry with their custom entry and it is only possible with an ugly hack (and the old entry must be still around, taking up memory and stuff.)  I don't know if decision not subclass `gtk.ComboBox' in new class is by design or to avoid such hacks.

I don't think it would cause confusion.  It could either go as undocumented feature, but I'd prefer if it was documented, but was somewhere among the last section and was clearly marked as "you probably don't need this" (and most developers don't) and "use at your own risk".

I mean, I see two valid arguments for not providing this feature: 1) if it is difficult or impossible to implement; 2) if it will cause changes in many places.  About item 2, I doubt, if it is possible, it should be generic and cause changes only in one or two places.  About item 1 you can tell better.

Yes, it looks like essentially the same request.  I just propose to do it in Python.  If it is done in C, you would just need to make sure Python wraps this in a convenient way.

Maybe you could mark it as postponed and add dependancy to the bug you mentioned.  It is not really a duplicate, but if that request is implemented, it will change and simplify the way to implement this one.

pygtk used to have something like this, but it was phased out when real gtype subclasses were implemented.  A real subclass is the wrapper, but it gets a new gtype so that code can detect that it's different than it's base class.  That's what I was getting at when I said that Entry should be distinct from a KiwiEntry.

One possible use is to add a convenience method to a wrapper so for example, I could use a fancy_animated_display() method with a window created by some other code.  I don't find this compelling because fancy_animated_display() can be an ordinary function that takes a window as an argument.

BTW, I think doing this at the C level is also misguided because code gets written for a particular class, with it's bugs, warts, and all.  Replacing it with another class that's different won't always work.

Users that do use this feature (and most will be fine without it) are responsible to use it correctly.  If they seriously change the way built-in objects work, they can hardly expect GTK+ to work correctly with them.  That is why I consider it perfectly OK and even correct to demand subclassing of standard classes.

If GTK+ fails to work with an instance of a proper (not changin standard features) subclass of standard class, it is a bug in GTK+.  I don't think it is proper to forbid additional features just to prevent additional bugs discovered in a library.

One of the main principles of OOP is that code should (ideally) work with any proper implementation of an interface.  It shouldn't rely on any implementation details.  Likewise, GTK+ shouldn't rely on undocumented features of its classes when dealing with arbitrary widgets.  It can only assume that an e.g. entry implements all _documented_ features of GtkEntry.

I guess my real question is what would replacing the wrappers do for you that you can't do with subclasses?  The use case I came up with doesn't meet my definition of compelling.  Part of the reason I'm asking is this approach was phased out in the past.

And, yes it would be nice if documentation were complete and I could do everything I need to do by following the documentation ;).

Well, with subclass you can do anything _except_ change the way objects created by GTK+ behave.  Like the mentioned entry in combo box entry.  I.e. they are good as long as you control object creation yourself.

Yes, in Python you could in principle modify an existing object by assigning certain properties of it.  However, there are drawbacks: 1) it will still have type `gtk.Entry', not 'MyCoolEntry', and type can be tested elsewhere; 2) it is a hack and not clean; 3) I doubt you could do everything this way, e.g. it is probably impossible to define default signal handlers not defined by the standard class; 4) it leads to code duplication: you need not only to define methods and add initializers in constructors, you also need to perform this very same initilizations from your "pseudo-subclass" method and install new methods too.  Phew, maybe there are more :)

And it is difficult to require a use case for a missing feature, no?  Of course nobody uses it now because it is missing...

You're losing me.  All I'm asking is for an example of why you want this -- something like: another library creates a dialog with an gtk.Entry and I need to use a certain method on it when I access it from my code.

We may be talking past each other because a wrapper is only created when python code accesses an object.  If a file dialog is created, none of the internal widgets will have wrappers created (unless you go through and access them from python).  I think you want to add behaviors to widgets (you mention adding signal handlers), but you'd end up changing the behavior of some widgets but not others depending if the wrapper happened to be created or not.  This would be confusing.

I suspect you want the functionality in bug 356864 which needs to be done at the C level.  If that's the case, we should close this bug.  If the functionality is added at the C level, it won't be difficult to add it to pygtk and it may happen automatically.

To be precise, I need to specify a different handler for "changed" signal.  Maybe more, but that's something to start.  And no, I don't use a library, for now I just create combo box entry (and I don't create the entry in it, it is created by GTK+.)

I would be satisfied if this feature was added in PyGTK, but adding it at C level would be more proper, yes.

What you want isn't possible by changing pygtk because some handlers would be changed while others would not because it can be difficult to work out when wrappers are created.  I still don't think it's a particularly good idea, but at least it would work consistently if implemented at the C level.  Closing for now -- open another bug if it's implemented there and not exposed in pygtk.