Re: [Texmacs-dev] Roadmap for GUI's and porting TeXmacs

[Joris van der Hoeven]

I have continued to think about porting TeXmacs by reconsidering
the possibility to throw the entire existing GUI away.
Here are some thoughts on what to do if we want to go that road:

1. We still want GUI independence. A first task therefore has
   to be to define a precise API of what the GUI provides to TeXmacs
   (the question of what TeXmacs might provide to the GUI can
   also be considered, but this is quite independent).
   In order to know this, one has to look at the *two* main
   TeXmacs widgets, which are in edit_interface.hh and tm_widget.hh.

   The first widget is the main canvas (and this is also the principal
   widget which might be exported if one wants to embed TeXmacs in
   another application). It mainly requires routines for drawing
   graphics (the ps_device class) and it handles the most common events
   like key presses, keyboard focus, mouse events and redraw requests.
   Furthermore, it needs to communicate with tm_widget in order to
   change the menus, icon bars, the extents, the footer, etc.

   The second widget contains virtually no TeXmacs-related logic:
   it mainly organizes standard widgets like menus, iconbars,
   footers, a text entry on the footer, a canvas with scrollbars, etc.
   Of course, this organization is highly dynamic. The main needs for
   tm_widget from the GUI are thus a comprehensive set of widget
   constructors, like the ones in widget.hh.

   In any case, our first task is to make a very precise proposal
   of what the API of the GUI should be from the TeXmacs point of view.
   We should make this API as minimal as possible; we may always
   extend it later, once that the porting has been done.
   A thing what I or maybe David might do is adapt the current GUI
   so as to match this well designed new API, thereby facilitating
   the porting.

2. For the actual porting, there are two main approaches:
   the "all in once" approach and a subdivision in two steps.

   The all in once approach consists of throwing away everything
   in src/Window except ps_device related stuff and to rewrite
   edit_interface and tm_widget based on a new toolkit
   (via the API in 1 in order to ensure GUI independence).

   The other approach consists of adapting the programs in Window/X
   to a new toolkit first. After this step, TeXmacs should still have
   the same appearance as before but all the underlying circuitry is new;
   in particular, TeXmacs should already be portable after this step.
   From a technical point of view, one would have to write one widget
   for the new toolkit, which would somehow correspond to the current
   x_window class. Only at a second stage, one would remove
   the existing GUI and rewrite edit_interface and tm_widget.

   So how to compair the two approaches? The second one has the advantage
   that it is more gradual. However, it has the disadvantage that
   one has to port a certain number of things which where only
   used by the current widget system (like pointer and keyboard grabs).
   In other words, the main difficulties might come from the first step,
   and the efficiency of this approach really depends on how well it is
   possible to mimick the X interface in the new toolkit.
   The global approach has the advantage to avoid this extra work,
   but you somehow won't get anything running before everything is done.
   Also, more complicated features like the communication with ghostscript
   might become harder.

   In order to choose, we should thus look whether it might
   be possible to replace the routines in Window/X one by one.
   For instance, are there toolkits with a facility to mimick X,
   or directly issue X commands and treat X events? If we completely
   loose the advantage of graduality in the two-step approach,
   then the global approach might actually be better.
   Also, we should first design a good API like in 1;
   it will then become easier to make a choice.