To: Francois.Pottier at inria.fr Cc: lablgtk at kaba.or.jp Subject: Re: Misc questions In-Reply-To: <20030922085521.A30725 at pauillac.inria.fr> References: <20030921180318.A7068 at pauillac.inria.fr> <20030922101819Y.garrigue@kurims.kyoto-u.ac.jp> <20030922085521.A30725@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20030922165104L.garrigue at kurims.kyoto-u.ac.jp> Date: Mon, 22 Sep 2003 16:51:04 +0900 From: Jacques Garrigue Lines: 71 Salut Francois, From: Francois Pottier > On Mon, Sep 22, 2003 at 10:18:19AM +0900, Jacques Garrigue wrote: > > > The answer is that row references are (at least in theory) needed for > > this example, but not properly wrapped yet as we did not need them > > yet. > > OK, then consider my message a request for a high-level interface > to them :) Done (in the next snapshot). > > If you need some functionality in the Gtk modules, you may access it > > by using some casts (but no magic, please) > > GtkTree.RowReference.create (model#as_model :> Gtk.tree_model Gtk.obj) > > I must say I have no idea why this cast makes any sense. As far as I > can tell, the type of [model#as_model] is Gtk.tree_model, which is > declared as a synonym for [`treemodel] Gtk.obj. (By the way, are > [Gtk.obj] and [Gobject.obj] the same type? This is confusing.) > Why is it legal to cast it up to Gtk.tree_model Gtk.obj? The answer > is beyond me. This is a point that I would very much like to understand. OK. Gobject.obj is contravariant. Since for variants [`treemodel] is a subtype of [`treemodel|`liststore], then a (liststore obj) is a subtype of a (treemodel obj). In short the variant tag may be seen as capabilities: the more you've got the better. This is more or less equivalent to using an object < treemodel : treemodel_ops; liststore : liststore_ops > with the *_ops abstract type. The variant allow just for a more compact notation, using a single abstract type for all objects. Actually, there was a small bug in the type of RowReference.create: it was unnecessarily restrictive. If you change it to external create : [> `treemodel ] Gtk.obj -> Gtk.tree_path -> Gtk.row_reference = "ml_gtk_tree_row_reference_new" then you don't need the coercion anymore. The duplicate Gobject.obj / Gtk.obj is historical: in gtk-1.2 objects were defined at the Gtk level, but they are now included in glib. > > Same thing for Window.maximize, you can use it directly (it is > > available as GtkWindow.Window.maximize), but we will add it to the > > window class in the next release. > > It doesn't seem to be available in GtkWindow.Window, at least not in the > 20030828 snapshot. You have to use ocamlbrowser to see all the contents directly. The first line of GtkWindow.Window is include Window which includes all definitions from GtkBaseProps.Window > > The situation is that there are so many functions in GTK that we have > > not yet assessed which are useful and which are not. > > Are all of them currently available at the low level? (I mean, can I, > in principle, access every GTK feature without modifying LablGTK?) This is not 100%, but hopefully more than 95% for the Gtk part. Eventually everything useful should be available. (And probably useless stuff too, as it is hard to distinguish) Note that the support for lower level libraries (glib, pango, gdk) is more partial. Cheers, Jacques