Hi
Ah, I see. Transparent windows works fine for me with XGCairoSurface now -
perhaps it was a limitation in cairo that was fixed since then.
btw, I added the test to GSTest that I was meaning to write for a while, for testing
-[NSWindow setAlphaValue:] and -[NSWindow setBackgroundColor:] for
Riccardo Mottola wrote:
I tried it also on another computer with a standard GeForce card, not
exported. I don't know if the display is 24 or 32bit. How do I know best?
You might check whether the output of xdpyinfo contains a visual with 32 planes
or only visuals with 24 planes.
Wolfgang
I have to apologize, sticking to these simple rules isn't as easy as I
thought it would be. I just fixed a bug in Gorm that was inside of an
+initialize method in a category. Just imagine somebody had implemented
that method in the main class later on.
On 14.09.2011 23:39, Fred Kiefer wrote:
Hi Riccardo,
On 2011-09-15, at 2:07 AM, Riccardo Mottola wrote:
Hi
Ah, I see. Transparent windows works fine for me with XGCairoSurface now -
perhaps it was a limitation in cairo that was fixed since then.
btw, I added the test to GSTest that I was meaning to write for a while, for
Hi
ok, you mean you tried switching to XGCairoSurface?
yes, exactly.
On the machine exporting to 15/16bit display it did not help at all, same
behaviour as before.
Hm, that suggests problem is elsewhere in the back/x11 code then. Is this the
first time you tested this configuration, or
The problem I have is when some shared behavior is implemented in a superclass,
and it doesn't get called for the subclass. Something like:
@implementation Superclass
+ (void)initialize
{
[OtherClass registerNewClass:self];
}
@end
Now if I subclass Superclass, my subclass doesn't get
I'm not sure how that would help you. Your subclasses would only receive a
+initialize message once you'd sent them some other message, which requires
some other bit of code to be able to locate them, which means the other code
can trivially register them...
That said, I agree that we should
I always thought it was a bad idea to call +initialize directly. For one thing,
the runtime guarantees that only one thread can be in your +initialize at a
time, but that guarantee vanishes if you call it yourself directly. So I
typically (on Mac OS) try to init classes like this as follows:
