Andre Poenitz wrote:
On Thu, Sep 28, 2006 at 12:39:57PM +0200, Abdelrazak Younes wrote:
Again, I prefer to have one single point of access for all global
variable. The logical place to put them is in Application. When it's
written "theApp->XXX", I know that this is a unique instance variable.
On Thu, Sep 28, 2006 at 10:08:54AM +0200, Abdelrazak Younes wrote:
> IMO, it is much cleaner this way. I really dislike these global
> variable. But the bigger benefit (for me) is that I will know exactly
> what needs more cleanups in the kernel (src/*).
>
> >We now get a class (and header
> >fi
On Thu, Sep 28, 2006 at 09:40:38AM +0200, Abdelrazak Younes wrote:
> >But keep in mind that to reach real encapsulation in the end _in theory_
> >src/*.[Ch] should not contain any #include "frontends/*".
>
> Yes, that exactly my plan. But hey I have to start somewhere ;-)
I know. And note that I
On Thu, Sep 28, 2006 at 12:39:57PM +0200, Abdelrazak Younes wrote:
> Again, I prefer to have one single point of access for all global
> variable. The logical place to put them is in Application. When it's
> written "theApp->XXX", I know that this is a unique instance variable.
> "XXX" alone doe
Abdelrazak Younes wrote:
Hum... I've done the change (see attached) but it's more complicated
than that. For example, InsetMathNest.C should not care about BufferList
but I need to include "bufferlist.h" to avoid this compilation error
below. Any idea someone?
With the pimpl_ implementation
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Lars Gullik Bjønnes wrote:
| > We now get a class (and header
| > file) that will have to include a multitude of other header
files. and
| > in cases headerfiles that callers does not need at all.
| | Right, initially
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Lars Gullik Bjønnes wrote:
| > We now get a class (and header
| > file) that will have to include a multitude of other header
files. and
| > in cases headerfiles that callers does not need at all.
| | Right, initially I didn't want to put thes
Abdelrazak Younes wrote:
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Andre Poenitz wrote:
| > | > On Wed, Sep 27, 2006 at 12:02:30PM +0200, Abdelrazak Younes
wrote:
| > | >>> (btw
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Andre Poenitz wrote:
| > | > On Wed, Sep 27, 2006 at 12:02:30PM +0200, Abdelrazak Younes wrote:
| > | >>> (btw. the bufferlist patch is ok
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Andre Poenitz wrote:
| > | > On Wed, Sep 27, 2006 at 12:02:30PM +0200, Abdelrazak Younes wrote:
| > | >>> (btw. the bufferlist patch is ok, but we should consolidate
|
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
| > On Wed, Sep 27, 2006 at 12:02:30PM +0200, Abdelrazak Younes wrote:
| >>> (btw. the bufferlist patch is ok, but we should consolidate
| >>> Application and LyX)
| >> Yes and my objective is just th
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
| > On Wed, Sep 27, 2006 at 12:02:30PM +0200, Abdelrazak Younes wrote:
| >>> (btw. the bufferlist patch is ok, but we should consolidate
| >>> Application and LyX)
| >> Yes and my objective is just this indeed. We all agree (I th
Andre Poenitz wrote:
On Wed, Sep 27, 2006 at 12:02:30PM +0200, Abdelrazak Younes wrote:
(btw. the bufferlist patch is ok, but we should consolidate
Application and LyX)
Yes and my objective is just this indeed. We all agree (I think) that
the frontend should use the kernel and not the other way
On Wed, Sep 27, 2006 at 12:02:30PM +0200, Abdelrazak Younes wrote:
> >(btw. the bufferlist patch is ok, but we should consolidate
> >Application and LyX)
>
> Yes and my objective is just this indeed. We all agree (I think) that
> the frontend should use the kernel and not the other way around. I
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Currently it is possible for a child document to have different
Georg> buffer parameters, even a different text class than the master.
Georg> These will of course be ignored if the master document is
Georg> typeset, but if you agree th
Jean-Marc Lasgouttes wrote:
>> "Georg" == Georg Baum
>> <[EMAIL PROTECTED]>
>> writes:
>
> Georg> And yes, changing the parameters of a child doc makes sense,
> Georg> ask Helge.
>
> Could you be more precise?
Currently it is possible for a child document to have different buffer
pa
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> And yes, changing the parameters of a child doc makes sense,
Georg> ask Helge.
Could you be more precise?
Georg> Therefore we should only modify the const version, but it will
Georg> also lead to problems if it is different from the
Abdelrazak Younes wrote:
> No, multiple nested include won't be allowed in my described scheme so
> by default a document would be opened using a MasterBuffer and any child
> document in a normal Buffer. Or we can inverse the naming if you want:
> by default use a Buffer class and child documents
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> No, multiple nested include won't be allowed in my
Abdelrazak> described scheme so by default a document would be opened
Abdelrazak> using a MasterBuffer and any child document in a normal
Abdelrazak> Buffer. Or we can
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> This is just an idea to enforce the idea of a Master
Abdelrazak> buffer that will care about LateX preample (and LyX
Abdelrazak> layout?). As far as I understand, child buffers ignore
Abdelraza
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> This is just an idea to enforce the idea of a Master
Abdelrazak> buffer that will care about LateX preample (and LyX
Abdelrazak> layout?). As far as I understand, child buffers ignore
Abdelrazak> some LateX things. It
Georg Baum wrote:
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes
<[EMAIL PROTECTED]> writes:
Abdelrazak> Would it make sense to make a new MasterBuffer class that
Abdelrazak> derives from Buffer?
No, the master buffer is just a pointer to yet another d
Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes wrote:
>>> "Abdelrazak" == Abdelrazak Younes
>>> <[EMAIL PROTECTED]> writes:
>>
>> Abdelrazak> Would it make sense to make a new MasterBuffer class that
>> Abdelrazak> derives from Buffer?
>>
>> No, the master buffer is just a pointer to ye
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Would it make sense to make a new MasterBuffer class that
Abdelrazak> derives from Buffer?
No, the master buffer is just a pointer to yet another document, which
happens to have a InsetInclude
On Wednesday 27 September 2006 12:48, Georg Baum wrote:
> This has
> something to do with the way LaTeX works.
Nope, that has *everything* to do with the way LaTeX works. ;-)
--
José Abílio
Jean-Marc Lasgouttes wrote:
>> "Abdelrazak" == Abdelrazak Younes
>> <[EMAIL PROTECTED]> writes:
>
> Abdelrazak> Would it make sense to make a new MasterBuffer class that
> Abdelrazak> derives from Buffer?
>
> No, the master buffer is just a pointer to yet another document, which
> happen
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Would it make sense to make a new MasterBuffer class that
Abdelrazak> derives from Buffer?
No, the master buffer is just a pointer to yet another document, which
happens to have a InsetInclude pointing to us. I suspec
Georg Baum wrote:
Abdelrazak Younes wrote:
Index: buffer.C
===
--- buffer.C(revision 15153)
+++ buffer.C(working copy)
@@ -1480,12 +1477,13 @@
params().parentname = name;
}
-
retain the two spaces plea
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| As the title says and as agreed yesterday.
|
| Will commit later today if there no comment.
btw. Are you aware that the Application you are working on now
actually exists already in the guise of class LyX in lyx_main.h
Abdelrazak Younes wrote:
> Index: buffer.C
> ===
> --- buffer.C(revision 15153)
> +++ buffer.C(working copy)
> @@ -1480,12 +1477,13 @@
> params().parentname = name;
> }
>
> -
retain the two spaces please.
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| As the title says and as agreed yesterday.
|
| Will commit later today if there no comment.
btw. Are you aware that the Application you are working on now
actually exists already in the guise of class LyX in lyx_main.h?
(btw. the bufferlist patch
As the title says and as agreed yesterday.
Will commit later today if there no comment.
Abdel.
Index: buffer.C
===
--- buffer.C(revision 15153)
+++ buffer.C(working copy)
@@ -15,7 +15,6 @@
#include "author.h"
#include "Bra
32 matches
Mail list logo
