Re: [Texmacs-dev] Towards the TMGUI API

[David Allouche]

I have been thinking about that issue for a few days, and I think it
is time for me to lay my thoughts out for further discussion.

I have not yet grokked your proposal in its fullness, and I am just
making a fresh brain-dump of how I see the problem. This proposal is
done with minimal consideration of the legacy code, because otherwise
I would not be able to make the big picture.

Basically, I am designing here my TMGUI of dreams.


  What is ugly
 ==============

A naive approach of the TMGUI problem may consider a system of two
components: the TeXmacs kernel and the GUI, and would perform the
interfacing through a wholly C++ API. The GUI would allow TeXmacs to
offer services to the rest of the system (handling events, and basic
levels of IPC communication like opening files on double-click of a
document and clipboard access), and it would allow TeXmacs to use
services from the system (creation and placement of widgets, on-screen
drawing for the psdevice, pixel stuff to avoid flickering, etc).

That approach is what I call the TeXmacs centric approach. I think the
right approach is very different both in philosophy and in
implementation.


  First Principles
 ==================

Now I will present how I would like all the system to be designed to
allow maximum flexibility of the look-and-feel, better separation of
the roles of the various components.

The TeXmacs kernel should be as passive as possible. That means that
its interface should avoid as much event-driven features as possible.
A passive kernel is good because it allows the use of lazy
implementations, for example, it may not be necessary to compute the
position of all boxes, but only of those which are displayed, and it
it is not necessary to rasterize fonts which are not in the current
viewport. It is also good because it contains no policy, thus taking
us nearer to the point where texmacs is a library for use by every
text editor.

The kernel and the GUI must be GUILE modules. Each part would only
provide the binary API which is most natural to it, and the scripting
language would make the glue between these two parts. One advantage of
this approach is that it will move most of the "square peg in round
hole" problems to the very high level scripting langage.

At this point still have a pretty obvious design, which is more or
less what is already existing: A TeXmacs backend, a GUI frontend, and
some GUILE middleware. The real news are in how the TeXmacs canvas
should be handle its own passivity.


  Passive TeXmacs
 =================

What is the functional design of the TeXmacs kernel?

  -- Initial typesetting: data tree --> side effect, box tree

  -- Incremental typesetting: tree action --> side effect, box action

  -- Physical-logical mapping: pixel --> path in box tree or data tree

  -- Incremental physical-logical mapping (physical motion):
     pixel, delta pixel --> corrected pixel, path in box or data tree

  -- Logical-physical mapping:
     path or range in box or data tree --> pixel region

  -- Context access: path in box or data tree, name --> value

  -- Setting and getting markers (for performance).
  
  -- Assorted state observers, data tree observers, box tree
     observers, and so on.


Please let me know if I forgot something.

As much event driven behaviour as possible should be moved out of the
TeXmacs kernel. That means that the kernel should only use callbacks
for returning from asynchronous calls.

Notice that this interface has absolutely nothing related to concrete
display. All display should be done by the GUI. That takes us to the
next step: High bandwith communication between the kernel and the GUI
and the font system.


  Display layer
 ===============

Almost every thing hapenning between the user and the kernel can
tolerate the communication overhead of GUILE. After all, the user is
sooooooo, slow... But yet the user has slow fingers, he does have
sharp eye, and is feedback-greedy. So all display-related matters must
be done at warp speed.

One solution would be to give the kernel direct access to thinly
wrapped low-level drawing primitives (aka. the ps_device). But that is
not good enough, at least because some things like the drawing
policies of the selection or caret are system dependent.

What I propose is to leave the actual conversion from boxes to drawing
operations to the GUI. In the current situation, the GUI would merely
delegate it back to the existing logic, but that would give it a
chance to override whatever is necessary. So, at first, that proposal
is roughly equivalent to just asking the GUI to implement ps_device.

Putting the interface at this more basic level, should also make it
easier to perform embedding of external tools in platform-dependent
ways. For exemple we may keep gv embedding on X11, but use the PS
device abilities of the system where provided.

In that way, the current screen font handling code would be a support
backend used by the GUI.

That Display aspect of the GUI would provide the following services:

  -- Display loading: box tree -> nil

  -- Display update: box action -> nil

These aspects are closely related to the "initial typesetting" and
"incremental typesettings" roles of the kernel. The information is
transmitted from the GUI to the typesetter through a C++ level box
interface, allowing maximum efficiency.

In addition, it would provide all things needed to make the editor
work (which is going to be moved to GUILE anyway):

  -- Draw cursor: box path, context -> nil
 
  -- Draw selection: region -> nil

  -- Maybe some other stuff.


  Scheme subsystems
 ===================

In our proposed architecture, most of the high-level logic is written
in GUILE. That code could be tentatively divided in the following
subsystems:

    -- TeXmacs wrapper, access to kernel features, possibly compatibility
       layer for deprecated APIs.

    -- GUI wrapper, callbacks and access to GUI features, provides
       a API which is specific to the GUI implementation.

    -- GUI glue, provides integration of the GUI wrapper with the rest
       of the program. This module could be considered central.

    -- Policy modules, essentially designed to be used with specific
       GUI implementation, but grouping all the features which were
       made platform independant. That modules will allow a X11 GUI to
       use most of the Win32 user interface policy, or a Macintosh GUI
       to use X11 policy.

    -- Support modules, provides features which may or may not be
       platform independent but are neither part of the TeXmacs kernel
       not part of the GUI. That modules would include file handling,
       parsing and unparsing, conversion filters, font handling, etc.


  Clipboard IPC
 ===============

Cut'n'paste is a knot of complexity in that problem. Actually
cut'n'paste itself started as a rather simple concept: a public
container for structured information (text, styled text, pictures);
but it slowly grown on various systems in something very elaborate,
providing drag'n'drop, publish-subscribe, component embedding and
probably a lot more I do not remember or never knew of.

In the proposed scheme, all the responsibility of clipboard management
is left to the glue and the GUI. These two parts will use the tree
observers provided by the editor kernel and the conversion algorithms
implemented either in Scheme or in C++ in support modules.


  Embedding inside TeXmacs
 ==========================

Platform specifics GUIs are free to perform embedding the way suit
them the best, since they use the very basic information from the
typesetter: the location of the embedding box, and its associated
information.


  Dialogs and menus
 ===================

One reason not to use a portable toolkit is that porting a GUI always
imply some amount of redesign. That redesign is separated in several
parts:

   -- look: we must use the native look of the platform

   -- layout: menus and dialogs must be arranged differently on
      different platforms.

   -- feel: we must use some host specific features, for example Win32
      provides a standard help system, we should try to put as much
      documentation as possible in that system.


That variability implies that simply using a portable toolkit is too
simple, and actually not structural enough. What would be best is to
represent the menus and the platform-independant dialogs in a
structural way (that is mostly done for menus) and allow each GUI
front-end to:

  -- override some of this specifications (like the location of the
     about, preferences, and print menu items, or the standard file
     and print dialogs,

  -- produce an appropriate concrete layout for dialogs and menus
     given the structural informations.


The production of that layout may require the use of typeset pictures,
that would be performed as needed by producing the required boxes with
a dummy typesetter instance and translating the boxes to pixmaps using
the same tool as for the main widget display.


  Choosing the toolkits
 =======================

Abandoning the idea of a platform independant toolkit is also likely
to actually make things easier on the long-term, because the technical
choices to be made on any platform will only be dependant on the
specifics of that platform.

So, how would we make up our mind? Since the focus of toolkit is no
longer portability, but instead convenience, we can use toolkits which
are rather limited by themselves but allow access to all the features
of the underlying system.

Unix: The user do not expect anything in particular from the GUI, but
they like it when an application integrates well in their desktop
environment of choice. Good documentation is better, but anyway we
have the code. ==> TXTK (TeXmacs ToolKit), GTK, Qt, wxWindows.

Windows: The user does have some expectations, but is not bothered by
slight inconsistencies, considering what a mess the system already is
once you use something else than only M$ apps. We just want to avoid
using MFC because that is horrible, and Qt because of the licensing.
==> GTK, wxWindows

MacOS Classic: Let us forget about that.

MacOS X: Here, it is very important to follow the user interface
guidelines, and use the Aqua toolkit. Since no commodity toolkit seems
to support Aqua, we would be best off writing a completely native GUI.
Apple tends to make libraries which are powerful and easy to use, and
they provide good developper tools.

An interesting and up to date page on toolkits:
http://www.atai.org/guitool/


A note on MacOS X:
  That is more important a market than it may seem at first. A lot of
  people who are constrained to using unix systems (or simply like
  them) are switching to MacOSX because it is the only unix with a
  really good graphical environment. Also, the Macintosh world
  contains a lot of people with little technical expertise, but smart
  enough not to follow the win32 cattle.
  We can expect more and more of the intended audience of TeXmacs
  (hackers, scientists, teachers, press) to use that system.

Side note: How about using a Java GUI?


  Conclusion
 ============

In previous mails, Joris asserted that GUI independance and the
revision of the Scheme API are unrelated problem. I disagree with that
view since using GUILE to perform the glueing of the kernel with the
GUI helps a lot to make things simpler.



-- 

                             -- David --