Re: Proposed LyXFunc reworking

John Levon [EMAIL PROTECTED] writes: | o no longer is the various parts of a new function spread in four or five | different places. To add a new function means adding it to functions.C, | and (if necessary) a status tester to status_functions.C but that is almost true today as well. To add

Re: Proposed LyXFunc reworking

"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Couln't much of what you do be done with added some more fields Lars to the LyXAction lfun_item? (In your case a function pointer) That would probably be a good idea. One thing which would be nice too is to declare the arguments

Re: Proposed LyXFunc reworking

On 15 Jan 2001, Lars Gullik Bjønnes wrote: John Levon [EMAIL PROTECTED] writes: | o no longer is the various parts of a new function spread in four or five | different places. To add a new function means adding it to functions.C, | and (if necessary) a status tester to

Re: Proposed LyXFunc reworking

On 15 Jan 2001, Jean-Marc Lasgouttes wrote: That would probably be a good idea. One thing which would be nice too is to declare the arguments expected by the func and maybe their type. Any suggestions on how this might work ? thanks john -- "Threads are for people who can't program state

Re: Proposed LyXFunc reworking

"John" == John Levon [EMAIL PROTECTED] writes: John On 15 Jan 2001, Jean-Marc Lasgouttes wrote: That would probably be a good idea. One thing which would be nice too is to declare the arguments expected by the func and maybe their type. John Any suggestions on how this might work ? Maybe

Re: Proposed LyXFunc reworking

at the very least, without auto generation, you need : 1 place for the commandtag (commandtags.h) 1 place for the invoke method (lyxfunc.C) 1 place for the instantiation of the lyxfunc (LyXAction.C) What about nuking the commandtags and putting everything in a std::mapstring, whatever,

Re: Proposed LyXFunc reworking

On Mon, 15 Jan 2001, Andre Poenitz wrote: at the very least, without auto generation, you need : 1 place for the commandtag (commandtags.h) 1 place for the invoke method (lyxfunc.C) 1 place for the instantiation of the lyxfunc (LyXAction.C) What about nuking the commandtags and

Re: Proposed LyXFunc reworking

John Levon [EMAIL PROTECTED] writes: | On 15 Jan 2001, Lars Gullik Bjnnes wrote: | | John Levon [EMAIL PROTECTED] writes: | | | o no longer is the various parts of a new function spread in four or five | | different places. To add a new function means adding it to functions.C, | | and

Re: Proposed LyXFunc reworking

"John" == John Levon [EMAIL PROTECTED] writes: John how do strings fit in with the frontend menus ? Must I really John have some extra store of integers (the menu ID tags from the GUI John library) to strings ? The functions could be allocated a number when they are registered, or something

Re: Proposed LyXFunc reworking

the command? Comparing strings instead numbers should cost only a constant factor of time more than comparing enums, starting off from a very tiny amount. Morover, lookup in the map is O(ln n) compared to O(n) in the big case scwitch. So it shold not really be noticable. you are

Re: Proposed LyXFunc reworking

On 15 Jan 2001, Jean-Marc Lasgouttes wrote: "John" == John Levon [EMAIL PROTECTED] writes: John how do strings fit in with the frontend menus ? Must I really John have some extra store of integers (the menu ID tags from the GUI John library) to strings ? The functions could be

Re: Proposed LyXFunc reworking

On Mon, 15 Jan 2001, Andre Poenitz wrote: No. I am not. First of all I mentiond the existence of a constant factor and second, it does not matter. Even if the factor was 1000. How many lyx-functions are called per second? 1000? Likely less. Now, how long take 1000 string lookups in a map

Re: Proposed LyXFunc reworking

John Levon [EMAIL PROTECTED] writes: | On 15 Jan 2001, Jean-Marc Lasgouttes wrote: | | That would probably be a good idea. One thing which would be nice too | is to declare the arguments expected by the func and maybe their type. | | Any suggestions on how this might work ? for

Re: Proposed LyXFunc reworking

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "John" == John Levon [EMAIL PROTECTED] writes: | | John how do strings fit in with the frontend menus ? Must I really | John have some extra store of integers (the menu ID tags from the GUI | John library) to strings ? | | The functions could

Re: Proposed LyXFunc reworking

"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars My problem with Levons code that I feel it is too static. With Lars the scheme Andre and I propose it is very easy to load function Lars os demand or have them created in a scriptlanguage. (or as a Lars named keyboard macro). Then we

Re: Proposed LyXFunc reworking

On 15 Jan 2001, Lars Gullik Bjønnes wrote: My problem with Levons code that I feel it is too static. With the scheme Andre and I propose it is very easy to load function os demand or have them created in a scriptlanguage. (or as a named keyboard macro). This is probably possible with

Re: Proposed LyXFunc reworking

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes: | | Lars My problem with Levons code that I feel it is too static. With | Lars the scheme Andre and I propose it is very easy to load function | Lars os demand or have them created in a

Re: Proposed LyXFunc reworking

On 15 Jan 2001, Lars Gullik Bjønnes wrote: Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | | Lars My problem with Levons code that I feel it is too static. With | Lars the scheme Andre and I propose it is very easy to load

Re: Proposed LyXFunc reworking

| A lyxfunc could take a stream argument from which it reads the actual | arguments. Most commands are passed around as strings anyway so it makes no | difference where it is converted to int/double/whatwever. I'd rather have the real lyxfunc the the correct paramters from the beginning,

Re: Proposed LyXFunc reworking

John Levon [EMAIL PROTECTED] writes: | On 15 Jan 2001, Lars Gullik Bjnnes wrote: | | My problem with Levons code that I feel it is too static. With the | scheme Andre and I propose it is very easy to load function os demand | or have them created in a scriptlanguage. (or as a named keyboard

Re: Proposed LyXFunc reworking

I'd rather have the real lyxfunc the the correct paramters from the beginning, and have a wrapper that create those argumetns from the supplied stream. ... | If there really was a performance problem (which I seriously doubt) the | lyxfunc could come as a "core" function taking the correct

Re: Proposed LyXFunc reworking

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

Re: Proposed LyXFunc reworking

argh, I've just sent a summary. I'll address the additional things below here. On 15 Jan 2001, Lars Gullik Bjønnes wrote: 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

Re: Proposed LyXFunc reworking

On Mon, Jan 15, 2001 at 06:06:31PM +0100, Lars Gullik Bjnnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: | | A lyxfunc could take a stream argument from which it reads the actual | arguments. Most commands are passed around as strings anyway so it makes no | difference where it is

Re: Proposed LyXFunc reworking

John Levon <[EMAIL PROTECTED]> writes: | o no longer is the various parts of a new function spread in four or five | different places. To add a new function means adding it to functions.C, | and (if necessary) a status tester to status_functions.C but that is almost true today as well. To

Re: Proposed LyXFunc reworking

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Couln't much of what you do be done with added some more fields Lars> to the LyXAction lfun_item? (In your case a function pointer) That would probably be a good idea. One thing which would be nice too is to declare the

Re: Proposed LyXFunc reworking

On 15 Jan 2001, Lars Gullik Bjønnes wrote: > John Levon <[EMAIL PROTECTED]> writes: > > | o no longer is the various parts of a new function spread in four or five > | different places. To add a new function means adding it to functions.C, > | and (if necessary) a status tester to

Re: Proposed LyXFunc reworking

On 15 Jan 2001, Jean-Marc Lasgouttes wrote: > That would probably be a good idea. One thing which would be nice too > is to declare the arguments expected by the func and maybe their type. Any suggestions on how this might work ? thanks john -- "Threads are for people who can't program

Re: Proposed LyXFunc reworking

> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On 15 Jan 2001, Jean-Marc Lasgouttes wrote: >> That would probably be a good idea. One thing which would be nice >> too is to declare the arguments expected by the func and maybe >> their type. John> Any suggestions on how this might

Re: Proposed LyXFunc reworking

> at the very least, without auto generation, you need : > > 1 place for the commandtag (commandtags.h) > 1 place for the invoke method (lyxfunc.C) > 1 place for the instantiation of the lyxfunc (LyXAction.C) What about nuking the commandtags and putting everything in a std::map

Re: Proposed LyXFunc reworking

On Mon, 15 Jan 2001, Andre Poenitz wrote: > > at the very least, without auto generation, you need : > > > > 1 place for the commandtag (commandtags.h) > > 1 place for the invoke method (lyxfunc.C) > > 1 place for the instantiation of the lyxfunc (LyXAction.C) > > What about nuking the

Re: Proposed LyXFunc reworking

John Levon <[EMAIL PROTECTED]> writes: | On 15 Jan 2001, Lars Gullik Bjønnes wrote: | | > John Levon <[EMAIL PROTECTED]> writes: | > | > | o no longer is the various parts of a new function spread in four or five | > | different places. To add a new function means adding it to functions.C, |

Re: Proposed LyXFunc reworking

> "John" == John Levon <[EMAIL PROTECTED]> writes: John> how do strings fit in with the frontend menus ? Must I really John> have some extra store of integers (the menu ID tags from the GUI John> library) to strings ? The functions could be allocated a number when they are registered, or

Re: Proposed LyXFunc reworking

> > the command? > > > > Comparing strings instead numbers should cost only a constant factor of > > time more than comparing enums, starting off from a very tiny amount. > > Morover, lookup in the map is O(ln n) compared to O(n) in the > > big case scwitch. So it shold not really be noticable.

Re: Proposed LyXFunc reworking

On 15 Jan 2001, Jean-Marc Lasgouttes wrote: > > "John" == John Levon <[EMAIL PROTECTED]> writes: > > John> how do strings fit in with the frontend menus ? Must I really > John> have some extra store of integers (the menu ID tags from the GUI > John> library) to strings ? > > The functions

Re: Proposed LyXFunc reworking

On Mon, 15 Jan 2001, Andre Poenitz wrote: > No. I am not. First of all I mentiond the existence of a constant factor > and second, it does not matter. Even if the factor was 1000. > > How many lyx-functions are called per second? 1000? Likely less. > Now, how long take 1000 string lookups in a

Re: Proposed LyXFunc reworking

> John Levon <[EMAIL PROTECTED]> writes: > > | On 15 Jan 2001, Jean-Marc Lasgouttes wrote: > | > | > That would probably be a good idea. One thing which would be nice too > | > is to declare the arguments expected by the func and maybe their type. > | > | Any suggestions on how this might

Re: Proposed LyXFunc reworking

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "John" == John Levon <[EMAIL PROTECTED]> writes: | | John> how do strings fit in with the frontend menus ? Must I really | John> have some extra store of integers (the menu ID tags from the GUI | John> library) to strings ? | | The

Re: Proposed LyXFunc reworking

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> My problem with Levons code that I feel it is too static. With Lars> the scheme Andre and I propose it is very easy to load function Lars> os demand or have them created in a scriptlanguage. (or as a Lars> named keyboard

Re: Proposed LyXFunc reworking

On 15 Jan 2001, Lars Gullik Bjønnes wrote: > My problem with Levons code that I feel it is too static. With the > scheme Andre and I propose it is very easy to load function os demand > or have them created in a scriptlanguage. (or as a named keyboard macro). > > This is probably possible with

Re: Proposed LyXFunc reworking

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> My problem with Levons code that I feel it is too static. With | Lars> the scheme Andre and I propose it is very easy to load function | Lars> os demand or have them

Re: Proposed LyXFunc reworking

On 15 Jan 2001, Lars Gullik Bjønnes wrote: > Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > > | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > | > | Lars> My problem with Levons code that I feel it is too static. With > | Lars> the scheme Andre and I propose it is very

Re: Proposed LyXFunc reworking

> | A lyxfunc could take a stream argument from which it reads the actual > | arguments. Most commands are passed around as strings anyway so it makes no > | difference where it is converted to int/double/whatwever. > > I'd rather have the real lyxfunc the the correct paramters from the >

Re: Proposed LyXFunc reworking

John Levon <[EMAIL PROTECTED]> writes: | On 15 Jan 2001, Lars Gullik Bjønnes wrote: | | > My problem with Levons code that I feel it is too static. With the | > scheme Andre and I propose it is very easy to load function os demand | > or have them created in a scriptlanguage. (or as a named

Re: Proposed LyXFunc reworking

> I'd rather have the real lyxfunc the the correct paramters from the > beginning, and have a wrapper that create those argumetns from the > supplied stream. > ... > | If there really was a performance problem (which I seriously doubt) the > | lyxfunc could come as a "core" function taking the

Re: Proposed LyXFunc reworking

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

Re: Proposed LyXFunc reworking

argh, I've just sent a summary. I'll address the additional things below here. On 15 Jan 2001, Lars Gullik Bjønnes wrote: > 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

Re: Proposed LyXFunc reworking

On Mon, Jan 15, 2001 at 06:06:31PM +0100, Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > | > | A lyxfunc could take a stream argument from which it reads the actual > | arguments. Most commands are passed around as strings anyway so it makes no > | difference where it