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, 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 plan to:
| > | >>
| > | >> 1) transfer the remaining bits of lyx_gui to Application and
GuiApplication.
| > | >> 2) transfer bits by bits the lyx_main code to either Application or
| > | >> some helper methods.
| > | > Fine with me.
| > | > 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 ;-)
| > | | For now, I am just replacing all the global variables with one
| > unique
| > | global variable.
| > But what is gained by that really?
|
| 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/*).
You would have got the same if you just cleaned up the use of extern
and location of the globals.
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 doesn't tell me anything by itself.
Besides, Application gives const & access to BufferList so this is at
least one improvement over the old code.
It is not your regular global variable
anyway, it is an unchaning instance of the _one_ object of that kind
in the whole application.
I am not sure I parsed the above correctly... Application is designed
specifically for this: it contains unique instance of objects:
- Clipboard
- Selection
- LyXFunc
- BufferList
I might add some more (egg quitting).
| > 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 these additional headers and use
| forward declaration but scoped_ptr requires them (MSVC gives errors).
| We have three solutions here:
Hmm... does MSVC have problems there as well...
Are you sure that gcc doesn't? You can compile this:
class A;
class B {
private:
boost::scoped_ptr<A> a_;
}
With MSVC I need #include "A.h" instead of class A.
| 1) use good old C pointers and manage creation/deletion.
| 1) use good old C pointers in Application.h and static scoped_ptr in
| Application.C creation/deletion.
| 3) pimpl LyXServer, LyXServerSocket and BufferList.
|
| Which one do you prefer?
What do you mean by 3)?
I hope you mean pimpl Application.
Of course I mean "put these member in a pimpled Application".
Abdel.
