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 corre
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 don
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").
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 mu
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
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 i
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
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%:
http://www.ohloh.net/
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 t
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 tim
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
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:
> 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 lis
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 ex
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 hav
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
> >>def
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 i
[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 /comman
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' with
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 ...
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 y
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 k
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
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 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 wri
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
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
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 cop
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 n
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 Paragrap
[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,
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 k
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 def
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 direct
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
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 goo
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 advan
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 serializa
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 remember
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 t
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 ins
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
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
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 Ins
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
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 expl
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
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
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
>
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 <>
> 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 doe
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 <>
> 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 doe
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 <
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 cou
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
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:
On Thu, Sep 20, 2007 at 03:47:05PM -0400, Richard Heck wrote:
...
> Here's an early question. InsetCommand insets are stored in LyX files
> like this:
>\begin_inset LatexCommand citet
>key etcetc
>\end_inset
> more or less.
...
> What I'm suggesting is that command insets should
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'll make me very happy with this.
> You get the same problem with BibLaTeX. Proper support for BibLaTeX w
On Thu, Sep 20, 2007 at 03:47:05PM -0400, Richard Heck wrote:
> [...] Comments?
Sounds like a plan.
Andre'
I'm looking now at re-working some of the code surrounding InsetCommand
and its derivatives. The motivation here is, ultimately, BibLaTeX
support and the possibility of user-definable---or, at least,
configurable---command insets, like InsetFlex provides for text insets.
In order for that to
59 matches
Mail list logo
