Re: Arbitrary widgets superimposed onto GtkProgressBar

[Peter Clifton <pcjc2 cam ac uk>]

On Fri, 2007-02-23 at 15:56 +0200, Gabriel Schulhof wrote:

> I have no problem drawing on top of a progress bar. The problem is having
> no-window widgets draw on top of the progress bar by themselves. I would
> somehow have to hijack their realize-related activity and inject the
> progress bar's GdkWindow while not making them children of the progress
> bar (because they refuse such an arrangement).

Sorry, I hadn't quite grasped that you wanted to put arbitrary widgets
on top. 

[snip]

> > In general... as a question to the GTK people. How is it possible to
> > subclass GTK widgets where a lot of the implementation detail is hidden
> > away like this. I realise there may be no contract to keep the internal
> > implementation constant, but does this mean the only alternative is to
> > copy-paste and the code for the whole widget to make the changes wanted?
> 
> ... and that doesn't even work, because the themes are often keyed on the
> widgets' class names, so even if you copy the entire painting code, the
> theme engines will not render your widget identically to the genuine GTK
> widget, because the class names do not match. Try building your own combo
> box, and see if it'll be rendered correctly under Clearlooks.

I'll stop posting to the devel list regarding the specific code question
(as probably app-devel would be a better list), but the question is I
have for the GTK developers is this:

Does the apparent difficulty in extending, or replicating standard GTK
widgets represent a design limitation of GTK? Can GTK provide some
internals of widgets for use in subclassing - rather than for public
access, like "protected" may be used in C++?

Thanks,

Peter Clifton