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

[Joris van der Hoeven]

I think that it is time that we fix some very general strategy
on how we will port TeXmacs to other platforms.
Here are a few ideas.

1. I absolutely want GUI independence.
   There are several reasons for this:

   a) GUI's are instable: what is a nice GUI now maybe
      a bad or unsupported GUI later on. I lost a lot of time
      using the Openwin toolkit, which was standard in GNU/Linux
      distributions 5 years ago, but which does not exist anymore....

   b) Licensing of GUI's may change: look what happened to Qt.
      When Qt was proprietary, it was interesting to use Gtk instead.
      Now that Qt is almost GPL, Gtk seems to be slowly dieing...
      But Qt may rebecome proprietary!

   c) GUI independence forces good modular design.

   On the negative side, GUI independence forces us to
   use some kind of a "greatest common divisor" strategy,
   so that we may be unable to exploit certain fancy features
   of a given GUI. Nevertheless, this can also be considered
   to be a feature, because unstable features will be
   naturally discarded.

2. I have a strong preferance for splitting the GUI into two parts:
   the low-level interface with the Window manager and
   the toolkit with all kind of widgets. The reasons are:

   a) This modularity is already present,
      so we remain compatible with ourselves.

   b) It makes it possible to port TeXmacs in a more gradual way.

   c) Even if we don't manage to port the widgets of a given toolkit,
      as soon as we managed to port the first part, then *at least*
      we can run TeXmacs on all supported architectures by the toolkit,
      using our own widgets.

   From the external point of view, the toolkit should really
   be a list of widget constructors (like in widget.hh).
   This will enable us ultimately to construct the precise interface
   in a very dynamic way using the Scheme extension language
   (or anything else).

3. From a technical point of view, how do we find the greatest
   common divisor of several GUI's? How to make them compatible?
   For this, we need to analyze at least two or three existing
   GUI's first, as I and David started to do with the list
   from a previous mail. We also need to analyze the design
   strategy behind the present GUI and where we may expect
   problems to come from. Here are a few points:

   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.

   b) Transparent menu entries. This is a particular application of a).
      A menu entry may be an arbitrary widget in TeXmacs.
      Also, the menus are fully dynamic.

   c) Our system is widget-based (well, some call that gadget-based).
      It means that our widgets are not necessarily attached to windows.

   d) Keyboard modifiers. TeXmacs will need a lot of keyboard modifiers
      (Shift, Control, Alt, Meta/M$, AltGr, Hyper, User).
      This is possible (and still; quite complicated) in X.
      Is keyboard handling sufficiently flexible in the different GUI's?

   e) Fonts. We currently use almost only our own fonts,
      which require clipped pixmap operations and invisible pixmaps.
      Later on, we might want to use other fonts.

   f) Character encodings. We have a potentially universal encoding
      scheme. It should be possible to make our scheme compatible
      with Unicode, like in Qt. We have to be careful that something
      similar can be done for other GUI's.

   g) Keyboard and pointer grabbing. This has been particularly painful
      for me when designing the GUI: a small mistake and
      the application makes X hang.

   h) Graphics. All is done using the SI-based units.
      Some changes are to be foreseen in order to make wysiwyg font handling
      dpi-independent.

4. I am willing to make changes in the existing GUI if this is really necessary
   or if it leads to a fundamentally better design. However, as a general
   strategy, we should first look whether a toolkit can be made compatible
   with the existing conventions. Please throroughly argument proposed changes!

OK, I'm getting a bit tired. More later...

<Joris>