Either I haven't understood what you talk about or you didn't understand
what I was talking about.
I fail to see how a Makefile.am magic can help this problem, Unless I use
it to actually rename the file LyXImage_specific.h to LyXImage.h and its
corresponding C file. And this doesn't sound all too clean to me.
Regarding the second point that you raise, the idea is to have an anemic
LyXImage class, one that has no real function but derived classes have the
methods that are actually used (setImage and getImage that set and get the
correct system dependent format). Basically the idea says that there will
be three classes in the mix, ImageLoader, LyXImage and Painter.
ImageLoader knows how to load various image formats to memory
representation and create a system specific LyXImage, and Painter knows
how to paint the corresponding LyXImage to screen. However in order to
transfer the LyXImage from ImageLoader to Painter I need to use a
LyXImage* and in order to have access to the system specific methods I
need to use a dynamic_cast<> in order to down-cast LyXImage to
LyXImage_specific.
for example LyXImage_X, has a method getPixmap(), this returns an
X-Pixmap, something that obviously Windows doesn't have. So the
LyXImage_Win will need to have a getWhatever() method that will return the
system dependent memory representation of the image.
On Mon, 23 Oct 2000, Allan Rae wrote:
> On Fri, 20 Oct 2000, Baruch Even wrote:
>
> > The current method that is used for LyXImage is pretty ugly, the header
> > file LyXImage.h includes the right header file for the frontend by using
> > the preprocessor.
>
> You could use some Makefile.am majic and put the support files in
> appropriate directories. Then just #include "LyXImage_specific.h"
> then the LyXImage_specific.h will be found in the appropriate directory
> which will be added to the include path to the compiler.
>
> > My problem is that I need the different LyXImage objects to have different
> > signatures, the X-Server version uses Pixmap, possibly the Gnome frontend
> > will use something else (either from imlib or gdk_pixbuf), and the windows
> > version will need to use something completely different.
> >
> > But anyhow the only interaction done with LyXImage is loading it by the
> > various image loaders for the various frontends, holding it as a pointer
> > or a reference wherever its needed (InsetGraphics for example) and
> > displaying it by using a Painter method that accepts LyXImage. So
> > effectively except the specialized parts (ImageLoader and Painter) nothing
> > else needs to know about the methods of LyXImage, except to construct it
> > and possibly not even that (by using pointers).
> >
> > The problem is that LyX is compiled with the -fno-rtti option, so I'm
> > unable to use a dynamic_cast to get the true type of the object. The
> > initial idea was to use a simple LyXImage, where the ImageLoader creates
> > the appropriate LyXImage, the others know nothing about it and the Painter
> > dynamically casts the LyXImage to the one it knows to handle (for example
> > LyXImage_X). Without RTTI (RunTime Type Information) this is impossible.
> >
> > So, how do I solve this? Can we remove the -fno-rtti flag? Any other C++
> > idiom that I should use?
>
> Each system will have a matching painter and LyXImage. You shouldn't have
> to worry about whether its an XPM or BMP or a hamburger. Everything
> that's system dependent should already have matching data types. You
> shouldn't face a situation where the Painter only knows how to draw XPM
> and the LyXImage only knows BMP because that would have be different
> systems.
>
> Anyway, if you really are sure that the Painter and images may be
> different on some given system then the LyXImage should be able to convert
> itslef into whatever format the Painter requires. This would get ugly
> with lots of functions -- one for each system supported * number of
> functions needed to set/get a format.
>
> Anyway it would be appropriate for the Painter to only know about the type
> it expects (one per system). So it should ask the LyXImage to provide
> that. There should be no need for a dynamic_cast<> within Painter.
>
> Just make sure src/PainterBase.h doesn't specify an image other than
> LyXImage and that xforms/Painter.h, gnome/Painter.h, and
> kde/Painter.h match support/X/LyXImage.[hC]
>
> In fact you probably don't need a higher level LyXImage.h and can get by
> with a system specific one. At least as soon as the tk-specific Painters
> are moved into their respective directories.
>
> Allan. (ARRae)
>
>
--
Baruch Even
http://techst02.technion.ac.il/~sbaruch/ (My Site)
http://www.redrival.com/jindor/ (My brothers AD&D site)
" Learn to laugh ... it's the path to true love! "
- The Angel in the movie Michael
