Delivered-To: garrigue at math.nagoya-u.ac.jp Authentication-Results: mailhost.math.nagoya-u.ac.jp sender=lablgtk-bounces at yquem.inria.fr; domainkey=neutral (no query protocol specified; no policy for yquem.inria.fr) Delivered-To: lablgtk at yquem.inria.fr DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=VR/oITxBm8QVxfMw4sHsVz7vCete56Ki2XXy/RuVZwk=; b=ay6/fZo+K+G1vHKP47zY3LwzyKCPSUrah8uXpQI4PPaSGJkVssAdg5PD/9H9RMgZA4 Fl1Cym4AM+zRxQVo8CkXLvqNzM8HhuElsy+g5FUBshlIBEXo2VCRh6bkNEKmGzeKKit0 /1qdPXyybz6eMXxNtHnRPUley9ewfWMpt5VOU= 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: References: Date: Sat, 4 Sep 2010 16:18:19 +0200 Message-ID: Subject: Re: [Lablgtk] React (frp) interface: which code organization? From: Adrien To: lablgtk 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 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