Re: [Texmacs-dev] Towards the TMGUI API

[Joris van der Hoeven]

> back to the toolkit replacement.

Yes, let us focus on that; we can not do hundred things
at the same time :^)

>   3/ Derive the main widget from  QXtWidget. I hope this proves 
>    possible. It does not buy any kind of portability. QXtWidget
>    is designed for the inclusion from a foreign X widget in a
>    Qt app. I am worried because the doc speak only of a Xt/Motif
>    extension but I believe it means anything that was intended 
>    raw X event.

This would be a point to find out. However, we also need to know
whether we can use Qt for porting TeXmacs to Windows. I thought
that for a while, but I am not sure at all anymore...

Anyway, since you are acquainted with Qt now and I also
read some of the underlying design, we can just think of
Qt as an arbitrary GUI in further discussions.
As to actual implementations, we'll see...

>   4/ Reconnect the main widget to Qt widgets
> 
> This replacement of your toolkit by Qt buys us  nothing toward a port
> to another window system. But I have no worry of Qt being able to do
> everything that you tookit does

It would buy us a port to Windows, if permitted...

> (mostly dynamic menus that include
> some bitmaps outputted  by your layout engine).

Right.

> Also, it permits to defer the thinking about what we really need to
> get a portable main widget. Do we need to keep the current layer of
> events? This is tempting because it abstracts the main widget from the
> underlying event model. But as I said, we may think that later.  The
> input from David friend may help us here.

Let us agree on what you mean by main widget: the edit_interface?

I think we need noticebly less than the current event model.
Indeed, we mainly need to handle the following events:

  void handle_repaint (repaint_event ev);
  void handle_keypress (keypress_event ev);
  void handle_mouse (mouse_event ev);
  void handle_keyboard_focus (keyboard_focus_event ev);
  void handle_resize (resize_event ev);

and maybe some administrative events like:

  void handle_get_size (get_size_event ev);
  void handle_attach_window (attach_window_event ev);
  void handle_clear (clear_event ev);

This is what TeXmacs *provides* to the GUI (and this is what may be used
to embed TeXmacs in another application). Inversely, TeXmacs needs
a collection of widget constructors from the GUI and maybe a few methods
to set the current menus, icons, etc. (implemented by the GUI).

> I understand it may be frustrating to drop you babiy that I would not
> dare to criticize per se: I even learnt pattern driving programmation
> by reading your toolkit code. The problem is that project it sets an
> higher entry point in your real project as far as TeXmacs is concerned
> : an interactive structured layout engine.

I convinced myself that we have to get rid of the current GUI even though
we might keep it as one of the GUI's which meet the TMGUI API.

> Example: in working a patch for the menu, I came into C++ code that
> generate Guile for dynamically building the buffer menu. It should be
> the other way around. TeXmacs should expose an API so that Guile or
> whatever langage can access the necessary info to build the menu.

True; I started to do this, but I did not finish yet (widgets are
already supported by the scheme extension language, but we can't do
anything useful with them yet. The next thing I wanted to do is
rewrite tm_menus in Guile).

> As a result of this shortcoming to submit that minor patch, I must
> master C++, guile, the guile API for menus.

But you almost do that :^)

> I hope I made clear that the nongencc stuff (completed by David and
> inetegrated in the current TeXmacs version) and this port to Qt are
> lowering the entry point for potential contributors.

Yes, but this is not a surprise. Mainly, someone has to do the job...

And there are many other things to lower the entry point,
like good documentation, a well designed Guile interface,
a more comprehensive way to write style files, etc.

What I want to make clear is that I really need help in order
to get these things done. So some people will have to learn
and C++ and Guile and the current TeXmacs source code.
Nevertheless, I hope that my (rough) proposal for what
the TMGUI API should do indicates a reasonable way to go
in order to give TeXmacs a cleaner and toolkit independent GUI.
I also hope that it sheds some light on what is important and
what is (or should be) independent in the current code.