I think there is some value in letting these functions be available to the outside world.  Part of my project is to streamline the process of widget, property and signal creation, so that a user could extend gtk in pure Haskell.  Imagine a library of pure Haskell widgets containers, and compound items.  It also helps with functional reactive programming, as the GTK signal could be the basis of behavior updates, and we wouldn't want to be limited to the few signals already provided.  (ie- adobe flex has the "Bind" keyword which allows any variable to be an FRP source by automatically creating a signal associated with it).

Perhaps such functions would make sense to an end user if documented in this context....

For now I've just added a copy of Signals.hs to my project, and this will keep things up and running for a while, although this probably isn't a great long term solution.

Thanks!



On Tue, Oct 22, 2013 at 10:53 PM, Axel Simon <Axel.Simon@in.tum.de> wrote:
Hi Jamshid,

On Oct 23, 2013, at 3:46 AM, J H <jamshidnh@gmail.com> wrote:

>
> Hi gang-
>
> I am working on a wrapper library for gtk2hs, and part of the functionality I am offering is the ability to add new signals to gtk.  So far it works great, but I need some functions in Signals.chs.  This module is hidden for some reason, so I basically had to copy paste to get things to work.
>
> Is there a reason this is hidden?  Could that change in the future?
>

The "historic" reasoning why Singals.chs and many other internals are not exported is that we wanted to present the user only with the functions that are necessary to do GUI programming. In particular, we did not want to expose any function that took Ptr types since there would always be a user friendlier way with a newtype and an according memory management infrastructure.

If one wants to build extensions, it is certainly problematic to do so using this setup. One could export the internal functions but not document them. One could also try to separate out the low-level stuff into a separate package and tell users not to use it (this will be tricky I think). The approach that the various packages use with respect to Signals.chs is that they generate the required Signals.chs file themselves using the tools in the Gtk2Hs repository. This might also be a way forward for your package.

Regards,
Axel

> Jamshid
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk_______________________________________________
> Gtk2hs-users mailing list
> Gtk2hs-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gtk2hs-users