kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

> On 29. okt. 2007, at 05:32, Dick Hollenbeck wrote:
>
>
> > Have you taken my advice and contacted the wxWidgets group? It looks
> > like wxWidgets for Mac has some holes that need to be plugged.
> Not yet. However, searching around, this restriction seems to be a 
> result of modernizing of the wxMac port.
> See http://thread.gmane.org/gmane.comp.lib.wxwidgets.general/55555.
>
> The question is whether it makes more sense to "fix" KiCad or wxWidgets.
>
>
> > I am not feeling comfortable with the idea of getting a flood of 
> > 50 to 100
> > #ifdef wxMAC s coming into the code.
> Definitely not. If this would be fixed in KiCad it should be done by 
> reorganizing DC instantiation for all platforms, not just hack around 
> it for the Mac.
>
> ~/= Marius
Those posts are earlier this month. So this is just coming to light? 

One poster said the following, and it is what I was thinking. This idea 
should have gotten more mileage on that list:

""""""""""""

This seems like a rather bad restriction. I wonder if we couldn't make
all wxClientDC instances on the same window use the same underlying
CGContext somehow. It could still result in problems with changing DC
attributes but if we restored them carefully, it would allow something
(common) like this:

wxClientDC dc1(win);
...
{
wxClientDC dc2(win);
... use dc2 ...
}
... use dc1 ...

even if you still couldn't use more than one wxClientDC concurrently (which


is much less common).


""""""""""""""

Towards that end, if you build wxWidgets from source, you might be able 
to augment the wxDC constructors and destructors with event logging (~ 
printf()s ? ) and gain a better understanding on how they are being 
used within Kicad. In any case the source to those needs to be understood.

HTH,

Dick