NSDrawer offset problem (class bugs)
NSDrawer offset problem (class bugs)
- Subject: NSDrawer offset problem (class bugs)
- From: Shaun Wexler <email@hidden>
- Date: Thu, 16 Jan 2003 00:30:22 -0800
I need specific NSDrawer behavior for fixed sizing. Examining
DrawerMadness a few hundred times has not solved the problem.
I need to maintain a fixed-size drawer opening on NSMaxX edge, but am
seeing the undefined window resizing behavior expressed in many posts
on the subject. Since IB has a bug with its NSDrawer object sizing, I
store only the content view, and create the drawer programmatically.
To allow my window to be sized smaller than the drawer (when the drawer
is closed), I don't attach the drawer to the window until the
-drawerShouldOpen: method. After adjusting the window's frame to a
sufficient size if necessary, the drawer is attached and opened. The
drawer's content view size is used to set both the min and max drawer
content sizes. Offsets for the drawer are calculated and applied.
Then all hell breaks loose when the window itself is resized with the
drawer open.
What I see happening is the window has an arbitrary minSize prior to
attaching the drawer. Upon attachment, the window's minSize is set by
NSWindow or NSDrawer to the sum of the leading and trailing offsets,
plus the drawer window's (private) frame size, thus preventing the
window from being sized smaller. At this time, the drawer's content
view size is also grown slightly by NSDrawer, likely to appease some
internal HIG assertion? Setting any of the springs or rods on the raw
view in IB results in positioning problems in the drawer's content view.
Is there a magic formula?!!! What am I missing? This is killing me...
The provided methods are a boneheaded way to implement a useful drawer
(using offsets to the window frame). The window's point of reference
for the leadingOffset (for my right-edged drawer) is the window content
view's top edge (plus 1px for the titlebar frame?), and the same for
the bottom. The problem is that this reference is tied to a private
object: the NSDrawerWindow's frame!!! Not the drawer's content size,
as it should be? There is not a "public" way to get this frame
information, though I can grab it from the view, once the drawer is
already open.
To make an NSDrawer intuitive for developers, it should respect its min
and max content size constraints. If the window MUST constrain the
drawer's size to ensure it's smaller than the window frame, there is
still no reason to restrict the window's min size based on the DRAWER
OFFSETS, which have nothing to do with the coverage of the drawer by
the window!
The undefined window behavior upon resize is a strong indicator of a
roach-fest permeating the class. What can I do to get the behavior I
need from the drawer, without writing my own drawer class using
attached windows, as it seems I'm headed towards?
I've been going MAD with the apparent bugs in the NSDrawer
implementation. RadarWeb has been chewing on my NSDrawer bug reports
since August, and hasn't fixed the NSWindow behavior problems, which
are still open in my bug reports file, and present in 10.2.3.
Frustrated, but ~patiently~ awaiting any offers of help (hello, Apple?)
:-)
Thank you!
--
Shaun Wexler
MacFOH
http://www.macfoh.com
_______________________________________________
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.