Re: [Texmacs-dev] Towards the TMGUI API

[Stéphane Payrard]

I am sorry to have side tracked the discussion with my requirement of
including perl for my pet project.  But this is this very projet that
is driving my thought all along but the conclusion I reached is of
general interest and I believe that I share it with David:

  The problem main TeXmacs is: it has a very high level entry point
  that discourages most people to do anything but some little fix
  patches here an there.

To be able to be a significant contributor in TeXmacs one must know
C++, guile, understand your toolkit and read a lot of code.  My short
term concern is to lower that entry point. Joris has done a
significant step in that direction by replacement of the
current toolkit from TeXmacs except the layout widget is the next
step.

Next is to expose a TeXmacs API so that one can use TeXmacs
as a widget/library and hook their favorite extension language.
Boy. Here I am at it again. :) :(

back to the toolkit replacement.

I am reading your proposals. I am not quite sure what to think of them.
But I don't think I am obliged to make immediately my mind  about it.

Indeed, thanks to discussions in the #qt  IRC, I am currently thinking of
a small step that gives a replacement toolkit without to have ot think
too much about later issues, thanks to the QXtWidget class.  It takes an
account the experience acquired by some dabblings I already made.  IT
can be broken in subgoals:

  1/ Document the interactions  between the main widget
  and the other other ones. This interaction are quite high level
  and should be pretty much toolkit independant.

  2/ Temporarily sever these links between the main widget and
    the other  (done before)

  3/ Derive the main widget from  QXtWidget. I hope this proves 
   possible. It does not buy any kind of portability. QXtWidget
   is designed for the inclusion from a foreign X widget in a
   Qt app. I am worried because the doc speak only of a Xt/Motif
   extension but I believe it means anything that was intended 
   raw X event.

  4/ Reconnect the main widget to Qt widgets

This replacement of your toolkit by Qt buys us  nothing toward a port
to another window system. But I have no worry of Qt being able to do
everything that you tookit does (mostly dynamic menus that include
some bitmaps outputted  by your layout engine).

Also, it permits to defer the thinking about what we really need to
get a portable main widget. Do we need to keep the current layer of
events? This is tempting because it abstracts the main widget from the
underlying event model. But as I said, we may think that later.  The
input from David friend may help us here.

I understand it may be frustrating to drop you babiy that I would not
dare to criticize per se: I even learnt pattern driving programmation
by reading your toolkit code. The problem is that project it sets an
higher entry point in your real project as far as TeXmacs is concerned
: an interactive structured layout engine.

Example: in working a patch for the menu, I came into C++ code that
generate Guile for dynamically building the buffer menu. It should be
the other way around. TeXmacs should expose an API so that Guile or
whatever langage can access the necessary info to build the menu.

As a result of this shortcoming to submit that minor patch, I must
master C++, guile, the guile API for menus.

I hope I made clear that the nongencc stuff (completed by David and
inetegrated in the current TeXmacs version) and this port to Qt are
lowering the entry point for potential contributors.

--
    stef