[Haskell-cafe] HP + Gtk2hs?

[Andrew Coppin]

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?