[Haskell-cafe] HP + Gtk2hs?
andrewcoppin at btinternet.com
Sat Dec 5 15:31:39 EST 2009
Daniel Fischer wrote:
> Am Samstag 05 Dezember 2009 20:14:17 schrieb Andrew Coppin:
>> Bulat Ziganshin wrote:
>>> Developer. many Haskell problems is due to the fact that we have a few
>>> volunteers doing things and lot of consumers begging for features :)
>> That *does* in fact seem to be a recurring problem, yes.
>> Now, how to fix this...?
> How about:
> get the sources, try proposed fix, if it works, send Duncan(*) the patch?
> Even better, become a gtk2hs developer yourself (though that's more work and probably
> requires some serious knowledge of gtk).
In order to do this, I'd have to know how to build Gtk2hs from source on
Windows. I imagine this is quite nontrivial.
>> Interestingly, while you can't compile bindings to external C libraries,
>> GHC does appear to ship with all the header files for Windows, which is
>> odd. It seems if you try to FFI to a standard Win32 function, it
>> magically knows where the hell the header files are, and it Just
>> Works(tm). Hell, I even followed a C++ guide to Win32 programming and
>> managed to translate an "open a blank window" program to Haskell, and it
>> worked. Maybe somebody just needs to sit down and write a nice binding
>> for doing native GUI stuff under Win32?
> Maybe you could try to be that somebody? I'm sure the Windows folks would appreciate it
> very much
The thought has certainly crossed my mind. If I could write such a
package, I imagine a lot of people would find it seriously useful.
Native Windows GUI programs, without any 3rd party DLLs to distribute
with your compiled binary... It'd be great, wouldn't it?
Of course, thinking about how great it would be doesn't get the code
written. ;-) I'd have to learn how to call Win32 from C first, for a
The various I/O libraries sometimes return weird results, and I'm told
this is because GHC is using the emulated POSIX interfaces rather than
native Win32 calls. I did think about turning my attention to fixing
that. However, I notice the next version of GHC seems to have a
radically reworked set of I/O libraries, so maybe it's already fixed?
More information about the Haskell-Cafe