Re: [Gtk2hs-users] GConf bindings

[Axel S. <A....@ke...>]

On Mon, Apr 19, 2004 at 02:11:09PM +0100, Duncan Coutts wrote:
> > > It is not quite clear if errors can occur asynchronously or if they
> > > would always be raised in response to a GConfClient API call though I
> > > think it is the latter.
> > Gtk is single-threaded, so error signals could either be delayed to after the GConf 
> > API call returned or the signal could be called while still in the call (hence the 
> > function that changes or looksup and entry must be "safe"). No real concurrency 
> > should be possible.
> 
> Sorry, I didn't mean concurrency, I meant could a error signal be
> emitted other than in response to a GConf API call, or if error signals
> could be emitted in response to some external event. If it is the latter
> then we have to bind the error signal anyway, otherwise it might be
> better to take the approach of raising Haskell errors in response to
> GErrors.
So your question was: Are there errors which trigger the error signal but that 
cannot be observed by passing a non-NULL GConfError? I think no. I think it's safe 
to assume it's a no. At least for now.

> > A very simplistic implementation would be to have a normal algebraic data type:
> > 
> > data GConfValue
> >   = GcvInt Int
> >   | ..
> >   | GcvList [GConfValue]
> >   | GcvPair (GConfValue, GConfValue)
> > 
> > which matches the possibilities in C (although the docu says, that pairs and list 
> > can't have mixed types).
> 
> Yes, I want to have that too (I called it GConfValueDyn but perhaps I
> should just call it GConfValue and the underling C struct GConfValueRaw
> or something).
> 
> I think it is nice to cater for the common case that the type is
> statically known by using a class. We don't need separate methods for
> the dynamic & static versions since GConfValueDyn/GConfValue is an
> instance of GConfValueClass.

If it works in practice (in your application), then I think it's good to have since 
it makes programs shorter.

> problem. You shouldn't ever be required to add type annotations like
> 
> timeout :: Int <- gConfClientGet engine "HaskellApp/timeout"

Maybe not always with Int (in case you compare timeout with a constant, it is still 
not clear to the compiler what type timeout is). But I guess I can live with an 
occasional type annotation.

> > Dealing with the error is probably easier than connecting a signal which reads some 
> > global MVars.
> 
> I'm not quite sure what you mean there. For the case that the actual
> type of the GConfValue is not the one we expected we will throw an
> exception.

I was thinking more about the global error callback 
(gconf_client_set_global_default_error_handler) 
and that it is rather useless, unless you pop up a dialog.

> >  Why don't create two functions, one for a value in 
> > GConfValueClass and another one for the sum type?
> 
> With GConfValue a member of GConfValueClass it all works with one
> function. Does this seem like a good idea (or do I have an unhealthy
> obsession with class overloading :-) )?

If I normally don't have to cast, it's ok. Novices don't want to bother with GConf 
anyway :-).

Axel.