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)
