Andre Poenitz [EMAIL PROTECTED] writes:
| Agreed to this point.
|
| | 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
| |
| Note that the container mapping from menu position to the lyxfunc could be
| as simple as a vectorstring for each container (I presume the integers
| are the positions in the menu and therefore small).
I foresee only one small problem, dynamically generated pseudo funcs.
They need a
I didn't follow the discussion, but I want to note that currently, the code
in LyXFunc::Dispatch is duplicated in InsetText::LocalDispatch, which is bad.
Are there plans for fixing this ?
On Tue, 16 Jan 2001, Dekel Tsur wrote:
I didn't follow the discussion, but I want to note that currently, the code
in LyXFunc::Dispatch is duplicated in InsetText::LocalDispatch, which is bad.
Are there plans for fixing this ?
Can someone explain exactly why we need Local Dispatch for the
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Agreed to this point.
|
| > | 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
| > |
> | Note that the container mapping from menu position to the lyxfunc could be
> | as simple as a vector for each container (I presume the integers
> | are the positions in the menu and therefore small).
>
> I foresee only one small problem, dynamically generated pseudo funcs.
> They need a
I didn't follow the discussion, but I want to note that currently, the code
in LyXFunc::Dispatch is duplicated in InsetText::LocalDispatch, which is bad.
Are there plans for fixing this ?
On Tue, 16 Jan 2001, Dekel Tsur wrote:
> I didn't follow the discussion, but I want to note that currently, the code
> in LyXFunc::Dispatch is duplicated in InsetText::LocalDispatch, which is bad.
> Are there plans for fixing this ?
Can someone explain exactly why we need Local Dispatch for the
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
On Mon, 15 Jan 2001, John Levon wrote:
5) Lars doesn't like the idea of generated code. John does ;) because
So do I. Running around between the three or four files is a pain in the
fingers. Is it Friday yet? It feels like Friday.
If you use m4 for this then we won't be adding yet another
John Levon [EMAIL PROTECTED] writes:
| 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
On Mon, Jan 15, 2001 at 06:05:00PM +, John Levon wrote:
4) There needs to be some way to deal with the frontend menus. These are
integer-based. There are only two options here :
Hmmm why not generate the integer ID# for each lyxfunc from some
string-hashing function? A
Agreed to this point.
| 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
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
On Mon, 15 Jan 2001, John Levon wrote:
> 5) Lars doesn't like the idea of generated code. John does ;) because
So do I. Running around between the three or four files is a pain in the
fingers. Is it Friday yet? It feels like Friday.
If you use m4 for this then we won't be adding yet another
John Levon <[EMAIL PROTECTED]> writes:
| 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
On Mon, Jan 15, 2001 at 06:05:00PM +, John Levon wrote:
>
> 4) There needs to be some way to deal with the frontend menus. These are
> integer-based. There are only two options here :
Hmmm why not generate the integer ID# for each lyxfunc from some
string-hashing function? A
Agreed to this point.
> | 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
18 matches
Mail list logo
