fdo#39007: Brute force fix: Unlink a potential restorecount.plist file

It is not completely clear to me whether we really still might be
leaving such files around. After all, we now in *two* places (at least
in current master) tell our NSWindows to not be
restorable... Norbert's code in AquaSalFrame::initWindowAndView()
*and* Herbert Dürr's code in -[SalFrameWindow initWithSalFrame:].

On the other hand, Cocoa does seem to create the file and keep it
around for a short while before removing it (in responce to our
setRestorable:NO calls?), so there is a slight time window where if LO
crashes, the file will be left around.

Such a file might also be around from an older LO version, or manually
planted there by somebody wanting to reproduce the bug...

Of course, the *real* fix for this problem would be to make LO a
*proper* Cocoa document centric application, that would use
NSDocument, NSApplication etc like native applications are supposed
to, and that *would* handle window restoration the Cocoa way. I.e.,
work with the system instead of against it.

Change-Id: I9ed058130ddddf49cf0221d899bef3e2654589c7

vcl/Library_vcl.mk

@@ -352,6 +352,10 @@ $(eval $(call gb_Library_add_cxxflags,vcl,\
     $(gb_OBJCXXFLAGS) \
 ))
 
+$(eval $(call gb_Library_add_defs,vcl,\
+	-DMACOSX_BUNDLE_IDENTIFIER=\"$(MACOSX_BUNDLE_IDENTIFIER)\" \
+))
+
 ifeq ($(ENABLE_CORETEXT),YES)
 
 $(eval $(call gb_Library_add_defs,vcl,\

vcl/aqua/source/app/salinst.cxx

@@ -184,6 +184,8 @@ static void initNSApp()
 
 sal_Bool ImplSVMainHook( int * pnInit )
 {
+    unlink([[NSString stringWithFormat:@"%@/Library/Saved Application State/%s.savedState/restorecount.plist", NSHomeDirectory(), MACOSX_BUNDLE_IDENTIFIER] UTF8String]);
+
     gpnInit = pnInit;
 
     bNoSVMain = false;