Re: [Texmacs-dev] Towards the TMGUI API

[Joris van der Hoeven]

> Seamless integration with the host environment is fundamental here.
> Everyone I talk with about TeXmacs believe that the real potential of
> TeXmacs is having its typesetting component used in other software
> tools. Unless we provide ports which comply well to local user
> interface policies, such integration will be hampered by intelligent
> people saying roughly "the engine is nice, but the GUI is such a mess,
> I cannot use that in my system or the management/clients/users are
> going to kick my ass."

Well, having a nice user interface which integrates in local
user interface policies and which is toolkit independent,
that is indeed what we are striving for here.

> Trying to force other systems into an Xlib-like interface is a *bad*
> idea. Xlib is a piece of crap, and you know it better than anyone else
> here. Forcing other systems in the current Xlib-like so-called
> "abstract" display layer may be very time consuming, unrewarding and
> in the end, ineffective.

Yes, and that is precisely why I took all the unnecessary parts
of X out of the TMGUI API. The only good abstraction which seems
universal enough to be kept is Application/Display/Window/Widget.

As to efficiency, I want the TMGUI API to be reduced to the minimum,
so that people can easily write a new TMGUI for a given toolkit.
Having a minimal abstract interface will enhance efficiency.

> My general feeling when I am sifting through your message is that you
> are taking a very TeXmacs centric view. Generally (not specifically
> here) your are considering how to make the world fit with TeXmacs. I
> do not believe you are taking the right approach... Instead you should
> ask yourself how to make TeXmacs fit in the world.

In fact, the TMGUI API works in both directions, even though
I currently tend to focus more on rewriting GUI's for TeXmacs
then the other way around. Nevertheless, the TMGUI API basically
says how the GUI and TeXmacs communicate and how we can make
both parts completely independend modulo this interface.

As a main design goal, I am striving for simplicity. Indeed,
although TeXmacs really does not have a very complicated GUI,
it looks too complicated for programmers and this has to change.
Now simplicity is obtained by asking the simple questions
        What does TeXmacs need from the GUI?
        What does the GUI need from TeXmacs?

Basically TeXmacs has one single important widget: the canvas.
We therefore have to specify what events are received by it and
what signals are emitted by it. The tmgui_texmacs class in
TMGUI API tells you this. It is *up to the GUI* to be able to
reinterpret the tmgui_texmacs class as a widget.
This will allow to embed TeXmacs in other applications.

Inversily, the GUI basically provides tools to create new widget and
user interface services. In order to create menus, popup windows and
stuff like that, TeXmacs therefore mainly needs a comprehensive
abstract set of widget constructors like in widget.hh now.
These constructors will be made available directly in the Scheme
interface, so that the whole can be controlled very easily
from outside TeXmacs.

> Technically, that translates in projects when TeXmacs control the GUI.
> I think that is not right. The GUI should control TeXmacs. One
> fundamental question here is defining the role of GUILE and what is
> its position with respect to the typesetting engine and the GUI,
> because in the end, that is GUILE which controls everything.

The GUILE or the GUI?

Anyway, no. We specify a communication protocol;
this may be used by *either* part to control the other.
No side should be privileged, we should focus on what
TeXmacs needs from the GUI and vice versa.

> The display and control of the editor would be
> done by the GUI/GUILE part. That would not only move most code out of
> the Edit directory, but would also allow better conformance of the
> display with local environment policy (like how the caret is drawn).

Yes, but I already told you thousand times that I *am* going to
reorganize the GUILE interface in that direction. But this is
another story, which is really independent from the communication
between the GUI and TeXmacs. From the GUI's point of view,
GUILE is part of TeXmacs.