Hi Josh, thank you for your detailed reply. It helped me understand the issue a lot better.
Am 20.09.2015 um 00:06 schrieb Josh Freeman: > On Sep 19, 2015, at 7:20 AM, Fred Kiefer wrote: >> thank you very much for porting this great code over to GNUstep. >> >> I am at the moment trying to get it running on gcc with the gcc objc >> runtime. I know this isn't the supported constellation, but I would like >> to at least understand what features are missing in this setup. > > PikoPixel's implementation of method-swizzling doesn't work with the > gcc runtime because the runtime's function, class_replaceMethod(), > behaves differently than on the objc2 or Apple runtimes. That's the only > issue I know of (though I didn't test much further on gcc after finding > it), so in theory, a reimplementation of method-swizzling (in > NSObject_PPUtilities_MethodSwizzling.m) that removed/reworked the > class_replaceMethod() calls could allow PP to use the gcc runtime. I already had figured out from the messages on the terminal that method swizzling was causing the problems, but didn't understand why. With your hint and a bit of googling (http://nshipster.com/method-swizzling/) I ended up with a small change to your swizzling method. All I had to do was to replace the two calls to class_replaceMethod() with the following: BOOL didAddMethod = class_addMethod(self, selector1, implementation2, typeEncoding2); if (didAddMethod) { class_replaceMethod(self, selector2, implementation1, typeEncoding1); } else { method_exchangeImplementations(method1, method2); } Strange enough this only works for the two instance method swizzling methods, for the class methods I have to use just method_exchangeImplementations(method1, method2); This seems to work with the gcc runtime. I really don't understand what I am doing here and why it should be any different. Now PikoPixel starts up and works fine for me. Of course I also removed all the swizzling for methods I already changed in GNUstep and I had to fiddle with the PPBuildEnvironmentMacros.h file to enable swizzling. >> I parallel I am digging through your GNUstep specific changes. I already >> found the NSMatrix additions and the cairo non-anti-alias stuff. I am >> going to add code into GNustep that supports this to make specific >> additions for GNUstep unnecessary. In theory it should be possible to >> just reuse your Cocoa code on GNUstep. Where this isn't possible, please >> file a bug report against GNUstep, preferable with an attached patch. > > I kept an internal list with brief, 1-to-2-line descriptions of > issues (now at about 17 items) that needs to be expanded into full bug > reports on savannah when there's time - I wrote one up so far: > http://savannah.gnu.org/bugs/?45442 . I'd be happy to send the raw list > to you - or post it to the developer mailing list - if that would be > useful. Just send me that internal list, together with your code changes, this should help me figure out what went wrong in GNustep. As for your bug report, I am sorry to never have replied to it. Window ordering is one of the weak spots in GNUstep. Previously I tried to figure out suitable values for window properties for KDE and Gnome for each new release. But I gave up on that a long time ago. Now I just take care that GNUstep stays usable on my own KDE environment. If you are interested in the problem please take a look at the method setwindowlevel:: in back/Source/x11/XGServerWindow.m. >> Once again thank you and I will keep you updated on my progress. > > Thanks, please do! Done :-) Fred _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
