Re: [Texmacs-dev] Roadmap porting TeXmacs and the TMGUI API

[Stéphane Payrard]

Hi,

On Sat, Aug 03, 2002 at 10:40:10AM +0200, Joris van der Hoeven wrote:
> 
> > > OK; do you plan to support CVS access there so that I, David or
> > > others can help you on certain points whenever this is appropriate?
> > 
> > This site is not yet about source and it will not be TeXmacs sources
> > but sources using TeXmaccs.  Indeed it will publicize what we will be
> > able to do with perl and TeXmacs once I will have shallow Qt + shallow
> > Perl done.  I have no reason to fork what rightly belongs to TeXmacs.
> 
> OK, so do you want me to setup a CVS directory for the source code?
> I think that this would be very useful for David, me and others.
> It is good for us to see the progress, to study your code,
> and to help you whenever you get stuck on a silly problem.

I had to get the architecture right. Dealing with the main loop is a
prerequisite for the rest.  About CVS, I don't care much. I am not in
ingremental mode yet. Once I get something working I send a patch.  I
am eagerly waiting to have avanced enough so that TeXmacs will make
CVS altogether obsolete.  Program are trees after all and TeXmacs
native structures are trees too.

> 
> > We will be able to use the Qt loop without Perl and without
> > any Qt widget. That is what the shallow Qt port is about.
> 
> Great. In fact, the right way to connect Perl to TeXmacs is to
> use the common interface which all computer algebra systems use too.
> This interface will be enhanced more and more in the future and
> it would be good to reuse it for alternative extension languages
> to Guile.

Certainly we should be able to use interfaces for shellish languages
(meaning, interactive languages with input and output interleaved),
but we want also a tighter relationship for extension languages.

> 
> > > > Probably, the first example will be to use the
> > > > POE::Component::Client::HTTP to pull web pages while updating the
> > > > status line. Currently we use curl or whatever and we don't get any
> > > > feedback about the loading of a page.  BTW: this means that the
> > > > tm_widget interface is public.
> > > 
> > > I do not follow you completely.
> > 
> > This just an exemple of what shallow Qt + shallow perl will buy us.
> 
> OK, I see.

Things will get clearer once I will have released my code.

> 
> > I have not figured out yet how it work.
> 
> You should also specify a width for the cell.

This is very much what I feared.  a web browser is able to figure out
the best size of the cells when they are not indicated one way or another.

> 
> > Once I know it is working I
> > can write a filter.  Perl is the language for that kind of thing.
> 
> I am not sure; I think that filters naturally decompose into two parts:
> a string-manipulation part (mainly parsing, output generation being easy),
> for which Perl is probably the best choice, and a tree-manipulation part,
> for which Guile is probably better.
> 

I see no problem for a filter to generate TeXmacs documents. In that
case, it has not to know about TeXmacs trees. If the document is fed
to TeXmacs, it eventually should be able to display it progressively
like I said with incoming HTML.

This is a cultural problem too. You will find more easily Perl/Python/Ruby 
programmers
than Guile programmers.

--
  stef