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

[Juan Pablo Romero]

2006/2/18, Felix Breuer <address@hidden>:
> 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 ;)

Regarding toolkit looks, I must confess I find the latest gnome theme
a little bit more pleasant than current kde default theme (plastik).

But, from a developer point of view, and having tried both toolkits, I
can assure you that while gtk/gnome is good, qt is simply better. Of
course, talking is almost useless per se, he/she who came up with some
code will have the last word :)

Having said that, I think your proposal of splitting texmacs in
components is the best solution.

You also mention that it requires a lot of work. Perhaps an initial
step would be just to split the GUI from the rest of the system, and
allow the rest to be compiled as a stand-alone library. Provided
documentation exists, one should be able to integrate the base system
with some toolkit without having to master texmacs internals first.

And while anyone should be able to accomplish such task, it's clear
that current texmacs developers are the best prepared to do it.


> * 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
>
>
>
> _______________________________________________
> Texmacs-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/texmacs-dev
>