Re: [Texmacs-dev] Towards the TMGUI API

[David Allouche]

Obviously you are thinking quite a lot about GUI issues right now. At
the moment, I lack the time to examine what you are up to, however I
want make myself heard before you go ahead.

Submitting the development plans of TeXmacs publicly for discussion is
really a great step forward to a more community oriented development
of TeXmacs. At the moment you may not get a lot of a feedback, but my
belief is that will help to improve the feeling of involvement for all
the people interested enough in TeXmacs to read that mailing list.

However, you must realize that very few people can understand what you
are up to. Stefp seems to do since he has spent a lot of time studying
the GUI code, but I think no one else here is able to really
understand the concrete issues discussed in your mails, even less make
proposals (I hope nogencc will help that in the long run, though).

Your setting things down seems to show some feeling of urgency. My
first and strongest recommendation is urging you to SLOW DOWN so that
other interested people can have the time to read your ideas,
understand them, reflect on them, and make proposals.

Personally, I am at complete loss and do not think I will be able to
grok your current project in fullness before a week (my current
priority is the restructuring of the menus you hurried me to do).

Yet, a recent discussion with another seasoned developer (Benoit
Widemann, who has been developing successful freewares and sharewares
on MacOS for years) introduced me to some very strong points which are
not irrelevant to the current discussion.

Each user environment not only sets technical compatibility issues
(problems to get the code to run), but also *policy* issues. A
*successful* port to another desktop environment is not merely getting
foreign code to run on different systems (that is a *poor* port), but
making the application integrate seamlessly in the host environment.

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."

The only right way to provide seamless integration in foreign system
is using separate "platform shells" which not only provide interface
to the system, but also control how things are actually done. For
example, for an application to be successful on MacOS you have to
provide a very specific menu hierarchy (with the TeXmacs menu first
with About, Preferences and Quit) and specific commands to handle
windows.

Moreover, my bet is that you cannot make proper component embedding in
any sort of portable way without breaking local GUI policies. For
example, on Unix we are using Xlib embedding, but on Windows we will
probably to use COM (aka ActiveX) components, and on MacOS we will
have to use the embedding features of Cocoa.

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.

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.

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.

You sounds like that is TeXmacs which should be controlling the GUILE.
Well, it is not. The only thing that TeXmacs should control is the
display. All the rest should be done by either:

        -- GUI executing Scheme commands in reaction to user actions.
        -- GUI sending events to the editor widget
        -- Scheme examining TeXmacs state

Actually, I could design a much more different architecture, but it
would take us far away from the current implementation. In that other
architecture TeXmacs would be completely passive and would only
perform box placement. 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).

Again... Please take your time. The current discussion is very
interesting, but it is complex. It is very time consuming, but will
probably shape the development of TeXmacs in the next year. So,
please, give the time to every interested person to read, understand,
think out and propose.

-- 

                             -- David --