[wx-dev] wxDC reorganisation

[Robert Roebling]

Vadim Zeitlin wrote:

> Robert Roebling wrote:
> 
> RR> I have been thinking about how to add support
> RR> for Cairo drawing to wxGTK's wxDC code. One
> RR> way would be a pimpl mechanism for wxGTK alone
> RR> without touching any other code at all. It is
> RR> quite obvious that a more general appraoch
> RR> would be better, basically making it possible
> RR> to plug-in drawing implementation into a wxDC
> RR> interface. 
> 
>  Absolutely.
> 
> RR> In the end, there will only be one wxDC class
> RR> (in base) and the wxDCBase class will dissappear
> RR> (or rather be merged with that).
> 
> I'd agree with this but I don't see how would it work
> with wxClient/Window/ScreenDC hierarchy, without speaking
> about other DCs such as wxPrinterDC or wxMemoryDC or

There would still be a wx/Paint/ClientDC per platform
which would do nothing but choose the right backend.
So there would be a wxPimplDC and a wxMSWClientPimplDC
deriving from it.

> pseudo DCs such as wxMirrorDC or wxBufferedDC?

I haven't thought about that, but where is the
problem?

> RR> Then some code can e.g. test for the presence of Cairo (on any
> RR> platform) and use that by using the Cairo backend. Does anyone think
> RR> this should not be done or could be better done?
> 
> I definitely think it should be done at wx[Client?]DC level.
> But I think wxDCBase would have to stay nevertheless. I.e.
> the DC hierarchy would continue use inheritance as it does
> now but would also use aggregation at wxDC/wxClientDC level.

The wxPostscriptDC would inherit from wxDC, but its main
task would be to do a 
wxPostscriptDC( params )
{
    this->SetPimpl( new wxPostscriptPimplDC( params ) );
}

I don't think we need wxDCBase for that. The various
implemenations need to derive from the pimpl interface
class, not anything else.

  Robert