Re: Closing windows bearing sheets
Re: Closing windows bearing sheets
- Subject: Re: Closing windows bearing sheets
- From: email@hidden
- Date: Mon, 4 Mar 2002 17:05:46 -0800
Every developer trying to work around the bug (each in a different
way, probably) will just waste a lot of everybody's time, and quite
possibly lead to a bunch of broken apps when Apple fixes the bug in a
way that turns out to be incompatible with people's hack workarounds.
Hey, I resemble that remark! :)
Yeah, don't we all. :->
I'd say that, as workarounds go, the one I just posted is pretty
obvious, painless, and unlikely to break in the future. The correct
way for Apple to fix it is to not try to close windows which have
attached sheets--and in that case, the workaround code will not cause
any harm.
Hmm. Famous last words.
What if Apple decides the right way to fix the problem is to "handle"
the open sheet somehow, and they put the code to do this downstream from
where -windowShouldClose: gets called, basically saying "well, if the
window should close but it has a sheet on it, then let's choose the
default action for the sheet" or some such. Maybe the Kit will
introduce some idea of "cancellable sheets" where sheets you run have
standard ways of getting backed out if the user takes a larger action,
like clicking a close box, that implies they no longer are interested in
the issues presented by the open sheet. Maybe some of the standard
sheets (like NSDocument's save sheet) will support this notion, but
won't be given the chance to back out because your code will
short-circuit the process before they get a chance to act.
What if Apple extends the concept of sheets to include some standard
*non-modal* sheets (like the color picker becoming a non-model sheet you
can pull down into your window and keep up as long as you want, or
something). Now your windows won't close anymore when they have one of
these non-modal sheets in them, unlike the windows of all the other
Cocoa apps out there that didn't use your workaround code.
Etc. etc. Sure, these are somewhat far-fetched examples. But many's
the time I've seen workaround code end up breaking an app. The basic
premise that such things happen is certainly not far-fetched at all.
One should not live in fear of the Kit changing and breaking one's code;
but this issue should weigh in a decision as to whether working around a
given Kit bug is a good idea or not.
Personally, I would prefer that people share the bugs they find and the
workarounds they invent, so at least we can discuss the pros and cons
of these things openly, instead of pushing it all into the closet.
Forcing everyone to reinvent workarounds is only going to lead to
*more* badly done hacks, IMHO. And often enough people think they need
workarounds to bugs which don't turn out to be bugs after all.
Also, I've never seen a workaround that didn't teach me more about how
the system actually works, or bring up details I wouldn't have thought
of.
Sure, I'm all in favor of an open discussion, I wasn't trying to
squelch anybody. I was just expressing my opinion that this is a bug
that is properly *not* worked around. I have an app or two where this
bug is probably hit. But I'm not going to go add workaround code to
those apps. I think that's the wrong response in this case.
I do agree that some bugs are not worth the trouble to work around (for
instance, the one recently posted to MacOSX-dev about the popup menu in
the title bar moving the window instead of the menu...), but I'd leave
it to each developer to make an informed choice about each individual
bug in the context of their own app.
Sure. I think we're in agreement on that. I was just arguing against
a knee-jerk reflex to put this workaround code into every app bitten by
Apple's bug. Sorry if I was unclear.
Ben Haller
Stick Software
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.