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 is
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
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 possib
> 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 co
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 keyb
> | 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
> beginni
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 ea
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 creat
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 L
> "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)
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 functi
Andre Poenitz <[EMAIL PROTECTED]> writes:
| > 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
> 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
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 m
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 c
> > 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.
>
> "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
som
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 one arg
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,
|
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 commandt
> 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, where the index
> "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 w
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
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 status_fun
> "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 argume
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 ad
26 matches
Mail list logo
