Update of bug #19010 (project gnustep):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Fixed in svn-trunk
Follow-up Comment #2, bug #19031 (project gnustep):
Your workaround is wrong in a kind of funny way.
You should test whether savePanel _already_ has an attached accessoryView. So
something like
- (int)runModalSavePanel: (NSSavePanel *)savePanel
withAccessoryView: (NSView *)accessoryView
Follow-up Comment #3, bug #19031 (project gnustep):
Not sure, if you are correct. I would expect that, if you don't want the
standard accessory view for your document, you override the
shouldRunSavePanelWithAccessoryView method to return NO. Why would you want
any other accessory view to be
Follow-up Comment #4, bug #19031 (project gnustep):
Hm, well I thought if i don't want any accessory view you override the
[NSDocument shouldRunSavePanelWithAccessoryView] and return NO.
If you want a customized accessory view you override [NSDocument
prepareSavePanel] and do you changes there.
Update of bug #19100 (project gnustep):
Category: Application = Backend
___
Follow-up Comment #2:
Moved to category Backend because I'm sure that all this focus problems have
appeared after
Follow-up Comment #3, bug #19100 (project gnustep):
You could check out gui as well as back ... I seem to recall matt redoing
window level code, though that was more than a month ago.
___
Reply to this item at:
Follow-up Comment #5, bug #19031 (project gnustep):
The text there is not as clear to me as it seems to be for you:
You can control whether the default accessory view (which contains a pop-up
menu allowing the user to choose what type to save) appears in the Save panel
by overriding