RE: FW: Enabling sharing of Qwt objects - https://sourceforge.net/p/qwt/patches/62/
Brought to you by:
rathmann
From: Peter Myerscough-J. <pet...@ma...> - 2017-02-06 16:20:45
|
Uwe, > So please let's rest the design pattern discussion and come back to real issues > you need to solve ? 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. I also cannot (as a nasty hack) set the base version (in my proxy) to a symbol type that forces the renderSymbols function to be called, and then call the proxied classes drawSymbol, or renderSymbol functions because the drawSymbol(s) functions have side effects on the passed in painter object. I cannot therefore derive a proxy class because the interface is not virtual, and the non-virtual functions have side effects that cannot be controlled. 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. The other classes I have suggested because I can see that I may have a requirement to proxy those classes, may be not immediately because I am focusing on the plots/curves/histogram type widgets, but if I want to add them to the QML version of Qwt then I will need to proxy them. The discussions up until now have, for me, tried to be about the merits of the changes or ways the changes could be implemented. Yes, the functions could just be made virtual, or we could create interface classes that clarify how Qwt uses a QwtSymbol or similar object when it is assigned, or we could add setAttribute(OwnsSymbol, false) functions. I do not mind how we approach enabling proxying/sharing objects/"Qwt not deleting the pointers we give it", but I need Qwt not to delete certain objects I give it, or I need to give it proxies that I do not mind Qwt deleting, and those proxies need to be able to 'forward' any function calls Qwt makes on the object. If I haven't made it clearer and it needs to be, please do say, Yours, Peter Ps. I know I said I could not see a problem with adding virtual functions, but I can see an issue with adding virtual functions in that the library will lose ABI compatibility because the virtual function table for the object will become larger. I don't think it should affect programs if they are rebuilt against the new library version. |