Andre Poenitz <[EMAIL PROTECTED]> writes:
| > Mathed should _now_ play with what is present. Mathed should not
| > impose any huge changes to the the rest of LyX at _this_ stage.
|
| Have you looked at the BufferView_pimpl.C change in mathed93.diff?
|
|
| I am moving the 50 LFUN_MATH* lines fr
> Mathed should _now_ play with what is present. Mathed should not
> impose any huge changes to the the rest of LyX at _this_ stage.
Have you looked at the BufferView_pimpl.C change in mathed93.diff?
I am moving the 50 LFUN_MATH* lines from the big switch into mathed.
I have removed two #inclu
Andre Poenitz <[EMAIL PROTECTED]> writes:
| > Well what you're hiding is the creation of an inset and inserting it in
| > BufferViews LyXText, I don't think this is really mathed stuff, is it?
|
| Since it needs to call the inset's constructors (and do things like "don't
| start with numbered di
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Putting everything in the big switch _and doing part of the work there_
| is stupid. I don't want mathed to participate in such stupidities...
Use the main switch for now, all this will change for _all_ dispatch
methods later not just for mathed.
| >
> Sure and as soon as we can register lyx-funcs to the Dispatcher (or
> LyXAction then we all will do as you, but in the time being we should
> wait until Lars has the time to do it and concentrate on fixing stuff
> instead of inserting lot's and lot's of new stuff or shuffle stuff around
> which
On 05-Jul-2001 Andre Poenitz wrote:
> Sure. But I'd rather call it
>
> struct MathInitializer()
> {
> MathInitializer() {
> big_lyxfunc_switch->register(LFUN_MATH_INSERT, my_math_insert);
> big_lyxfunc_switch->register(LFUN_MATH_DISPLAY, my_math_display);
> ...
> }
> Well what you're hiding is the creation of an inset and inserting it in
> BufferViews LyXText, I don't think this is really mathed stuff, is it?
Since it needs to call the inset's constructors (and do things like "don't
start with numbered displayed formalae") it certainly is.
> Then you proba
On 05-Jul-2001 Andre Poenitz wrote:
> This sounds suspiciously like admitting that you criticized the patch
> before reading it.
I did yes :)
> Putting everything in the big switch _and doing part of the work there_
> is stupid. I don't want mathed to participate in such stupidities...
bla, b
> > Would you be satified if I simply duplicated the code?
>
> Well I had a look at your patch and I really think you should just let it
> there!
This sounds suspiciously like admitting that you criticized the patch
before reading it.
Maybe I am overreacting a bit currently...
> This is only t
On 05-Jul-2001 Andre Poenitz wrote:
> open_new_inset uses insertInset.
>
> Would you be satified if I simply duplicated the code?
Well I had a look at your patch and I really think you should just let it
there! This is only the creation of the outermost Inset and all this stuff
is there, or sh
> Why do you need that? I have insets in insets without the need to use
> that function. Did you have a look at the functions InsetInsertAllowed
> and insertInset()?
open_new_inset uses insertInset.
Would you be satified if I simply duplicated the code?
Andre'
--
André Pönitz
> On 04-Jul-2001 Andre Poenitz wrote:
> >
> > If BufferViewPimpl::open_new_inset were publicly available in
> > BufferView, I could move all the MATH_* action handling from
> > BufferView_pimpl.C to mathed/formula.C
> >
> > I think this would benefit encapsulation...
>
> Why do you need that?
On 04-Jul-2001 Andre Poenitz wrote:
>
> If BufferViewPimpl::open_new_inset were publicly available in
> BufferView, I could move all the MATH_* action handling from
> BufferView_pimpl.C to mathed/formula.C
>
> I think this would benefit encapsulation...
Why do you need that? I have insets in i
13 matches
Mail list logo
