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

[Joris van der Hoeven]

> > 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.

> 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.

> > > 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.

> I have not figured out yet how it work.

You should also specify a width for the cell.

> 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.