React (frp) interface: which code organization?

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