John Levon <[EMAIL PROTECTED]> writes:
| > Each LFUN is a function Levon and I agree on that, afaisi we disagree
| > on how to store the LFUNS and how to dispatch them.
| >
| > Lgb
|
| I don't even disagree on that !
very well
| Dispatch("menu-open eric-bristow") is perfectly possible in my
| proposal. If you want it like that, fine (but you will have to solve the
| frontend menu case as I mentioned - what is your suggestion here).
You want an unique number for each LFUN (dynamic from each run of Lyx
of course)?
This can easily be done by having a separate method for this. From the
menu code you ask for a "LFUN" number and you can use that to
access/dispatch the LFUN later.
This will also mean that we only store as many number as there will be
different requests for the "LFUN"s. (Not something I care a lot
about). (we store this in a vector f.ex. that contains iterators into
the real LFUN map.) (actually by this you get O(1) access to numbered
LFUNs.)
Access by LFUN name and you get O(ln) access.
How is it done now? We read a ui file that has the LFUN's as strings
| Rather it seems the disagreement is you don't like auto-generation,
| whereas I consider it necessary for debugging and documentation [1]
| purposes.
Oh, autogeneration of documentation is ok, but now of source files (I
even have problems with .fd and .moc :-), but I won't object to those)
| I'm not sure where the disagreement on the storage system is though ?
Perhaps we really agree.
| john
|
| p.s. my name is John ...
Sorry.
(Levon is just easier to remember)
| [1] and not just developer docs, as JMarc points out
I am well aware of this, and this has been in the plan from when we
decided that the LyXFunc needed a rework.
Lgb
