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

[Joris van der Hoeven]

>    a) TeXmacs is event driven system with a medium level of typing.
>       In compairison with Qt for instance, we do not have
>       the type safeness of the SIGNAL/SLOT system.
>       However, our event system has the powerfull advantage that
>       we can write so called transparant or modifier widget.
>       For instance, imagine that you have an arbitrary widget w,
>       which we want to modify or give some additional structure,
>       like a background color, another size, an additional method,
>       a button-like structure, etc. Then we may do this in a way
>       to send all non treated events (regardless of what kind!)
>       by the modified widget to w.

As to this particular and fundamental problem,
I propose the following strategy (illustrated in the case of Qt):

1. Write one Qt widget which corresponds to a TeXmacs window.
   It may take any possible event from the window manager and
   potentially reemit any possible event to both TeXmacs and
   later other Qt widgets.

2. The repainting and the event handling is exclusively taken care of
   by TeXmacs widgets at a first stage; implement the conversion
   of Qt events to TeXmacs events in the Qt widget from 1.
   This should eventually lead to a Qt port for the base level
   (i.e. X -> Qt, but without Qt widgets).

3. We now want to make it possible to interpret Qt widgets
   as TeXmacs widgets. In order to do so,
   the idea is to write a template which enriches the Qt widget
   with particular types of slots with the TeXmacs widget class.
   The TeXmacs handle function then translates TeXmacs events
   into Qt signals which are recognized by the slots.
   If there is a way to automatically detect the supported slots
   of a Qt widget, it might even be possible to write only one
   such template.

4. We also need to make it possible up to a certain extent
   to interpret TeXmacs widgets as a Qt widgets. If we *know*
   that the TeXmacs widget was actually a translated Qt widget
   as in 3, then we might try to use that information directly.
   Otherwise, we have to create a new Qt widget class with
   a slot for each possible TeXmacs event and which sends
   a TeXmacs emit to the corresponding TeXmacs widget.
   This is a bit dirty, because we need an exhaustive list
   of all possible TeXmacs events. But *we do not longer need
   the core TeXmacs GUI to be extensible*, so this is OK.

The points 1 and 2 should be reasonably easy to achieve.
The points 3 and 4 may be harder, due to the fact that
the signatures of TeXmacs events and Qt signals are not
necessarily the same. In the case of redraw, mouse click,
attribute, etc. events, this should be OK. But the automatic
negociation of size (get_size_event) and keyboard and pointer
grab events may need to be reviewed.

<Joris>