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 start... o_O 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?