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

[David Allouche]

On Thu, Aug 01, 2002 at 10:30:02PM +0200, Joris van der Hoeven wrote:
> 
> On Thu, 1 Aug 2002, David Allouche wrote:
> 
> > First, I need several new predicates and observer functions in GUILE
> >  for the enabled state of the menu items or they checkmarks:
> > 
> >     get-clipboard: string -> tree
> >     full-screen?: -> bool
> >     get-shrinking-factor: -> int
> >     session-use-math-input?: -> bool
> >     get-insertion-positions: -> string
> > 
> > I would also need predicates related to selection translation:
> > 
> >     selection-get-import: -> string
> >     selection-get-export: -> string
> > 
> > But I am wondering why not move all the selection/translation related
> > logic to the Scheme layer...
> 
> Yes, this should indeed be done, but we have to be careful to distinguish
> between system wide settings, window related settings and
> buffer related settings. So what we need is functions
> 
> set-buffer-property!: scheme_tree, scheme_tree -> void
> get-buffer-property : scheme_tree -> scheme_tree
> set-window-property!: scheme_tree, scheme_tree -> void
> get-window-get-property : scheme_tree -> scheme_tree
> set-system-property!: scheme_tree, scheme_tree -> void
> get-system-property : scheme_tree -> scheme_tree

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.

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.

Also, since the "properties" being get or set are mostly data members
of the C++ objects, I do not understand why a hashmap would be needed...


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

> > More importantly, I think the current "implicit rule" mechanism is way
> > to rigid. It could be simple to implement an extensible system of
> > implicit rules using the following procedure properties:
> > 
> >   -- check-mark: "*", "v" or "o"
> > 
> >   -- check-test: predicate to apply to the same parameter list as the
> >      procedure to which it is associated and which return the checked
> >      state of the menu item.
> > 
> > Here too, it may be possible to do with minimal hacking in C++, but
> > since widgets now have a GUILE interface, why not move the menu
> > construction code (at least make_menu_item) to GUILE?
> 
> 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.

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

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") but one of the first steps is obviously moving as much GUI
*logic* to the GUILE layer to allow reuse by different GUI shells.

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.

-- 

                             -- David --