Abdelrazak Younes wrote:
For someone who knows the intricacy of GUII perhaps. I've done a lot of
GUI programming and I don't share at all your opinion. Requiring someone
to learn Qt and also to learn LyX GUII architecture is too much IMO and
that is the very reason why we don't have so much
Andre Poenitz wrote:
On Tue, Sep 25, 2007 at 11:28:41AM +0200, Georg Baum wrote:
But why would you want a second entry point? Until now I see only
theoretical advantages of not using the dispatch mechanism (it is the
same app so it ought to use a direct API and not some string stuff).
Georg Baum wrote:
Abdelrazak Younes wrote:
For someone who knows the intricacy of GUII perhaps. I've done a lot of
GUI programming and I don't share at all your opinion. Requiring someone
to learn Qt and also to learn LyX GUII architecture is too much IMO and
that is the very reason why we
Abdelrazak Younes [EMAIL PROTECTED] writes:
I think so yes, by calculating and storing real paragraph height of
the whole document when it is first loaded. Then each new full update
metrics call will update the stored height of the recalculated
paragraph metrics. I'd like to finish correcting
Abdelrazak Younes wrote:
> For someone who knows the intricacy of GUII perhaps. I've done a lot of
> GUI programming and I don't share at all your opinion. Requiring someone
> to learn Qt and also to learn LyX GUII architecture is too much IMO and
> that is the very reason why we don't have so
Andre Poenitz wrote:
> On Tue, Sep 25, 2007 at 11:28:41AM +0200, Georg Baum wrote:
>> But why would you want a second entry point? Until now I see only
>> theoretical advantages of not using the dispatch mechanism ("it is the
>> same app so it ought to use a direct API and not some string
Georg Baum wrote:
Abdelrazak Younes wrote:
For someone who knows the intricacy of GUII perhaps. I've done a lot of
GUI programming and I don't share at all your opinion. Requiring someone
to learn Qt and also to learn LyX GUII architecture is too much IMO and
that is the very reason why we
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> I think so yes, by calculating and storing real paragraph height of
> the whole document when it is first loaded. Then each new full update
> metrics call will update the stored height of the recalculated
> paragraph metrics. I'd like to finish
Andre Poenitz wrote:
Why do we need the dispatch mechanism for calls into the kernel?
It is not needed, but it simplifies the code. For example, take the label
dialog: Renaming a label is more than just changing some inset parameter,
because some references might be changed, and some global
Abdelrazak Younes wrote:
This is of course not needed but there are some fundamentalist over here
:-).
Nonsense. This discussion is not about fundamentalism (not even with
smileys), it is about very practical advantages/disadvantages of different
approaches.
Georg
Andre Poenitz wrote:
How would you have rated the previous GUII architecture?
I would not have implemented it that way, but I never had big problems with
it. Is was in my experience far less a problem than you always made it
appear. Surely implementing a new inset required too many classes, but
Georg Baum wrote:
Abdelrazak Younes wrote:
This is of course not needed but there are some fundamentalist over here
:-).
Nonsense. This discussion is not about fundamentalism (not even with
smileys), it is about very practical advantages/disadvantages of different
approaches.
Well, last
Georg Baum wrote:
Andre Poenitz wrote:
How would you have rated the previous GUII architecture?
I would not have implemented it that way, but I never had big problems with
it. Is was in my experience far less a problem than you always made it
appear. Surely implementing a new inset required
Abdelrazak Younes wrote:
Georg Baum wrote:
Where is the metrics/draw concept documented? Who
understands the current state?
Me. And I've tried to document this mess while doing it.
Just to put things in perspective this page says I have a comment/code
ratio of 24%:
On Tue, Sep 25, 2007 at 11:28:41AM +0200, Georg Baum wrote:
Andre Poenitz wrote:
Why do we need the dispatch mechanism for calls into the kernel?
It is not needed, but it simplifies the code. For example, take the label
dialog: Renaming a label is more than just changing some inset
On Tue, Sep 25, 2007 at 11:36:38AM +0200, Georg Baum wrote:
Andre Poenitz wrote:
How would you have rated the previous GUII architecture?
I would not have implemented it that way, but I never had big problems with
it. Is was in my experience far less a problem than you always made it
On Tue, Sep 25, 2007 at 11:41:48AM +0200, Abdelrazak Younes wrote:
Georg Baum wrote:
Abdelrazak Younes wrote:
This is of course not needed but there are some fundamentalist over here
:-).
Nonsense. This discussion is not about fundamentalism (not even with
smileys), it is about very
Andre Poenitz wrote:
> Why do we need the dispatch mechanism for calls into the kernel?
It is not needed, but it simplifies the code. For example, take the label
dialog: Renaming a label is more than just changing some inset parameter,
because some references might be changed, and some global
Abdelrazak Younes wrote:
> This is of course not needed but there are some fundamentalist over here
> :-).
Nonsense. This discussion is not about fundamentalism (not even with
smileys), it is about very practical advantages/disadvantages of different
approaches.
Georg
Andre Poenitz wrote:
> How would you have rated the previous GUII architecture?
I would not have implemented it that way, but I never had big problems with
it. Is was in my experience far less a problem than you always made it
appear. Surely implementing a new inset required too many classes,
Georg Baum wrote:
Abdelrazak Younes wrote:
This is of course not needed but there are some fundamentalist over here
:-).
Nonsense. This discussion is not about fundamentalism (not even with
smileys), it is about very practical advantages/disadvantages of different
approaches.
Well, last
Georg Baum wrote:
Andre Poenitz wrote:
How would you have rated the previous GUII architecture?
I would not have implemented it that way, but I never had big problems with
it. Is was in my experience far less a problem than you always made it
appear. Surely implementing a new inset required
Abdelrazak Younes wrote:
Georg Baum wrote:
Where is the metrics/draw concept documented? Who
understands the current state?
Me. And I've tried to document this mess while doing it.
Just to put things in perspective this page says I have a comment/code
ratio of 24%:
On Tue, Sep 25, 2007 at 11:28:41AM +0200, Georg Baum wrote:
> Andre Poenitz wrote:
>
> > Why do we need the dispatch mechanism for calls into the kernel?
>
> It is not needed, but it simplifies the code. For example, take the label
> dialog: Renaming a label is more than just changing some inset
On Tue, Sep 25, 2007 at 11:36:38AM +0200, Georg Baum wrote:
> Andre Poenitz wrote:
>
> > How would you have rated the previous GUII architecture?
>
> I would not have implemented it that way, but I never had big problems with
> it. Is was in my experience far less a problem than you always made
On Tue, Sep 25, 2007 at 11:41:48AM +0200, Abdelrazak Younes wrote:
> Georg Baum wrote:
> >Abdelrazak Younes wrote:
> >
> >>This is of course not needed but there are some fundamentalist over here
> >>:-).
> >
> >Nonsense. This discussion is not about fundamentalism (not even with
> >smileys), it
Richard Heck wrote:
In the end, I don't think this will be needed. But yes, the
serialization here is a hassle, and it's sheer luck that it isn't a
problem.
How would an optimal/a better solution look like in your opinion?
[Serious question]
Well, there are advantages to the
Richard Heck wrote:
In the end, I don't think this will be needed. But yes, the
serialization here is a hassle, and it's sheer luck that it isn't a
problem.
How would an optimal/a better solution look like in your opinion?
[Serious question]
Well, there are advantages to the
Georg Baum wrote:
If you had a serialization that
would not require to implement these wrapper classes for new insets and
that would 'just work' without additional effort (for example by using the
insets read() and write() methods directly), then I think this would be
ideal.
That would be a
Abdelrazak Younes a écrit :
Georg Baum wrote:
If you had a serialization that
would not require to implement these wrapper classes for new insets and
that would 'just work' without additional effort (for example by
using the
insets read() and write() methods directly), then I think this would
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes a écrit :
Georg Baum wrote:
If you had a serialization that
would not require to implement these wrapper classes for new insets and
that would 'just work' without additional effort (for example by
using the
insets read() and write() methods
Abdelrazak Younes wrote:
That would be a good first step indeed. But I personally don't think the
hypothetical benefit of using inset globs in the lyxserver is worth
it. I mean, I agree this would be nice to have, this kind of thing is
even necessary for simulation programs where you
On Mon, 24 Sep 2007, Abdelrazak Younes wrote:
Serialization allows us to have the paragraph-params-apply lfun, for
example, which allow to bind any aspect of paragraph settings to a key
or icon.
No, what you are talking about is the frontend - core communication,
which I agree should be
[EMAIL PROTECTED] wrote:
On Mon, 24 Sep 2007, Abdelrazak Younes wrote:
Serialization allows us to have the paragraph-params-apply lfun, for
example, which allow to bind any aspect of paragraph settings to a key
or icon.
No, what you are talking about is the frontend - core communication,
Abdelrazak Younes [EMAIL PROTECTED] writes:
No, what you are talking about is the frontend - core communication,
which I agree should be kept working via LFUN. But we don't need any
serialization to do that, just a well defined protocol.
Right now, we have a copy of the current ParagraphParam
Georg Baum wrote:
Richard Heck wrote
Well, there are advantages to the serialization. I can't remember what
they are ;-), but I have seen them.
It is a type question. Passing InsetFooParams directly would mean that the
dispatch mechanism needs to know about all these types, or rather you
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
No, what you are talking about is the frontend - core communication,
which I agree should be kept working via LFUN. But we don't need any
serialization to do that, just a well defined protocol.
Right now, we have a copy
Richard Heck wrote:
Not that I have time to do this now, but if you had any further ideas
about this, I'd love to hear them.
No, I don't have further ideas.
Georg
On Mon, Sep 24, 2007 at 09:23:01AM +0200, Georg Baum wrote:
Richard Heck wrote:
In the end, I don't think this will be needed. But yes, the
serialization here is a hassle, and it's sheer luck that it isn't a
problem.
How would an optimal/a better solution look like in your
On Mon, Sep 24, 2007 at 09:57:31AM +0200, Abdelrazak Younes wrote:
Georg Baum wrote:
If you had a serialization that
would not require to implement these wrapper classes for new insets and
that would 'just work' without additional effort (for example by using the
insets read() and write()
On Mon, Sep 24, 2007 at 10:55:13AM +0200, Jean-Marc Lasgouttes wrote:
Abdelrazak Younes a écrit :
Georg Baum wrote:
If you had a serialization that
would not require to implement these wrapper classes for new insets and
that would 'just work' without additional effort (for example by
using
On Mon, Sep 24, 2007 at 11:04:39AM +0200, Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes a écrit :
Georg Baum wrote:
If you had a serialization that
would not require to implement these wrapper classes for new insets and
that would 'just work' without additional
On Mon, Sep 24, 2007 at 12:17:38PM +0200, Georg Baum wrote:
Abdelrazak Younes wrote:
That would be a good first step indeed. But I personally don't think the
hypothetical benefit of using inset globs in the lyxserver is worth
it. I mean, I agree this would be nice to have, this kind of
On Mon, Sep 24, 2007 at 01:02:54PM +0200, [EMAIL PROTECTED] wrote:
On Mon, 24 Sep 2007, Abdelrazak Younes wrote:
Serialization allows us to have the paragraph-params-apply lfun, for
example, which allow to bind any aspect of paragraph settings to a key
or icon.
No, what you are talking
On Mon, 24 Sep 2007, Abdelrazak Younes wrote:
Inset defines its own undocumented protocol. We are not talking about a
network protocol or something complicated, we just need a well defined
syntax for the LFUN, for example:
LFUN_XXX /command1 option1a option1b /command2 option2a option2b ...
Andre Poenitz wrote:
On Mon, Sep 24, 2007 at 11:04:39AM +0200, Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes a écrit :
Georg Baum wrote:
If you had a serialization that
would not require to implement these wrapper classes for new insets and
that would 'just work'
[EMAIL PROTECTED] wrote:
On Mon, 24 Sep 2007, Abdelrazak Younes wrote:
Inset defines its own undocumented protocol. We are not talking about
a network protocol or something complicated, we just need a well
defined syntax for the LFUN, for example:
LFUN_XXX /command1 option1a option1b
Andre Poenitz wrote:
On Mon, Sep 24, 2007 at 09:23:01AM +0200, Georg Baum wrote:
Richard Heck wrote:
In the end, I don't think this will be needed. But yes, the
serialization here is a hassle, and it's sheer luck that it isn't a
problem.
How would an optimal/a better solution look like
On Mon, Sep 24, 2007 at 11:03:56PM +0200, Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
On Mon, 24 Sep 2007, Abdelrazak Younes wrote:
Inset defines its own undocumented protocol. We are not talking about
a network protocol or something complicated, we just need a well
defined syntax
Andre Poenitz wrote:
On Mon, Sep 24, 2007 at 12:17:38PM +0200, Georg Baum wrote:
Abdelrazak Younes wrote:
That would be a good first step indeed. But I personally don't think the
hypothetical benefit of using inset globs in the lyxserver is worth
it. I mean, I agree this would be nice to
On Mon, Sep 24, 2007 at 10:34:46PM +0200, [EMAIL PROTECTED] wrote:
On Mon, 24 Sep 2007, Abdelrazak Younes wrote:
Inset defines its own undocumented protocol. We are not talking about a
network protocol or something complicated, we just need a well defined
syntax for the LFUN, for example:
Richard Heck wrote:
In the end, I don't think this will be needed. But yes, the
serialization here is a hassle, and it's sheer luck that it isn't a
problem.
How would an optimal/a better solution look like in your opinion?
[Serious question]
Well, there are advantages to the
Richard Heck wrote:
>>> In the end, I don't think this will be needed. But yes, the
>>> serialization here is a hassle, and it's sheer luck that it isn't a
>>> problem.
>>>
>> How would an optimal/a better solution look like in your opinion?
>> [Serious question]
>>
> Well, there are
Georg Baum wrote:
If you had a serialization that
would not require to implement these wrapper classes for new insets and
that would 'just work' without additional effort (for example by using the
insets read() and write() methods directly), then I think this would be
ideal.
That would be a
Abdelrazak Younes a écrit :
Georg Baum wrote:
If you had a serialization that
would not require to implement these wrapper classes for new insets and
that would 'just work' without additional effort (for example by
using the
insets read() and write() methods directly), then I think this would
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes a écrit :
Georg Baum wrote:
If you had a serialization that
would not require to implement these wrapper classes for new insets and
that would 'just work' without additional effort (for example by
using the
insets read() and write() methods
Abdelrazak Younes wrote:
> That would be a good first step indeed. But I personally don't think the
> hypothetical benefit of using "inset globs" in the lyxserver is worth
> it. I mean, I agree this would be nice to have, this kind of thing is
> even necessary for simulation programs where you
On Mon, 24 Sep 2007, Abdelrazak Younes wrote:
Serialization allows us to have the paragraph-params-apply lfun, for
example, which allow to bind any aspect of paragraph settings to a key
or icon.
No, what you are talking about is the frontend -> core communication,
which I agree should be
[EMAIL PROTECTED] wrote:
On Mon, 24 Sep 2007, Abdelrazak Younes wrote:
Serialization allows us to have the paragraph-params-apply lfun, for
example, which allow to bind any aspect of paragraph settings to a key
or icon.
No, what you are talking about is the frontend -> core communication,
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> No, what you are talking about is the frontend -> core communication,
> which I agree should be kept working via LFUN. But we don't need any
> serialization to do that, just a well defined protocol.
> Right now, we have a copy of the current
Georg Baum wrote:
Richard Heck wrote
Well, there are advantages to the serialization. I can't remember what
they are ;-), but I have seen them.
It is a type question. Passing InsetFooParams directly would mean that the
dispatch mechanism needs to know about all these types, or rather you
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
No, what you are talking about is the frontend -> core communication,
which I agree should be kept working via LFUN. But we don't need any
serialization to do that, just a well defined protocol.
Right now, we have a
Richard Heck wrote:
> Not that I have time to do this now, but if you had any further ideas
> about this, I'd love to hear them.
No, I don't have further ideas.
Georg
On Mon, Sep 24, 2007 at 09:23:01AM +0200, Georg Baum wrote:
> Richard Heck wrote:
>
> >>> In the end, I don't think this will be needed. But yes, the
> >>> serialization here is a hassle, and it's sheer luck that it isn't a
> >>> problem.
> >>>
> >> How would an optimal/a better solution
On Mon, Sep 24, 2007 at 09:57:31AM +0200, Abdelrazak Younes wrote:
> Georg Baum wrote:
> >If you had a serialization that
> >would not require to implement these wrapper classes for new insets and
> >that would 'just work' without additional effort (for example by using the
> >insets read() and
On Mon, Sep 24, 2007 at 10:55:13AM +0200, Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes a écrit :
> >Georg Baum wrote:
> >>If you had a serialization that
> >>would not require to implement these wrapper classes for new insets and
> >>that would 'just work' without additional effort (for example
On Mon, Sep 24, 2007 at 11:04:39AM +0200, Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes wrote:
> >Abdelrazak Younes a écrit :
> >>Georg Baum wrote:
> >>>If you had a serialization that
> >>>would not require to implement these wrapper classes for new insets and
> >>>that would 'just work'
On Mon, Sep 24, 2007 at 12:17:38PM +0200, Georg Baum wrote:
> Abdelrazak Younes wrote:
>
> > That would be a good first step indeed. But I personally don't think the
> > hypothetical benefit of using "inset globs" in the lyxserver is worth
> > it. I mean, I agree this would be nice to have, this
On Mon, Sep 24, 2007 at 01:02:54PM +0200, [EMAIL PROTECTED] wrote:
> On Mon, 24 Sep 2007, Abdelrazak Younes wrote:
>
> >> Serialization allows us to have the paragraph-params-apply lfun, for
> >> example, which allow to bind any aspect of paragraph settings to a key
> >> or icon.
> >
> >No, what
On Mon, 24 Sep 2007, Abdelrazak Younes wrote:
Inset defines its own undocumented protocol. We are not talking about a
network protocol or something complicated, we just need a well defined
syntax for the LFUN, for example:
LFUN_XXX /command1 option1a option1b /command2 option2a option2b ...
Andre Poenitz wrote:
On Mon, Sep 24, 2007 at 11:04:39AM +0200, Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes a écrit :
Georg Baum wrote:
If you had a serialization that
would not require to implement these wrapper classes for new insets and
that would 'just work'
[EMAIL PROTECTED] wrote:
On Mon, 24 Sep 2007, Abdelrazak Younes wrote:
Inset defines its own undocumented protocol. We are not talking about
a network protocol or something complicated, we just need a well
defined syntax for the LFUN, for example:
LFUN_XXX /command1 option1a option1b
Andre Poenitz wrote:
On Mon, Sep 24, 2007 at 09:23:01AM +0200, Georg Baum wrote:
Richard Heck wrote:
In the end, I don't think this will be needed. But yes, the
serialization here is a hassle, and it's sheer luck that it isn't a
problem.
How would an optimal/a better solution look like
On Mon, Sep 24, 2007 at 11:03:56PM +0200, Abdelrazak Younes wrote:
> [EMAIL PROTECTED] wrote:
> >On Mon, 24 Sep 2007, Abdelrazak Younes wrote:
> >
> >>Inset defines its own undocumented protocol. We are not talking about
> >>a network protocol or something complicated, we just need a well
>
Andre Poenitz wrote:
On Mon, Sep 24, 2007 at 12:17:38PM +0200, Georg Baum wrote:
Abdelrazak Younes wrote:
That would be a good first step indeed. But I personally don't think the
hypothetical benefit of using "inset globs" in the lyxserver is worth
it. I mean, I agree this would be nice to
On Mon, Sep 24, 2007 at 10:34:46PM +0200, [EMAIL PROTECTED] wrote:
> On Mon, 24 Sep 2007, Abdelrazak Younes wrote:
>
> >Inset defines its own undocumented protocol. We are not talking about a
> >network protocol or something complicated, we just need a well defined
> >syntax for the LFUN, for
On Fri, Sep 21, 2007 at 11:59:56AM +0200, Georg Baum wrote:
Richard Heck wrote:
The change should be fairly simple, both in the code and in lyx2lyx:
It's mostly a matter of file format, not so much of internal
representation. Internal code concerned with writing and reading will be
all
Andre Poenitz wrote:
The bad news is that this change will require one controller class for each
inset. Currently there is only one command controller, used by all command
insets. That is the only reason I did not do this change already during the
InsetCommandParams rewrite.
So again an
On Sun, Sep 23, 2007 at 03:57:52PM -0400, Richard Heck wrote:
Andre Poenitz wrote:
The bad news is that this change will require one controller class for
each
inset. Currently there is only one command controller, used by all command
insets. That is the only reason I did not do this change
In the end, I don't think this will be needed. But yes, the
serialization here is a hassle, and it's sheer luck that it isn't a problem.
How would an optimal/a better solution look like in your opinion?
[Serious question]
Well, there are advantages to the serialization. I can't
On Fri, Sep 21, 2007 at 11:59:56AM +0200, Georg Baum wrote:
> Richard Heck wrote:
>
> > The change should be fairly simple, both in the code and in lyx2lyx:
> > It's mostly a matter of file format, not so much of internal
> > representation. Internal code concerned with writing and reading will
Andre Poenitz wrote:
The bad news is that this change will require one controller class for each
inset. Currently there is only one command controller, used by all command
insets. That is the only reason I did not do this change already during the
InsetCommandParams rewrite.
So again an
On Sun, Sep 23, 2007 at 03:57:52PM -0400, Richard Heck wrote:
> Andre Poenitz wrote:
> >>The bad news is that this change will require one controller class for
> >>each
> >>inset. Currently there is only one command controller, used by all command
> >>insets. That is the only reason I did not do
In the end, I don't think this will be needed. But yes, the
serialization here is a hassle, and it's sheer luck that it isn't a problem.
How would an optimal/a better solution look like in your opinion?
[Serious question]
Well, there are advantages to the serialization. I can't
Richard Heck wrote:
OK, thanks. I'd certainly have overlooked that, at least initially. I
think it is possible to get the mailer to do the work, though. This
involves getting some consistency between dialog names and inset names,
which isn't exactly wonderful, but I think it will be OK, at
Richard Heck wrote:
> OK, thanks. I'd certainly have overlooked that, at least initially. I
> think it is possible to get the mailer to do the work, though. This
> involves getting some consistency between dialog names and inset names,
> which isn't exactly wonderful, but I think it will be OK,
Juergen Spitzmueller [EMAIL PROTECTED] writes:
Fonts, btw, should go down the same route eventually (however, we should
take care that we don't end up with 173 configuration files).
What do you mean?
What I'm suggesting is that command insets should behave the same way.
So we'd have:
Jean-Marc Lasgouttes wrote:
Fonts, btw, should go down the same route eventually (however, we should
take care that we don't end up with 173 configuration files).
What do you mean?
The fonts we support are hardcoded in LyX. This means that new fonts (such
as the TeXGyre fonts) need to be
Juergen Spitzmueller [EMAIL PROTECTED] writes:
The fonts we support are hardcoded in LyX. This means that new fonts (such
as the TeXGyre fonts) need to be added to BufferParams::loadFonts (which
always entails a file format change currently).
OK, you mean font packages. Yes, something could
Jean-Marc Lasgouttes wrote:
Example I found yesterday and did not report yet: when using almost EC
fonts, I need to use aeguill.sty too if I want to use french
guillemets (otherwise all I get is black squares). Either we always
load it (but I suspect there is a reason why the ae style file
Jean-Marc Lasgouttes wrote:
Example I found yesterday and did not report yet: when using almost EC
fonts, I need to use aeguill.sty too if I want to use french
guillemets (otherwise all I get is black squares). Either we always
load it (but I suspect there is a reason why the ae style file
On Friday 21 September 2007 10:28:06 Jean-Marc Lasgouttes wrote:
OK, you mean font packages. Yes, something could be done, but some
hardcoding is often necessary.
Example I found yesterday and did not report yet: when using almost EC
fonts, I need to use aeguill.sty too if I want to use
Richard Heck wrote:
The change should be fairly simple, both in the code and in lyx2lyx:
It's mostly a matter of file format, not so much of internal
representation. Internal code concerned with writing and reading will be
all that changes. This will significantly simplify factory.cpp's
Juergen Spitzmueller wrote:
Richard Heck wrote:
I'm looking now at re-working some of the code surrounding InsetCommand
and its derivatives. The motivation here is, ultimately, BibLaTeX
support
\begin{praise}
You're going to make me blush.
Richard
Jean-Marc Lasgouttes wrote:
What I'm suggesting is that command insets should behave the same way.
So we'd have:
\begin_inset Citation
command citet
key etctec
\end_inset
More or less.
This looks reasonable, in general.
A question: how will the parser know that this
Georg Baum wrote:
The bad news is that this change will require one controller class for each
inset. Currently there is only one command controller, used by all command
insets. That is the only reason I did not do this change already during the
InsetCommandParams rewrite.
Sorry, could you
Richard Heck wrote:
Georg Baum wrote:
The bad news is that this change will require one controller class for
each inset. Currently there is only one command controller, used by all
command insets. That is the only reason I did not do this change already
during the InsetCommandParams rewrite.
Georg Baum wrote:
Richard Heck wrote:
Georg Baum wrote:
The bad news is that this change will require one controller class for
each inset. Currently there is only one command controller, used by all
command insets. That is the only reason I did not do this change already
during the
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
> Fonts, btw, should go down the same route eventually (however, we should
> take care that we don't end up with 173 configuration files).
What do you mean?
>> What I'm suggesting is that command insets should behave the same way.
>> So we'd
Jean-Marc Lasgouttes wrote:
>> Fonts, btw, should go down the same route eventually (however, we should
>> take care that we don't end up with 173 configuration files).
>
> What do you mean?
The fonts we support are hardcoded in LyX. This means that new fonts (such
as the TeXGyre fonts) need to
1 - 100 of 118 matches
Mail list logo
