Hi Donald, On Feb 14, 2014, at 4:27 AM, Donald Allen <donaldcal...@gmail.com> wrote:
> The > > http://hackage.haskell.org/package/gtk3-0.12.5.2/docs/Graphics-UI-Gtk-Windows-Dialog.html > > is really in tough shape. Among other things: > > 1. The references to dialogNewWithButtons and dialogGetUpper are > bogus; they don't exist. > 2. The advice "A 'modal' dialog (that is, one which freezes the rest > of the application from user input), can be created by calling > windowSetModal on the dialog." is wrong. You have to set the > windowModal attribute of the dialog to True. > I think none of the developers would argue against any user saying that the documentation can be improved. I don't even know where dialogGetUpper has gone and if this is due to the Gtk3 transition. If you're happy to use git to checkout the sources, then it would be of great help if you correct the details and send in a patch. The "on signal" vs "onSignal" things is indeed a leftover from when we only had "onSignal". It might be documented where the "on" function is defined. We could add some documentation in a central place, except there is none for signals as Signals.chs is not exported and thus not visible in the documentation. About returning Widget instead of Container: If the C code guarantees that the widget is always a container then we can just bind the function that way and safe the user the hassle. That is probably the case here. The C code often uses the wrong types since the compiler doesn't really care what pointer it is. Cheers, Axel > On Thu, Feb 13, 2014 at 9:52 PM, Donald Allen <donaldcal...@gmail.com> wrote: >> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ 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
