texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] Roadmap for GUI's and porting TeXmacs


From: Joris van der Hoeven
Subject: Re: [Texmacs-dev] Roadmap for GUI's and porting TeXmacs
Date: Fri, 26 Jul 2002 12:56:11 +0200 (MET DST)

I still continued to think about the global approach from
the previous email and in fact there might be a way to make
this approach more gradual too.

As I said before, there are two main TeXmacs widgets:
edit_interface.hh and tm_widget.hh. At a first stage,
one might try to port only edit_interface.hh and
reduce tm_widget.hh to the strict minimum, say a canvas
with scrollbars and no menus, icon bars and no footer.

This will reduce the complexity of the problem a lot,
because there is quite a lot of complex logic in tm_widget and
also quite a lot of complex logic in order to make edit_interface
and tm_widget communicate appropriately. In fact, the whole model
of tm_widget should be rethought, because we might like to
have multiple views in one window, draggable menus and
icon bars and more stuff like that. Consequently,
it is best to keep tm_widget as simple as possible to start with.

So what do we have to do concretely ifwe want
to port edit_interface without anything else?
First of all, we have to delete a lot of stuff:
virtually anything in src/Window, except the things
which have to do with ps_device, which we should keep
intact for a while. We should also delete virtually
anything in tm_widget and everything which has to do
with that. At the end of this, there should be nothing
left of type "widget" or "window" except in tm_interface and
the main frontend, and we may delete most methods in
the "display" class (at a first stage, we do not need to
care about X-fonts, help balloons, selections and dictionnaries).

The next step is to create a new abstract widget class,
which contains exactly the slots which will be implemented
in edit_interface, i.e. keyboard and mouse handling and
support for repainting. We should then adapt edit_interface
to derive from that class. At a first stage, we may keep
the keyboard handling very simple, so that it will only
be possible to type plain text. Later, we have to deal
with all the language extensions and the modifier keys.
The handling of mouse events should be quite trivial.

The main work will probably be to port the ps_device,
because we have to match the current coordinate convention,
so we should perform similar decode/encode operations
as is currently the case in x_drawable. This is quite
complicated, because we have to be very precise:
a one pixel difference may screw things up when scrolling.
Another complicated issue might be pixmaps, shadowing and
clipping, which is needed for font handling and in order
to prevent flickering. On the other hand, we may forget
about xpm and postscript at a first stage.

So: does anyone want to give this a try, maybe Stéphane?
The saga will probably be a bit longer than the nogencc one,
but I come to believe more and more that it actually should
not be that difficult, because the TeXmacs GUI is relatively
simple and modular. We might setup a CVS branch for a TeXmacs
version based on a new toolkit on Savannah, starting with
TeXmacs-1.0.0.10. When things start to get really working
(a few months from now if things progress as they should),
we will synchronize things with the default branch of TeXmacs
in a similar way as we did for nogencc.

<Joris>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]