?
LyXAction is the dictionary of known LyX functions, with their names and
properties (together with FuncCode.h for the enums).
LyXFunc contains the basic mechanism to execute these functions. It
should soon become a variable-less class, and part of its contents will
be moved somewhere else. This is in flux
ed to distinguish these two?
LyXAction is the dictionary of known LyX functions, with their names and
properties (together with FuncCode.h for the enums).
LyXFunc contains the basic mechanism to execute these functions. It
should soon become a variable-less class, and part of its contents w
Hi all,
Re-sending. I am trying to understand the LyX flow of control. Appreciate
any help. Apologies for the duplicate.
Thanks,
Manoj
-- Forwarded Message --
Subject: LyXAction, LyXFunc
Date: Sunday 07 February 2010
From: Manoj Rajagopalan rma...@umich.edu
To: LyX
Hi all,
Re-sending. I am trying to understand the LyX flow of control. Appreciate
any help. Apologies for the duplicate.
Thanks,
Manoj
-- Forwarded Message --
Subject: LyXAction, LyXFunc
Date: Sunday 07 February 2010
From: Manoj Rajagopalan <rma...@umich.edu>
T
Hi all,
These classes seem to be related. Could someone help me understand what
each does and how they are related? IIUC, both are meant to be singletons
which help with translating user inputs and commands into FuncRequest
instances that cause the update of the document or LyX application
Hi all,
These classes seem to be related. Could someone help me understand what
each does and how they are related? IIUC, both are meant to be singletons
which help with translating user inputs and commands into FuncRequest
instances that cause the update of the document or LyX application
sanda wrote:
Author: sanda
Date: Tue Jan 20 15:51:18 2009
New Revision: 28257
URL: http://www.lyx.org/trac/changeset/28257
Log:
Backport
Pavel, can we please return to the practice of posting branch-patches to the
list before committing? I really like to understand the changes to branch.
Jürgen Spitzmüller wrote:
sanda wrote:
Author: sanda
Date: Tue Jan 20 15:51:18 2009
New Revision: 28257
URL: http://www.lyx.org/trac/changeset/28257
Log:
Backport
Pavel, can we please return to the practice of posting branch-patches to the
list before committing? I really like
Pavel Sanda wrote:
sorry, shoould i revert?
No. But could you try to explain in one or two words what the change does?
Jürgen
Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
sorry, shoould i revert?
No. But could you try to explain in one or two words what the change does?
i discovered this glitch while backporting fix for 5389.
1. set new window for each opened file in preferences
2. new file (window 1)
3. open file
Pavel Sanda wrote:
i discovered this glitch while backporting fix for 5389.
1. set new window for each opened file in preferences
2. new file (window 1)
3. open file registered under rcs (window 2)
4. checkout for edit, type something
5. check-in - question for saving the file - yes - dialog
Jürgen Spitzmüller wrote:
I see. Do we need to check for lyx_view_ != 0 at this place, as we do
otherwhere?
no, it has been checked before.
pavel
Pavel Sanda wrote:
I see. Do we need to check for lyx_view_ != 0 at this place, as we do
otherwhere?
no, it has been checked before.
OK. Thanks for the explanation.
Jürgen
sanda wrote:
> Author: sanda
> Date: Tue Jan 20 15:51:18 2009
> New Revision: 28257
>
> URL: http://www.lyx.org/trac/changeset/28257
> Log:
> Backport
Pavel, can we please return to the practice of posting branch-patches to the
list before committing? I really like to understand the changes to
Jürgen Spitzmüller wrote:
> sanda wrote:
> > Author: sanda
> > Date: Tue Jan 20 15:51:18 2009
> > New Revision: 28257
> >
> > URL: http://www.lyx.org/trac/changeset/28257
> > Log:
> > Backport
>
> Pavel, can we please return to the practice of posting branch-patches to the
> list before
Pavel Sanda wrote:
> sorry, shoould i revert?
No. But could you try to explain in one or two words what the change does?
Jürgen
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > sorry, shoould i revert?
>
> No. But could you try to explain in one or two words what the change does?
i discovered this glitch while backporting fix for 5389.
1. set new window for each opened file in preferences
2. new file (window 1)
3. open
Pavel Sanda wrote:
> i discovered this glitch while backporting fix for 5389.
> 1. set new window for each opened file in preferences
> 2. new file (window 1)
> 3. open file registered under rcs (window 2)
> 4. checkout for edit, type something
> 5. check-in -> question for saving the file -> yes
Jürgen Spitzmüller wrote:
> I see. Do we need to check for lyx_view_ != 0 at this place, as we do
> otherwhere?
no, it has been checked before.
pavel
Pavel Sanda wrote:
> > I see. Do we need to check for lyx_view_ != 0 at this place, as we do
> > otherwhere?
>
> no, it has been checked before.
OK. Thanks for the explanation.
Jürgen
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak Right now there is only one LyXView for one LyXFunc. There
Abdelrazak are two way forward for the multiple LyXView problem.
Abdelrazak 1) Application maintains a map of LyXFunc indexed by the
Abdelrazak LyXView ID as given
>>>>> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Right now there is only one LyXView for one LyXFunc. There
Abdelrazak> are two way forward for the multiple LyXView problem.
Abdelrazak> 1) Application maintains a map of LyXFu
Hello,
This patch replaces BufferView-LyXView-getLyXFunc() with
theApp-lyxFunc().
I am not sure yet how to proceed with the LyXView/LyXFunc interaction
and the dispatch machinery.
Right now there is only one LyXView for one LyXFunc. There are two way
forward for the multiple LyXView
Hello,
This patch replaces BufferView->LyXView->getLyXFunc() with
theApp->lyxFunc().
I am not sure yet how to proceed with the LyXView/LyXFunc interaction
and the dispatch machinery.
Right now there is only one LyXView for one LyXFunc. There are two way
forward for the multipl
Abdelrazak Younes wrote:
Are you sure you cannot come [to denmmark]?
I'd like to but it will be difficult.
I think going to Denmark will by far be the best way to solve the issues.
In the history of LyX, there has been a tradition of long and intense
discussions about this and that. They
Asger Ottar Alstrup wrote:
Abdelrazak Younes wrote:
Are you sure you cannot come [to denmmark]?
I'd like to but it will be difficult.
I think going to Denmark will by far be the best way to solve the issues.
In the history of LyX, there has been a tradition of long and intense
discussions
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak I am sure he his but that is not the problem. We should be
Abdelrazak able to work out the frictions without meeting face to
Abdelrazak face.
It is not always possible.
JMarc
Abdelrazak Younes wrote:
I am sure he his but that is not the problem. We should be able to
work out the frictions without meeting face to face.
The problem here is that humans interface better face to face. E-mail
is ok for
conveying ideas, but not emotions. Or an impression of how
On Mon, Sep 18, 2006 at 12:19:55PM +0200, Abdelrazak Younes wrote:
Asger Ottar Alstrup wrote:
Abdelrazak Younes wrote:
Are you sure you cannot come [to denmmark]?
I'd like to but it will be difficult.
I think going to Denmark will by far be the best way to solve the issues.
In the
On Sun, Sep 17, 2006 at 10:19:25PM +0200, Abdelrazak Younes wrote:
A pity that you cannot come to denmark, we should get drunk (at least
I) and then we could go outside and fight it out.
You'd loose, I've been practising French boxing in my youth.
Are you sure you
cannot come?
I'd like
Abdelrazak Younes wrote:
Are you sure you cannot come [to denmmark]?
I'd like to but it will be difficult.
I think going to Denmark will by far be the best way to solve the issues.
In the history of LyX, there has been a tradition of long and intense
discussions about this and that. They
Asger Ottar Alstrup wrote:
Abdelrazak Younes wrote:
Are you sure you cannot come [to denmmark]?
I'd like to but it will be difficult.
I think going to Denmark will by far be the best way to solve the issues.
In the history of LyX, there has been a tradition of long and intense
discussions
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> I am sure he his but that is not the problem. We should be
Abdelrazak> able to work out the frictions without meeting face to
Abdelrazak> face.
It is not always possible.
JMarc
Abdelrazak Younes wrote:
I am sure he his but that is not the problem. We should be able to
work out the frictions without meeting face to face.
The problem here is that humans interface better face to face. E-mail
is ok for
conveying ideas, but not emotions. Or an impression of how
On Mon, Sep 18, 2006 at 12:19:55PM +0200, Abdelrazak Younes wrote:
> Asger Ottar Alstrup wrote:
> >Abdelrazak Younes wrote:
> >>>Are you sure you cannot come [to denmmark]?
> >>
> >>I'd like to but it will be difficult.
> >
> >I think going to Denmark will by far be the best way to solve the
On Sun, Sep 17, 2006 at 10:19:25PM +0200, Abdelrazak Younes wrote:
> >A pity that you cannot come to denmark, we should get drunk (at least
> >I) and then we could go outside and fight it out.
>
> You'd loose, I've been practising French boxing in my youth.
>
> >Are you sure you
> >cannot come?
(BufferView * bv)
+bool LyXFunc::ensureBufferClean(BufferView * bv)
{
Buffer buf = *bv-buffer();
if (buf.isClean())
@@ -668,12 +666,14 @@
_(Cancel));
if (ret == 0)
- bv-owner()-dispatch(FuncRequest(LFUN_BUFFER_WRITE
Abdelrazak Younes [EMAIL PROTECTED] writes:
| This avoids the bv-owner()-dispatch() redirection.
|
| Will commit soon.
I am not confident in its correctness.
--
Lgb
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| This avoids the bv-owner()-dispatch() redirection.
|
| Will commit soon.
I am not confident in its correctness.
I am not confident in your empty argument.
Abdel.
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| Abdelrazak Younes [EMAIL PROTECTED] writes:
| | This avoids the bv-owner()-dispatch() redirection.
| | | Will commit soon.
| I am not confident in its correctness.
|
| I am not confident in your empty argument.
We
in your empty argument.
We have had multitudes of errors becuase of functions in the wrong
instance fo the class have been called.
There is only one LyXFunc for one LyXView, how in hell could that be a
wrong instance if there is only one unique instance?
The onus is on _you_ to show
am not confident in its correctness.
| | | I am not confident in your empty argument.
| We have had multitudes of errors becuase of functions in the wrong
| instance fo the class have been called.
|
| There is only one LyXFunc for one LyXView, how in hell could that be a
| wrong instance
.
| | | | Will commit soon.
| | I am not confident in its correctness.
| | | I am not confident in your empty argument.
| We have had multitudes of errors becuase of functions in the wrong
| instance fo the class have been called.
|
| There is only one LyXFunc for one LyXView, how in hell could
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Hell? It is not very bad lamguage if you ask me. You have been using
| worse word against me. Check your archive.
Then I am sorry, I'll try to clean up my language and henceforth only
use the most civil language in my accusations.
| | The onus is
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Hell? It is not very bad lamguage if you ask me. You have been using
| worse word against me. Check your archive.
Then I am sorry, I'll try to clean up my language and henceforth only
use the most civil language in my
Abdelrazak Younes [EMAIL PROTECTED] writes:
| I have to change and you are right. Of course that's how it is.
|
| Are you ironic here or serious? I was pretty serious.
A bit of both I guess.
| A pity that you cannot come to denmark, we should get drunk (at least
| I) and then we could go
Abdelrazak Younes wrote:
You'd loose, I've been practising French boxing in my youth.
like zidane?!
lars, be careful!!
;-)
rClean(BufferView * bv)
+bool LyXFunc::ensureBufferClean(BufferView * bv)
{
Buffer & buf = *bv->buffer();
if (buf.isClean())
@@ -668,12 +666,14 @@
_(""));
if (ret == 0)
- bv->owner()->dispatch(
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| This avoids the bv->owner()->dispatch() redirection.
|
| Will commit soon.
I am not confident in its correctness.
--
Lgb
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| This avoids the bv->owner()->dispatch() redirection.
|
| Will commit soon.
I am not confident in its correctness.
I am not confident in your empty argument.
Abdel.
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | This avoids the bv->owner()->dispatch() redirection.
| > | | Will commit soon.
| > I am not confident in its correctness.
|
| I am not confident in your empty
in its correctness.
|
| I am not confident in your empty argument.
We have had multitudes of errors becuase of functions in the wrong
instance fo the class have been called.
There is only one LyXFunc for one LyXView, how in hell could that be a
wrong instance if there is only one unique instance?
bv->owner()->dispatch() redirection.
| > | > | | Will commit soon.
| > | > I am not confident in its correctness.
| > | | I am not confident in your empty argument.
| > We have had multitudes of errors becuase of functions in the wrong
| > instance fo the class have been called.
|
his avoids the bv->owner()->dispatch() redirection.
| > | > | | Will commit soon.
| > | > I am not confident in its correctness.
| > | | I am not confident in your empty argument.
| > We have had multitudes of errors becuase of functions in the wrong
| > instance fo the class h
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| "Hell"? It is not very bad lamguage if you ask me. You have been using
| worse word against me. Check your archive.
Then I am sorry, I'll try to clean up my language and henceforth only
use the most civil language in my accusations.
| > | > The
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| "Hell"? It is not very bad lamguage if you ask me. You have been using
| worse word against me. Check your archive.
Then I am sorry, I'll try to clean up my language and henceforth only
use the most civil language in my
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > I have to change and you are right. Of course that's how it is.
|
| Are you ironic here or serious? I was pretty serious.
A bit of both I guess.
| > A pity that you cannot come to denmark, we should get drunk (at least
| > I) and then we could
Abdelrazak Younes wrote:
You'd loose, I've been practising French boxing in my youth.
like zidane?!
lars, be careful!!
;-)
While re-compiling LyX, I noticed the following warning:
..\..\..\src\lyxfunc.C(218) : warning C4244: 'initializing' : conversion
from 'lyx::char_type' to 'char', possible loss of data
in
void LyXFunc::handleKeyFunc(kb_action action)
{
char c = encoded_last_key;
The problem
Abdelrazak Younes [EMAIL PROTECTED] writes:
| While re-compiling LyX, I noticed the following warning:
|
| ..\..\..\src\lyxfunc.C(218) : warning C4244: 'initializing' :
| conversion from 'lyx::char_type' to 'char', possible loss of data
|
| in
|
| void LyXFunc::handleKeyFunc(kb_action action
While re-compiling LyX, I noticed the following warning:
..\..\..\src\lyxfunc.C(218) : warning C4244: 'initializing' : conversion
from 'lyx::char_type' to 'char', possible loss of data
in
void LyXFunc::handleKeyFunc(kb_action action)
{
char c = encoded_last_key;
The problem
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| While re-compiling LyX, I noticed the following warning:
|
| ..\..\..\src\lyxfunc.C(218) : warning C4244: 'initializing' :
| conversion from 'lyx::char_type' to 'char', possible loss of data
|
| in
|
| void LyXFunc::handleKeyFunc(kb_
Nov 2003 09:50:10 -
@@ -1404,14 +1404,9 @@ void LyXFunc::dispatch(FuncRequest const
found. endl;
}
- if (view()-theLockingInset())
- view()-unlockInset(view()-theLockingInset
Alfredo Braunstein wrote:
I envisage we will use this a lot:
par.text() ? par.text() : view()-text;
and it seems a little dummy to me.
Shouldn't we have par.text(bv) anyway, thinking about multiple views?
Can I remove ParIterator::text() and substitute it with
ParIterator::text(BufferView
On Wed, Nov 05, 2003 at 11:06:19AM +0100, Alfredo Braunstein wrote:
Alfredo Braunstein wrote:
I envisage we will use this a lot:
par.text() ? par.text() : view()-text;
and it seems a little dummy to me.
Shouldn't we have par.text(bv) anyway, thinking about multiple views?
Can I
++ lyxfunc.C 5 Nov 2003 09:50:10 -
@@ -1404,14 +1404,9 @@ void LyXFunc::dispatch(FuncRequest const
<< " found." << endl;
}
- if (view()->theLockingInset())
- view()
Alfredo Braunstein wrote:
I envisage we will use this a lot:
> par.text() ? par.text() : view()->text;
and it seems a little dummy to me.
Shouldn't we have par.text(bv) anyway, thinking about multiple views?
Can I remove ParIterator::text() and substitute it with
ParIterator::text(BufferView
On Wed, Nov 05, 2003 at 11:06:19AM +0100, Alfredo Braunstein wrote:
> Alfredo Braunstein wrote:
>
> I envisage we will use this a lot:
>
> > par.text() ? par.text() : view()->text;
>
> and it seems a little dummy to me.
>
> Shouldn't we have par.text(bv) anyway, thinking about multiple views?
On Thu, Aug 07, 2003 at 02:04:18PM +0200, Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| Duplicated and/or dead code.
I do not agree with how you remove the else
It's still in now.
it is not longer obvious that the cases are exclusive... I have to
read each block
file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfunc.C,v
retrieving revision 1.475
diff -u -p -r1.475 lyxfunc.C
--- lyxfunc.C 4 Aug 2003 09:06:31 - 1.475
+++ lyxfunc.C 7 Aug 2003 09:42:01 -
@@ -859,8 +859,7 @@ void LyXFunc::dispatch(FuncRequest const
int
On Thu, Aug 07, 2003 at 01:56:41PM +0200, Andre Poenitz wrote:
But from a first glance it did not crash more often with this change
than without...
Ok I'll split it into two and let you play around with the LyXFunc.C
part...
I'd rather know what this code is supposed to do.
regards
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfunc.C,v
retrieving revision 1.475
diff -u -p -r1.475 lyxfunc.C
--- lyxfunc.C 4 Aug 2003 09:06:31 - 1.475
+++ lyxfunc.C 7 Aug 2003 09:42:01 -
@@ -876,32 +875,26 @@ void LyXFunc
On Thu, Aug 07, 2003 at 01:44:49PM +0200, Andre Poenitz wrote:
Duplicated and/or dead code.
Have you given this some *proper* testing with undo ? In particular in
various positions of tables etc. ?
john
On Thu, Aug 07, 2003 at 03:20:19PM +0200, Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| On Thu, Aug 07, 2003 at 02:04:18PM +0200, Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| Duplicated and/or dead code.
I do not agree with how you
On Thu, Aug 07, 2003 at 02:04:18PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | Duplicated and/or dead code.
>
> I do not agree with how you remove the else
It's still in now.
> it is not longer obvious that the cases are exclusive... I have to
> read
file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfunc.C,v
retrieving revision 1.475
diff -u -p -r1.475 lyxfunc.C
--- lyxfunc.C 4 Aug 2003 09:06:31 - 1.475
+++ lyxfunc.C 7 Aug 2003 09:42:01 -
@@ -859,8 +859,7 @@ void LyXFunc::dispatch(FuncRequest const
int
On Thu, Aug 07, 2003 at 01:56:41PM +0200, Andre Poenitz wrote:
> But from a first glance it did not crash more often with this change
> than without...
>
> Ok I'll split it into two and let you play around with the LyXFunc.C
> part...
I'd rather know what this code is supposed to do.
32 +875,26 @@ void LyXFunc::dispatch(FuncRequest const
goto exit_with_message;
}
- // Undo/Redo is a bit tricky for insets.
- if (action == LFUN_UNDO) {
-
On Thu, Aug 07, 2003 at 01:44:49PM +0200, Andre Poenitz wrote:
> Duplicated and/or dead code.
Have you given this some *proper* testing with undo ? In particular in
various positions of tables etc. ?
john
On Thu, Aug 07, 2003 at 03:20:19PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Thu, Aug 07, 2003 at 02:04:18PM +0200, Lars Gullik Bjønnes wrote:
> >> Andre Poenitz <[EMAIL PROTECTED]> writes:
> >>
> >> | Duplicated and/or dead code.
> >>
> >> I do not
I am happily removing stuff like:
case LFUN_REF_INSERT:
code = Inset::REF_CODE;
break;
Should I replace it with something like:
case LFUN_DIALOG_SHOW_NEW_INSET:
if (ev.argument == citation)
code =
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus I am happily removing stuff like: case LFUN_REF_INSERT: code =
Angus Inset::REF_CODE; break;
Angus Should I replace it with something like: case
Angus LFUN_DIALOG_SHOW_NEW_INSET: if (ev.argument == citation) code
Angus = Inset::CITE_CODE;
On Fri, Mar 07, 2003 at 03:32:06PM +, Angus Leeming wrote:
I am happily removing stuff like:
case LFUN_REF_INSERT:
code = Inset::REF_CODE;
break;
Should I replace it with something like:
case LFUN_DIALOG_SHOW_NEW_INSET:
Jean-Marc Lasgouttes wrote:
Angus What does the function do?
The idea is to be able to say whether it is legal to use
LFUN_DIALOG_SHOW_NEW_INSET at some place. Therefore we need the
relevant Inset::Code in order to call insetAllowed(code). So we want
to get the code of the new inset from
I am happily removing stuff like:
case LFUN_REF_INSERT:
code = Inset::REF_CODE;
break;
Should I replace it with something like:
case LFUN_DIALOG_SHOW_NEW_INSET:
if (ev.argument == "citation")
code =
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> I am happily removing stuff like: case LFUN_REF_INSERT: code =
Angus> Inset::REF_CODE; break;
Angus> Should I replace it with something like: case
Angus> LFUN_DIALOG_SHOW_NEW_INSET: if (ev.argument == "citation") code
Angus> =
On Fri, Mar 07, 2003 at 03:32:06PM +, Angus Leeming wrote:
> I am happily removing stuff like:
>
> case LFUN_REF_INSERT:
> code = Inset::REF_CODE;
> break;
>
> Should I replace it with something like:
> case LFUN_DIALOG_SHOW_NEW_INSET:
>
Jean-Marc Lasgouttes wrote:
> Angus> What does the function do?
>
> The idea is to be able to say whether it is legal to use
> LFUN_DIALOG_SHOW_NEW_INSET at some place. Therefore we need the
> relevant Inset::Code in order to call insetAllowed(code). So we want
> to get the code of the new inset
/wanted? Is their an implementation?
Angus
-- Forwarded Message --
Subject: LyXFunc/LyXAction
Date: 13 Oct 2000 15:48:08 +0200
From: [EMAIL PROTECTED] (Lars Gullik Bjønnes)
To: [EMAIL PROTECTED]
We should make a way to ensure that LyXFunc are called with the
correct number
(123);
This could easily be used for the FuncSlot.
Lgb
---
and I also found Allan's follow up
-- Forwarded Message --
Subject: Re: stream_cast and Re: LyXFunc/LyXAction
Date: Thu, 19 Oct 2000 16:49:54 +1000 (GMT+1000
On Fri, Aug 16, 2002 at 06:26:35PM +0100, Angus Leeming wrote:
-- Forwarded Message --
Subject: LyXFunc/LyXAction
Date: 13 Oct 2000 15:48:08 +0200
From: [EMAIL PROTECTED] (Lars Gullik Bjønnes)
To: [EMAIL PROTECTED]
We should make a way to ensure that LyXFunc are called
On Fri, Aug 16, 2002 at 06:31:24PM +0100, Angus Leeming wrote:
This sounds like xtl to me. Would FuncRequest not benefit from this?
Overkill IMNSHO.
_Please_ let's see how far we come using the int,int,button,string
approach.
unscrambling of stringifications...
We certainly do not do much
/wanted? Is their an implementation?
Angus
-- Forwarded Message --
Subject: LyXFunc/LyXAction
Date: 13 Oct 2000 15:48:08 +0200
From: [EMAIL PROTECTED] (Lars Gullik Bjønnes)
To: [EMAIL PROTECTED]
We should make a way to ensure that LyXFunc are called with the
correct number
string:
string a = stream_cast<string, int>(123);
This could easily be used for the FuncSlot.
Lgb
---
and I also found Allan's follow up
-- Forwarded Message --
Subject: Re: stream_cast<> and Re: LyXF
On Fri, Aug 16, 2002 at 06:26:35PM +0100, Angus Leeming wrote:
> -- Forwarded Message --
>
> Subject: LyXFunc/LyXAction
> Date: 13 Oct 2000 15:48:08 +0200
> From: [EMAIL PROTECTED] (Lars Gullik Bjønnes)
> To: [EMAIL PROTECTED]
>
> We should make a wa
On Fri, Aug 16, 2002 at 06:31:24PM +0100, Angus Leeming wrote:
> This sounds like xtl to me. Would FuncRequest not benefit from this?
Overkill IMNSHO.
_Please_ let's see how far we come using the int,int,button,string
approach.
> unscrambling of stringifications...
We certainly do not do
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 name.
| The problem with ii) as I read it is O(n
| 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 name
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
1 - 100 of 302 matches
Mail list logo
