On Fri, Feb 14, 2014 at 1:52 AM, Axel Simon <axel.si...@in.tum.de> wrote: > 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.
I've already forked my own repository, to submit a pull request for deletion of more incorrect assertions, so I'm already set up to make corrections to the documentation. I will do so as time permits. > > 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. The problem is referring to the "onSignal things", as you put it, as Signals. Using that terminalology implies that they can be used with 'on', which is exactly what I tried to do. It took me awhile (including a look at the sources) to figure out what was going on. > > 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. In C, you must use a cast to add something to the content area if you want your code to compile without warnings (something I always require of myself), since gtk_dialog_get_content_area returns a pointer to widget, not a container (as you would expect). I think this is a mistake in gtk. Because of this, gtk2hs was forced to do the same thing and the casting function you provide works, once you figure out what to do. Again, the documentation is an issue. If someone is going to use a dialog, she is going to have to put something in the content area, yes? Kind of a fundamental operation that ought to be prominently addressed in the documentation, especially since it's far from obvious how to do it, and right now there's nothing. I will fix this, to hopefully avoid having someone else waste the time I did yesterday wrestling with this. /Don > > 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 > ------------------------------------------------------------------------------ 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
