On Thu, Feb 13, 2014 at 1:40 PM, Donald Allen <donaldcal...@gmail.com> wrote: > Graphics.UI.Gtk.Windows.Dialog > > The documentation says "the two primary areas of the window can be > accessed using dialogGetUpper and dialogGetActionArea." There is no > dialogGetUpper. Is it now dialogGetContentArea? > > The documentation says "The top section is a VBox,". If dialogGetUpper > has been replaced by dialogGetContentArea, the latter returns an IO > Widget, not a Vbox and Widget is not in the ContainerClass. So how do > put something in the content area? In the C version of my project, > which of course uses gtk3 directly, I simply do a gtk_container_add to > the content area of the dialog. Works fine. The Haskell compiler won't > allow this, because, as I said above, Widget is not in the > ContainerClass, so I can't do a containerAdd. Can someone enlighten me > as to how one adds, say, a calendar, to the container area of a > dialog?
I took a more careful look at my C code that pops up a calendar in a dialog, as well as looking at the relevant gtk3 routines and saw the light. First of all, gtk_dialog_get_content_area returns a pointer to a GtkWidget. The gtk2hs equivalent does the analogous thing. I made gtk_container_add compile without complaint by using a GTK_CONTAINER cast. gtk2hs offers something analogous -- castToContainer. Using the latter, the Haskell code now compiles and the dialog with embedded calendar now appears. I still think there are documentation issues here that contributed to my confusion. I'm guessing that the gtk3 support is a work-in-progress and that the documentation is in a similar state of transition. If my guess is right, then I'm grateful for the gtk3 support that exists and looking forward to this being a more finished product. But if I'm wrong and the thought is that this is finished, then I would argue that it isn't, certainly not in the documentation department. > > Graphics.UI.Gtk.Misc.Calendar > > In the Signals section, we have > > onDaySelected :: CalendarClass self => self -> IO () -> IO (ConnectId self) > > This is a function, not a signal. It cannot be used with 'on'. I > suspect what is going on here is that a change has been made from > functions like this, with the signal name embedded in the function, to > use of 'on', which takes a signal as an argument. The latter makes > much more sense to me, a better design, in my opinion. But it looks > like the transition is only partly done. If I'm right about this, it > would really be helpful to warn users of this, and refer them to > documentation for how to use the old-style and new-style signal > connection. Perhaps I missed it, but I've found nothing in the > documentation that says anything about this. Or perhaps I've got this > wrong, in which case I'd appreciate an explanation. > > /Don Allen ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
