DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type;
	b=PezfZ9/XImx4YSMZnHtjP/Bf38Y5X364XxNL64FUrruEnaZYrUYvFQ2bOdzZd1uW2+
	g5IBHdOPyYO8vb4fW4xJNF+IRSrFmJB9QN3NHDugOQJo+peHROBdHcGs8ObrrKhiq8i2
	mb74GudY6aQvxMNOQIjAFG/OSrup/2d13zFx8=
MIME-Version: 1.0
In-Reply-To: <AANLkTikLb7Ck4u=A8vgkp_ggbNYmWABS+eLhVog2B=s2 at mail.gmail.com>
References: <AANLkTikLb7Ck4u=A8vgkp_ggbNYmWABS+eLhVog2B=s2 at mail.gmail.com>
Date: Sat, 4 Sep 2010 16:18:19 +0200
Message-ID: <AANLkTimLnwRMbQFNvZZmWoy+UrrUaRw7+x_KfazaW=NC at mail.gmail.com>
Subject: Re: [Lablgtk] React (frp) interface: which code organization?
From: Adrien <camaradetux at gmail.com>
To: lablgtk <lablgtk at yquem.inria.fr>
Content-Type: text/plain; charset=ISO-8859-1
Status: U

Hi,

After trying to expand propcc, I found out that no real modification
was needed since the "missing" field is actually not required. I've
made a patch against HEAD[1], it simply extract most of
GtkSignal.connect into a function named GtkSignal.connect_aux, there
is no change in functionality or anything.

Could this patch be applied to trunk? Thanks. (it also fixes a typo:
s/marhsal/marshal/)

Also, if anyone is interested, I've put up a page for
'lablgtk-react'[2]. I'll announce the project more formally later on.

[1] http://notk.org/~adrien/lablgtk-gtk-signal-connect-aux.patch
[2] http://caravel.forge.ocamlcore.org/lablgtk-react/doc

--

Adrien Nader

On 23/08/2010, Adrien <camaradetux@gmail.com> wrote:
> Hi,
>
> I've started playing with react and lablgtk and got a working prototype
> with one small limitation. And it's the occasion to ask for input.
>
> Currently, I'm 'tracking' properties with a generic function. Whenever a
> property is defined, a glib signal which name starts with 'notify::' is
> emitted.  For instance, when the 'progress' property of a WebKitWebView
> is modified, the signal 'notify::progress' is emitted. Simply attaching
> a callback to this signal allows updating the react side.
>
> A short note: in react parlance, a 'signal' is a value that is always
> defined while an 'event' is discrete. Thus, glib properties map to react
> signals and glib signals map to react events.
>
> The generic function I mentionned is the following:
>
>   let react_track obj prop =
>     let module S = GtkSignal in
>     let prop_r, prop_set = React.S.create (get prop obj) in
>     let sgn_name = "notify::" ^ prop.name in
>     let classe = `webview in (* XXX: not generic *)
>     let callback () = prop_set (get prop obj) in
>     let sgn = {S.name=sgn_name; classe=classe; marshaller=S.marshal_unit}
> in
>     ignore (S.connect ~sgn ~callback obj);
>     prop_r, prop_set
>
> Actually, the 'let classe = `webview in' line isn't generic: I haven't
> found how to get this information. Is there anything against adding this
> to properties? It will probably break a few things but it shouldn't be
> hard to fix.
>
> For instance, the 'progress' property:
>   let progress : ([>`webview], _) property =
>     { name = "progress"; conv = double }
> would become:
>   let progress : ([>`webview], _) property =
>     { name = "progress"; conv = double; classe = `webview }
>
>
> Another possibility is to change propcc: properties and signals are
> already generated by propcc, it'd be relatively easy to expand it to
> generate react-compatible modules and classes.  However, it means adding
> a lot of lines of code to the final code and that's I prefer the first
> solution.
>
>
> A final note: you can find my example my test code, along with the
> 'react_track' function on [1]. It is the browser using the webkit-gtk
> bindings that I mentionned a few days ago on the caml-list.
> Note that a .cmi file is not being copied during the installation of the
> current lablwebkit bindings. You can update to the tarballs I've
> uploaded[2] or use Obj.magic on the two errors (it's guaranteed safe).
>
>
> Does anyone has a preference? Or maybe a reason not to expand the
> record? Thanks.
>
>
> [1] http://notk.org/~adrien/webkit_test.ml.html
> [2] https://forge.ocamlcore.org/frs/?group_id=157
>
> --
>
> Adrien Nader
>

_______________________________________________
Lablgtk mailing list
Lablgtk@yquem.inria.fr
http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk