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
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.
On Tue, Oct 22, 2013 at 10:53 PM, Axel Simon <Axel.Simon@...> wrote:
> Hi Jamshid,
> On Oct 23, 2013, at 3:46 AM, J H <jamshidnh@...> 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
> 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.
> > 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
> > the latest Intel processors and coprocessors. See abstracts and register
> > Gtk2hs-users mailing list
> > Gtk2hs-users@...
> > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users