To: lablgtk at kaba.or.jp
Cc: garrigue at kurims.kyoto-u.ac.jp
Subject: Re: file_selection_complete patch.
In-Reply-To: <20001220091319.B2330 at lambda.u-strasbg.fr>
References: <20001218132340.A29055 at lambda.u-strasbg.fr>
	<20001220125012A.garrigue@kurims.kyoto-u.ac.jp>
	<20001220091319.B2330@lambda.u-strasbg.fr>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20001221123306D.garrigue at kurims.kyoto-u.ac.jp>
Date: Thu, 21 Dec 2000 12:33:06 +0900
From: Jacques Garrigue <garrigue at kurims.kyoto-u.ac.jp>
Lines: 79

From: Sven LUTHER <luther at dpt-info.u-strasbg.fr>

> > I often realize that this is not so much a pain to have to write the stub
> > by hand (anyway you need to read the docs to do something nice), but
> > that checking that you forgot nothing is really hard. Particularly
> > when the library itself is also evoluting...
> 

> I understand that, we had the same problem with mlgtk.  Automatic or
> semi-automatic translation (or at least stub skeleton writing) is
> the way to go for this. Also gtk+ 2.0 seems to be coming, altough i
> don't know the release date previsions for it.

I don't see immediately how automatic translation can help here.
My point was that being exhaustive is very difficult, but hard to
automatize. There are several reasons to that.
* since part of the work is done by hand, you can always forget some
  function appearing in the C API. Note that automating the stub
  generation is not enough to solve it, since you can still forget to
  add the method to the class layer.
* in fact there are some choices to be done about which functions and
  field to interface to. There are some C functions that are not
  needed at the ML level, and you need to access directly some fields
  in widgets when no method is available. Only experience can tell
  you what is needed and what is not.
* providing access to everything does not seem to be a solution
  either, since some C API may be badly unsafe, or require to much
  work to wrap.

This doesn't mean that I think that automatic stub generation is
useless. Indeed, this might simplify work, and avoid some bugs due to
inconsistencies between C and ML declarations. But this would not
solve the worst problem, which is that you still have to study the
interface in detail, and follow additions.

For an interesting example of semi-automatic stub generation you can
see
  Manuel Chakravarty, "C -> Haskell or Yet Another Interfacing Tool",
  IFL'99, LNCS 1868
This is the way the Haskell binding for GTK+ was done.
However, while I think this much more safe, it still requires a lot of
manual work. Also, it uses the Haskell FFI, which allows direct access
to C data structures. This is impossible in Caml, and Xavier Leroy
does not seem very keen on adding such a feature.

> i wrote there right now, what do you think ? (maybe you could do the change,
> directly, i think it is almost as much/less work as applying the patch).

I actually did it once, and removed it after realizing that complete
was not set_filter...

> > But here, complete is not simply a filter, but is rather intended to be
> > called for completing a partial input, like when you press tab.
> 
> Erm, ...
> 
> i don't understand you here, when i pass "*.ml" to complete, then
> only the .ml files of the given directory are shown ? Is this not
> how a filter does behave ?

First it does not show only the .ml files, but actually *.ml*.
Also, it filters directories, which is not what you would
expect from set_filter. And calling set_filename cancels the filter,
so that you cannot use ?filter and ?filename simultaneously.
My conclusion is that it is really not intended to set a filter, but
as its name shows to complete user input. Nice, but different.

> > So bad there is no real concept of filter in GTK's file selector.
> > The one Jun made for labltk had one, and this is really nice.
> 
> I still don't understand the difference, but then if there trully is one,
> maybe be we should send a request for it to the gtk+ guys ?

Well, yes.
I just didn't do it because I felt lazy about having to discuss the
matter, an hoped that they would realize it for themselves, but since it
is not in 1.3 either, this might be a good idea to tell them.

Jacques