Re: Arbitrary widgets superimposed onto GtkProgressBar

["Gabriel Schulhof" <nix go-nix ca>]

On Fri, February 23, 2007 15:38, Peter Clifton wrote:
> But, is it possible for you to create a subclass of the GtkProgressBar,
> catch provide implementations of the appropriate methods / paint /
> expose events, and draw ontop of the GtkProgressBar's window?

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

> Perhaps the window is hidden in the implementation of GtkProgressBar, so
> you can't do that, but conceptually, I think you're trying to extend the
> progress bar.

No, the window is widget->window, but it doesn't help.

> 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 have (fruitlessly) tried something like this before:

In MyCustomComboBox::class_init:
  const char *rc_string = ""
  "style \"my_combo\""
  "{"
  "  GtkComboBox::appears-as-list = 1"
  "}"
  "widget_class \"*.MyComboBox\" style \"my_combo\"";

  gtk_rc_parse_string (rc_string);

Maybe I should try it again - perhaps, this time, GTK will heed my
rc_string ...