Re: [Texmacs-dev] New features for menus in TeXmacs 1.0.0.11

[Joris van der Hoeven]

> I am not sure I understand what you want to do. I want to get/set a
> number of attributes of the existing TeXmacs objects. I understand it
> may be better to use a few basic GUILE extensions in order to make the
> API more flexible.
> 
> But I do not think that is immediately related to my problem. It is
> more a question of a general refactoring of the GUILE API. It may
> indeed be necessary to do it sooner or later but I fail to see its
> immediate relationship with what I want to do.

The idea is simply to regroup all properties in a single hashmap
for each class (editor, tm_widget and server) instead of having
a bunch of variables and a separate method for setting/retrieving
values for/of each of them.

This supposes that a variable like "sfactor" would be replaced
by set_int_property ("sfactor", x) or get_int_property ("sfactor")
member functions of tm_widget in the TeXmacs code (set_int_propery calls
set_property and does some conversion) and that the set_property and
get_property routines are exported to the GUILE interface
as set-window-property and get-window-property.

This change will allow us to have a more uniform interface between
TeXmacs and GUILE for display, window and buffer related properties.
Notice that it may be necessary to insert some extra call back code
inside the set_property routines for a few special properties.

> By the way, I would rather call the procedures 'get-this-*-property'
> and 'set-this-*-property!' so we can later easily introduce variants
> which take a buffer/window/system as a parameter.

True, that is what I said in the later mail.

> > Notice also that we should change the way to deal with shrinking factors.
> > The shrinking factor should be a window related propery only and
> > it should be possible to set it in the user preferences too.
> 
> I leave that kind of change to you. That is too far away from the menu
> for me right now.

OK.

> > You want to do this? It should indeed be done, but that might take
> > a few days... In fact I already started doing this, by putting the widget
> > construction routines in the scheme interface.
> 
> I think I will give it a try. Since there are widget construction
> routines, it is time to try that kind of change.

OK. Please try to factor the code a bit more too in order
to make it more readable. This should be easier in GUILE.

> > Notice however that this is not really urgent. We might prefer to wait for
> > a TMGUI API which works on Windows first, in order to get some more ideas. 
> > It would be nice to construct other things like dialogue boxes in
> > a similar way.
> 
> That is really urgent to me.

Well, if you want to do it, fine.

> I have not yet taken the time to make a real roadmap for my vision of TMGUI
> (you know, the message you dismissed as "interesting but offtopic")

Right, or rather: *beyond topic*

> but one of the first steps is obviously moving as much GUI
> *logic* to the GUILE layer to allow reuse by different GUI shells.

I do not see this as part of the TMGUI API, because this is really
a matter of how to organize things in the most flexible way possible
*inside* TeXmacs. Nevertheless, as a separate project, it is indeed
important, so if you have time for it, great...

> One other step would be introducing thin adapters to change some
> internal interfaces (like making the typesetter passive), but you will
> read more about that before too long.

In fact, the very first steps should be

1. Remove virtually everything in src/Window except ps_device.

2. Remove virtually everything which depends on that in src/Edit
   and src/Texmacs.

3. Create two Qt (or whatever) widgets to replace edit_interface and
   tm_widget. The first one should do nothing. The second one should
   be capable of displaying the first one in a canvas.

4. After this, verify that TeXmacs compiles and runs again;
   it will do nothing interesting, but at least it should work again.

5. Progressively enrich the widget which replaces edit_interfaces with
   all methods of ps_device (except maybe postscript graphics,
   which may be postponed to later).

6. Enrich the interface between the replacements of edit_interface and
   tm_widget, so that you can set the extents of the main canvas.

7. After this, TeXmacs should run again and if you start it
   using "texmacs some-old-file.tm", then it should be possible
   at least to *display* and scroll old documents.

8. Enrich the edit_interface with methods to retrieve keyboard and
   mouse events. As to the keyboard events, you may start with
   the most simple ones. Later, support should be added for
   all possible keyboard modifiers. After this, you should
   be able to edit files again.

9. Do the final enrichments of tm_widget with menus, iconbars and
   a footer, etc. After this, TeXmacs has been ported...