Previously, the content view of almost all window types
could overlap the frame of the window.
This is a follow on to b28429f which insets the content view
from the frame for all relevant window types.
Refs #1798
Previously, windows with no minimum size could be resized
by the user such that the content view was completely hidden, and then
resized such that the window was effectively turned inside out.
This obviously needed to be fixed.
Now, when the user resizes a window, each _CPWindowView subclass
is asked for the minimum resize size, with the size being additively
set by each subclass. This minimum size takes into account things
like the title bar, divider line, and close button, and always leaves
at least 2px height for the content view.
The user-requested size is then pinned to the minimum resize size.
In the process of fixing this bug, I discovered in the Cocoa docs
that the CPWindow -setFrame: methods should ignore minSize and maxSize.
Other changes:
- Take the divider height into account in contentRectForFrameRect for titled windows.
- Use _CG macros and fix formatting.
Closes#1753
- CPView and subclasses support multiple-value hidden bindings.
- CPControl and subclasses support multiple-value enabled bindings.
- CPWindow and CPBox support multiple-value title with pattern bindings.
- CPButton supports multiple argument + target bindings.
- CPImageView and CPTextField support multiple-value editable bindings.
- CPMenuItem supports multiple-value enabled bindings.
- Fixed bugs in CPObjectController with simple collection operators.
- CPColorWell uses black as the placeholder color.
- Runtime object attributes from a cib are applied as they are read, not deferred.
- NSNumberFormatter now reads the number style from the xib.
- Normalized some parameter names.
- Formatting.
- Test app for all binding types.
- Popovers are implemented as child windows.
- Renamed _CPAttachedWindow/_CPAttachedWindowView to _CPPopoverWindow/_CPPopoverWindowView, since that is its only use.
- The default for CPView -acceptsFirstMouse is now NO, per Cocoa. Subclasses override this as necessary.
- _CPWindowView -hitTest returns self it the mouse is within a resize region, which may be outside the window's frame.
- Fixed an off by one bug in CPDomWindowLayer -insertWindow:atIndex:, where inserting a visible window behind a window it is already behind would cause it to move up one from its intended position.
- Updated the ChildWindows and CPPopover test apps.
- If a window is fixed width or fixed height, then no resize cursor is shown and no resize area is active on the edges that cannot be resized.
- Optimized CG calls in CPWindow.
- Added fixed height window to test app.
This commit provides resizing of windows from all sides. The legacy style, which displays a resize thumb in the lower right, can be restored with [CPWindow setGlobalResizeStyle:CPWindowResizeStyleLegacy].
- Factored out blur handler from CPTokenField into CPTextField.
- CPTextField will no longer lose focus unnecessarily.
- Changed switch style in CPWindow -sendEvent.
- Added menu bar to KeyViewLoop test app.
- It turns out Cocoa DOES recalculate the loop when calling recalculateKeyViewLoop. It does not wait until selectNext/PreviousKeyView is called.
- Cocoa calculates the key view loop for nibs that do not have one, but does not call recalculateKeyViewLoop.
- If there is no first responder and no initial first responder when a window first becomes key, use the first valid key view, not the first geometric key view.
- Made allViews function a method, not sure why it was a function.
- Unit tests now pass.
- Removed unnecessary code at beginning of CPTextField -becomeFirstResponder that might have been a hack to get around a bug I fixed.
- Fixed race condition in setTimeout closure in CPTextField -becomeFirstResponder.
- CPWindow -setInitialFirstResponder now works reliably and follows Cocoa behavior in that if -makeFirstResponder is called with something other than the window before the window is first shown, it will override the initial first responder.
- Like Cocoa, until the first responder is set during window load, the first responder is the window by default, not the content view.
- Optimized search for any view that has a previous/next key view set.
- Sheets can become key windows again.
- CPWindow -recalculateKeyViewLoop now just marks the loop as dirty, per Cocoa docs.
- CPWindow -autorecalculatesKeyViewLoop now behaves per Cocoa, it only has an effect when views are added or removed.
- If the first responder does not have a valid previous/next key view, it does not resign to nil, per Cocoa behavior.
- Code optimization and cleanup.
- Test app (KeyViewLoopTest) that demonstrates various scenarios.
- Track mouse exit from window resize rect instead of unconditionally setting arrow cursor.
- Don't show the resize cursors for full platform windows.
- Show the resize down cursor if the top of a window is being resized and it has reached the bottom of the menubar.
- Make windows in CPToolbarTest resizable to test resizing behavior with toolbars.
- Added a full platform window and menubar to the test app.
- The main run loop resets the cursor if it falls outside of all windows during a mouse move.
- Added cursors supported by CSS that are not in NSCursor.
- Code cleanup in CPCursor.
- Cursors now indicate available resize directions if there is a window min/max size.
- Reduced slop to 3, what it is in Cocoa.
- Added a second non-min/max window to the demo.
Due to a typo in ce9534c, even standard titled windows returned NO for `canBecomeKeyWindow`. This triggered errors in `CPApplicationTest`.
The fix returns the correct YES for `canBecomeKeyWindow` of titled windows.
Without this fix Cappuccino always returned YES for `canBecomeKeyWindow` for every window. But in Cocoa, only "standard" windows with a title bar and/or resizing return YES.
With this fix Cappuccino better matches Cocoa's behaviour.
Without this fix, the tab key press would be propagated to the browser, which would blur the focused input element, even when that input element was the one the new first responder intended to use.
Without this feature windows could easily end up being placed outside of the screen/browser when loaded in Cappuccino due to e.g. the window position being 100 px from the bottom of a 1418 px tall screen but the browser only being 800 px.
This commit adds support for all "initial position" window masks in Interface Builder except "centre". Position can be specified in current screen space coordinates and then adjusted proportionally to the browser size, or adjusted while preserving a left or right margin and a top or bottom margin.
If a window contained a text field which was the initial first responder, and the window was displaying a sheet, clicking on the window would cause the text field to alternate between being the first responder and not.
This was caused by the window `orderFront:` setting its first responder to the initial responder if there wasn't any responder yet. This would cause the text field to focus, even that the window wasn't the key window, and then on the next click the text field would blur which would make the text field automatically resign its first responder status.
The solution is to leave the first responder status alone if a window which isn't the key window is `orderFront:`ed. This appears to be more sensible UX in general. You don't expect the first responder of non-key windows to change when you click it's background.
Aparajita Fishman
Randall Luecke
Andrew Hankinson
Aparajita Fishman
Antoine Mercadal
aparajita
Alexandre Wilhelm
Martin Carlberg
Alexander Ljungberg
Darrell Walisser
Alexander Ljungberg