Discussion:
[Gtk2hs-users] Fwd: Why is Signals.chs hidden?
J H
2013-10-23 01:46:39 UTC
Permalink
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?

Jamshid
Axel Simon
2013-10-23 05:53:34 UTC
Permalink
Hi Jamshid,
Post by J H
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
Post by J H
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
https://lists.sourceforge.net/lists/listinfo/gtk2hs-users
J H
2013-10-23 17:35:39 UTC
Permalink
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!
Post by Axel Simon
Hi Jamshid,
Post by J H
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.
Post by J H
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
Post by J H
Jamshid
------------------------------------------------------------------------------
Post by J H
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
Post by J H
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk_______________________________________________
Post by J H
Gtk2hs-users mailing list
https://lists.sourceforge.net/lists/listinfo/gtk2hs-users
Loading...