Re: FW: Enabling sharing of Qwt objects - https://sourceforge.net/p/qwt/patches/62/

[Uwe R. <Uwe...@ti...>]

Hi Peter,

> I need to be able to proxy the QwtSymbol, and although you have
> argued that the renderSymbols function is virtual to allow the class
> to be derived, Qwt uses the drawSymbol and drawSymbols functions
> internally to render the symbols. These functions are not virtual
> and contain code paths that do not call renderSymbols.

QwtSymbol::drawSymbols implements a pixmap cache on top of
renderSymbols, what doesn't make sense for a proxy. Disable it by
QwtSymbol::setCachePolicy() and you always run straight into 
QwtSymbol::renderSymbols().

QwtSymbol::drawSymbol() is called by QwtPlotCurve::legendIcon(), 
QwtPlotMarker::legendIcon() + QwtPlotMarker::draw().

But as you also have proxy classes of all plot items, where the methods 
above are overloaded - why would you call QwtSymbol::drawSymbol() there ?

In general I would expect that overloading QwtPlotCurve::drawSymbols 
might be a more flexible approach for your proxy class. QwtPlotMarker 
does not have a virtual drawSymbol method, but introducing it fits into 
the API design and could be done for Qwt 6.2.

> I also need to proxy the QwtDataRaster, and currently I have a nasty
> hack that stores the proxied object's interval in the base class the
> proxy derives from and updates the base, whenever the derived class
> is updated. This is a workable work around.

So what you are looking for is something like this:

class QwtRasterData
{
public:
     ....
     virtual QwtInterval interval( Qt::Axis ) const = 0;
     virtual double value( double x, double y ) const = 0;
};

( no more setInterval and no members storing the intervals ! )

As users have to derive from QwtRasterData anyway and the compiler will
tell you about such an API change why not. Guess there are also not many
use cases, where the intervals are changed without changing the data too
so casting in user code has to be done anyway.

There is also QwtMatrixRasterData - a class, that is usually used
without deriving. So the members removed from the base class need to be
added there.

I'm fine with such a change,
Uwe