Considering no replies came, here's a few of my own thoughts: 1. I consider GNUstep as something that has to keep source-level compatibility; binary level? Not so much. What for? There are so many, many combinations. Plus we don't even release our own binaries. 2. Even if we cared about ABI compat, apparently NSSavePanel is only subclassed in framework itself, to get NSOpenPanel. Apps are NOT supposed to be subclassing it. At least from a bit of googling I did on the phone.
Plus, NSSavePanel returned in a sandboxed environment on OS X is different than in non-sandboxed. Apple wouldn't do that if the class could be subclassed reasonably... Regards, Ivan Vučica via phone On 10. 8. 2013., at 15:55, Luboš Doležel <[email protected]> wrote: > Hi, > > I'm adding two methods using blocks: > > - (void) beginSheetModalForWindow:(NSWindow *)window > completionHandler:(GSSavePanelCompletionHandler)handler; > - (void) beginWithCompletionHandler (GSSavePanelCompletionHandler)handler; > > into NSSavePanel. For the latter, I need to add two ivars > > GSSavePanelCompletionHandler _completionHandler; > NSWindowController *_modelessWindowController; > > since its modeless and returns immediately. > > Should I add indirection not to break fragile ABI derived classes, or do > you think it's not needed for this class? > > -- > Luboš Doležel > > _______________________________________________ > Gnustep-dev mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
