Re: React (frp) interface: which code organization?

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 <[email protected]> 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
>