OK, in fact I think we agree on almost everything. Let me try and
summarise a little :
1) everyone agrees that each lyxfunction should look after itself. This
includes pseudo-actions, which should be able to invoke their real
action *themselves*
2) everyone agrees there is a need for some object to contain every
lyxfunction, and provide various methods of looking it up
3) Lars and Andre argue for a string-based lookup. This shouldn't cause
any performance problems, and has the advantage of making
dynamically-added lyxfunctions easier. I agree, after consideration, that
string-based lookup as the primary method is good
4) There needs to be some way to deal with the frontend menus. These are
integer-based. There are only two options here :
i) each frontend has a container mapping from integer values to
strings, used on dispatch
ii) each lyxfunctions is assigned an integer ID, and the ability
to lookup in the container by ID is added.
Lars must be suggesting option i). This has the disadvantage that
similar management code must be replicated in each frontend, and
there needs to be logic for handling pseudo-actions etc. Why not
just centralise this code (and keep the data close to the object
!) by letting each lyxfunction know about its own numeric ID in
the kernel code ? This *doesn't* mean any code other than the
frontend/ code would use numeric lookup method.
5) Lars doesn't like the idea of generated code. John does ;) because
a) centralisation of all aspects of a lyxfunction. Lars previously
stated this wasn't of much concern to him, but I *definitely* agree
with JMarc that jumping all over the place when debugging is a pain
(along with hoping to increase my understanding of the lyx code,
this is my major motivation of the re-working).
b) the array in LyXAction.C does not give scope for adding
documentation, in an easy and readable way. The separation of the
method code (currently in the LyXFunc.C switch) from the lyxfunction
properties is a BAD thing.
c) Reference.lyx. 'Nuff said.
d) doxygen output. Oh I would like a developer's description of what
each LyXFunction does. Keeping it in the new functions.C would be
very nice
e) some other things I've forgotten
Comments ?
thanks
john
--
"Threads are for people who can't program state machines."
- Alan Cox
