On Sun, 22 Oct 2000, Baruch Even wrote:
> 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.
The Makefile stuff just chooses which directory it will find the system
specific implementation in. Just like we do for the other frontends
stuff. Each system (X, Win32 etc.) then has the same name for the headers
as every other system implemenation. The include path determines which
one of those headers gets included.
Since each system implementation of LyXImage will only be used by
frontends that work on that system then there won't be any weird
combinations of what the Painter will try to use and what the LyXImage is
capable of providing -- since they are both system-specific (where
LyXImage is also toolkit ignorant although it doesn't have to be).
> 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.
I still think you should be able to push this lower (ie. into the
frontends). Painter is gui-specific so it will know what functions it has
available. It will know that it will _always_ have a particular type of
LyXImage implementation. For example, xforms/Painter.h (which is
currently sitting in src/Painter.h and appears to be an Xlib rather than
XForms specific implementation) will _always_ be used with the
support/X/LyXImage.h implementation. So it _knows_ that LyXImage* will
have pixmap functions.
You don't need to down cast.
> 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.
Does PainterBase need to know about LyXimage's? I would say no.
In that case all the different implementations would be called LyXImage
and reside in different directories. (even if the answer is yes, you
still put everything in same directories and call them all LyXImage and
have a LyXImageBase class)
The system dependent getWhatever() function will be known about by ...
Wow what a beautiful sunrise... fantastic pink and orange glowing clouds.
... the system&toolkit specific Painter and implemented in the system
specific LyXImage. If you can implement PainterBase such that it doesn't
need to know about LyXImages then we could argueably skip LyXimage
entirely. However, supposing that isn't possible then when you access a
LyXImageBase* in Painter you _know_ it will really be the right thing so
you can static_cast it if need be.
So the moral of the story is push as much system/toolkit specific stuff
into the frontend specific implementations and whereever possible avoid
passing some parameter in the Base classes that is itself a Base class.
Now I'm really tired and my back doesn't love me anymore so I'm going home
for some sleep while I can still walk.
Allan.
> 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
>
>
>
Allan. (ARRae)
