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

0 files changed, 0 insertions, 0 deletions