2011/1/5 Matthew Flatt <[email protected]>: > The `window<%>' method `get-handle' returns the native widget for a > window. The docs for `get-handle' are out of date, and I pull push a > correction later today: the result for `get-handle' is now an FFI > pointer instead of an integer, and it represents GtkWidget under X. > [...]
Hello Matthew, yes, I figured out that much, but it doesn't help a lot ... > So, you could create a `panel%' to hold the native Gtk widget. Then, > use `get-handle' on the `panel%' instance to get the parent widget for > the new native widget. > [...] ... because this simple approach doesn't work: If I use gtk_container_add to attach a child to the GtkContainer backing a panel% or frame%, that child widget stays invisible. One reason certainly is that its size is set to 1x1 pixels. So apparently some integration with the layout management system is necessary. However, even if I override all size related methods of the subwindow<%> interface on a panel% and forward them to GTK+ equivalents on the native widget, the native child widget is still not resized to useful dimensions by the Racket GUI system. And even if I manually resize, show and redraw the widget using calls of wrapped GTK+ functions at the REPL, it still doesn't show up in the GUI. Another related strange observation in contradiction to the documentation is that the method add-child of area-container<%> does not work if passed an implementation of the subwindow<%> interface that just extends object%, but insists on getting an instance of some internal mred% class. I'm getting more puzzled the more I look under the hood of the Racket GUI library :-/ Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
