Re: [Texmacs-dev] Re: [TeXmacs] Announcement: TeXmacs.app for MacOS X Tiger

[Felix Breuer]

On Fri, 2006-02-17 at 19:12 +0100, David MENTRE wrote:
> Hello,
> 
> [ Follow-up on texmacs-dev@ as it is more a development issue. ]
> 
> Juan Pablo Romero <address@hidden> writes:
> 
> >[ Joris: ]
> >> For the new graphics mode, Henri and I are indeed considering changing
> >> the underlying libraries. Cairo and OpenGL are both good candidates.
> 
> Cairo is just a drawing library and does not have widget with native
> look and feel of the platform. 

That is a good thing, IMO. See below.

> OpenGL has the same issues as Cairo and moreover does not run on all
> platforms (think PDA and broken graphic card drivers).

PDA support, on the other hand, is a good thing to take into
consideration.

> >> We might also want to opt for an abstract layer (like the current
> >> ps_device) with different implementations.

Cairo provides exactly such an abstraction layer. It is not a proven
technology however

> Would this abstract layer be used for GUI drawing (menus, scroll-bars,
> etc.) or only for text and graphic rendering?
> 
> In fact, it seems to me that there are two different cases to consider:
> 
>  - the GUI (menus, ...) that should be done using a well known toolkit,
>    Qt 4 being a very good candidate;

I think it is a good thing, that TeXmacs does *not* tie itself to any
particular GUI toolkit, because:

* we could never agree on which TK to use (I can't stand Qt ;) 
* focusing on a particular toolkit limits portability/reusability 
* it would be huge amount of work, because "how TeXmacs talks to its
  GUI right now" and "how toolkit X wants to talk to its app" are very
  different

>  - the drawing area, for text and graphics rendering on different media
>    (screen, PDF, PS, ...). From what I have eared, Cairo seems to suite
>    the needs (works on Windows, Unix and MacOS X, abstraction of medium)
>    but others might have a more knowledged position.

This on the other hand looks like a very good thing to do to me. In
fact, I can only propose again to split TeXmacs (in the long run) into
several libraries, which, taken together, provide exactly the app we
know and love today, but which, when taken individually, can be reused
in several ways.

Off the top of my head, the components could be:

* the TeXmacs file system server / document graph server, which
  - maintains the document tree (graph)
  - keeps a history (undo tree)
  - provides network transparency
  - (and multiuser support?)

* a DRD / stylesheet library (perhaps integrated in the server), which
  - allows definition of DRDs and macros
  - transparently expands parts of the document graph according to the
    defined macros
  - checks constraints defined in DRDs
  - all in all, provides a stylesheet engine (insofar as a stylesheet
    is a transformation of the document graph)

* the TeXmacs layout/typesetting library, which
  - uses an abstract drawing library (which may be custom, or Cairo, or
    OpenGL, or whatever) to render to any kind of medium
  - may be used (together with the server) without a GUI to provide
    a typesetting engine that can be run on a server as a complete
    LaTeX replacement
  - other applications can link against this lib, to get mathematical
    typsetting functionality.

* the comprehensive collection of styles, packages and export/import
  filters already in TeXmacs

* the current (non-toolkit) GUI, implemented on top of the abstract 
  drawing lib

If the components of TeXmacs are split into libraries (and/or
clients/servers) this way people can implement native GUIs for any
toolkit they like. But on top of that we get a lot of flexibility and
allow people to use the great technologies already implemented in
TeXmacs in their own apps. Just a few benefits I can think of:

* The possibility to use TeXmacs to render formulas in Cairo or OpenGL
apps alone would be of use to a great many people (me included :) and
would give TeXmacs a significant boost in popularity. 

* The ability to run TeXmacs on a server as a "headless" typesetting
engine (with a lot of nice properties beyond those of LaTeX) might make
publishing houses more amiable to the idea of integrating TeXmacs into
their line of production. 

* The TeXmacs server could turn TeXmacs into a collaborative authoring
environment, which (in combination with the sessions to CASs and
customizable UIs) might also be interesting as a teaching environment.

Of course splitting TeXmacs in the way mentioned above would be a huge
undertaking. But most of the functionality mentioned is already
available in TeXmacs and has only to be made available to the "outside
world". I think the above would be of far greater use than simply
porting TeXmacs to GUI toolkit XY but it would allow for toolkit GUIs to
be implemented cleanly without "tying" TeXmacs to any particular
toolkit.


Ultimately, I don't know enough about TeXmacs' interna to judge the
feasibility of my proposal. But I truly think that opening up TeXmacs in
this way could help this great piece of software realize its full
potential.


Best,
Felix