Hi,
On Sep 23, 2010, at 18:11, John Obbele wrote:
>>
>> Why can't you simply initialize the GValue *only* in the error case?
>> We could patch GValue but that means that your library will be
>> dependent on some future version of gtk.
>
> This is what I was doing until now. It works well once you've
> understood the trick and, indeed, there is no real need to patch
> System.Glib.GValue.chs.
>
> Hum ... let's say that, at least, this bunch of mails will help
> gtk2hs newbies who might encounter this same behavior in the
> future :)
>
Well, yes, we could have more functions dealing with GValue, although
I hope there are very few places that GValues are necessary (and they
are only necessary in bindings). I had a lot of fun with crashes where
GValues were not initialized or not cleaned up properly (space leaks).
The withGValue function seemed to be the best thing to do.
>>> I have successfully cast my object to the GObjectClass by copy-
>>> pasting
>>> samples of code I have found. Same for signals, they are working
>>> fine. ... except that I'm using plain vanilla c2hs with
>>> pre-compiled gtk2hs-0.10 packages :(
>>>
>>
>> This is bad. Signals.chs and Types.chs must be automatically
>> generated. I'm not sure how well the standard c2hs could work, but at
>> least dependencies are broken so that a project with several files
>> will not work.
>>
>> You will run into problems that certain pointers to and from C
>> functions are recognizes as the Haskell types they were declared
>> as, I
>> think.
>
> I was afraid so :'(
>
> /me cabal install glib gtk gconf
> /me copy and past part of gconf configuration to xfconf
> /me pull his hair out seeing that gtk2hsC2hs is outdated and can
> neither handle inline "#include<foobar>" instructions, nor
> multiple headers files through the cabal 'x-c2hs-header'
> directive, nor some "do" construct syntaxes (explicit '{',
> ';', '}' are my friends !)
>
You can only pass one header file to gtk2hsC2hs since it will compile
it into a serialized form. We use the trick of defining a local header
file if we need more than one header file or if they don't always
define the right macros.
Note that including a header file into the .chs file has no effect on
the compilation of the final modules. C header file directives are
nowadays ignored by ghc.
> [... 4 hours and one thunderstorm later ... ]
>
> /me launch his quickcheck tests with parallel threads and is
> happy to see that everything run smoothly ... except for
> System.Glib.UTFString.fromUTF which is not as good as the
> utf8-string package to process arbitrary strings generated by
> QuickCheck2.
>
True, fromUTF bails out badly. What kind of behavior does utf8-string
have that we don't? I don't really want to add yet another package to
the dependency list of gtk, but I would be happy to add some sort of
better error handling or recovery.
>>> I have tried to solve my weak-reference problem by artificially
>>> increasing the object reference with objectRef. If I've correctly
>>> read the glib documentation, this should do the trick.
>>>
>>
>> I don't follow. What problem do you want to solve? Do you have weak
>> references anywhere?
>>
>
> I may have confused "weak-reference" with what the xfconf
> documentation calls "singleton object". Here is the official C
> API:
>
> http://www.xfce.org/documentation/4.6/api/xfconf/xfconf-xfconf-channel.html#xfconf-channel-get
>
> One can read that xfconf_channel_get() returns a XfconfChannel*
> object which is owned by the daemon and should *NOT* be
> g_object_unref(), whereas xfconf_channel_new*() return normal
> GObjects.
>
> I have artificially objectRef my objects from channel_get() to
> use them with gtk2hs.
>
> So simple question : is this the "right" solution or should I
> simply dump channel_get() and only use channel_new() with gtk2hs
> ?
>
> (Yes I'm really a memory-leak maniac, that's why I insist on this
> pseudo-problem).
>
Avoiding leaks is important. They are harder to find than crashes :-)
Have you checked the constructGObject function? It might be the
correct way to handle channel_get if this function creates a floating
reference only. The docs of channel_get are very terse, it might help
to look at the source code.
> All these things said, and apart from these last problems, my
> bindings begin to look really good, so many thanks for your
> patience and your help.
Great! I'm glad that people can now produce packages on top of Gtk2Hs
without us being the bottleneck.
Cheers,
Axel
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Gtk2hs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
