Re: NSSavePanel fragile ABI - do we care?

[Ivan Vučica]

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 <address@hidden> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev