Previously, calling setPostsFrameChangedNotifications:YES or setPostsBoundsChangedNotifications:YES would immediately result in the notification being sent. Cocoa will only send in this context if:
- setPosts[Frame/Bounds]ChangedNotifications:NO was called.
- The frame/bounds changed between that call and the call to setPosts[Frame/Bounds]ChangedNotifications:YES.
We are currently not tracking pending changes, so this commit removes the sending of the notification completely in those methods.
Fixes#1076
Previously, Cappuccino would resize in such a way that a view's size ratio to its superview would not be maintained.
This commit ensures that size ratios are maintained during resizing.
Patch contributed by @davidkhess
Fixes#357
Previously, when a sheet was resized, there were a number of problems:
- Sheets in Cocoa resize their width symmetrically, such that they always remain centered. This was not happening in Cappuccino.
- When a sheet is resized wider than its parent window, the shadow at the top of the sheet was growing wider than the bounds of the parent window's title bar, which makes no sense since the shadow is supposed to be cast by the title bar.
- Sheets had no top border, so when they were resized wider than the parent window, the top edge looked like it was cut off. In Cocoa, sheets have a top border that sits under the title bar of the parent window, and which is visible when the sheet is resized wider than the parent window.
This commit addresses these problems as follows:
- Sheet width is now resized symmetrically.
- Sheet resizing is pinned to the screen bounds.
- The top sheet shadow is pinned to the width of the parent window's content view.
- Sheets now have a top border.
In addition to these changes, a redundant sheet top shadow was eliminated from one of the _CPWindowView subclasses.
Fixes#1846
Previously sheet animation was performed by sizing the sheet from zero to full height when animating in, and then back to zero height when animating out. This caused problems with the resize algorithms, which are not designed to deal with sizing from zero.
Analyzing Cocoa behavior revealed that sheets slide in and out with no resizing.
With this commit, a general purpose mechanism for clipping a window to a rect was added to CPDOMWindowLayer. Clipping was put in CPDOMWindowLayer because that is the class that deals with windows at the global level. CPWindow uses the clipping mechanism to slide the sheet in and out, thus avoiding all resizing problems.
Fixes#1840
Previously the attached sheet shadow (that appears below the title bar of the window a sheet is attached to) was 9x8, and it was quite dark.
With this commit the width has been reduced to 1 (to reduce the image size) and it has been lightened up.
Also changed "height-shadow" theme attribute to "shadow-height".
Previously, sheets could be resized from the top, which would destroy the illusion of being attached to the top of the parent window.
With this commit, sheets are prevented from being resized by the user from the top edge.
Fixed: mouseEntered and mouseExited mixed up for custom views in menu
Previously, when clicking and dragging inside a menu, mouseEntered and mouseExited were sent to the wrong views.
This commit correctly sends mouseExited to the previous hovered view, then mouseEntered to the new hovered view.
Fixed: using keyboard navigation in empty CPCollectionView threw exception
Previously, if an empty CPCollectionView was first responder and keyboard navigation was used, a CPInvalidArgumentException (Range {-1, 1} is out of bounds) was thrown.
This commit checks for an empty collection, eliminating the exception.
Without this fix, a platform window could be resized by clicking just under the menu bar and dragging downwards, even that platform windows are supposed to be the size of the browser window by definition.
Without this fix, the presence of a modal ancestor window to a token field would lock down the autocomplete menu from mouse interaction.
This fix ensures the token field autocomplete menu accepts mouse events even during the presence of modal widows, just like other auxiliary windows such as pop up menus.
Without this fix, opening a transient popover would allow windows other than the modal window (or its children) to be interacted with.
In general, setCallback:forNextEventMatchingMask: did not work right if more than 1 callback was installed.
In the popover case the modal window would install its "any event" callback to control the event loop, but then the popover would add a second callback for mouse down to detect clicks outside of it. This would disrupt the modal event handling and allow mouse clicks (and presumably other events) to escape the modal event catcher.
This fix makes multiple nextEvent callbacks work as one would expect, with later ones taking priority over older ones and reinserted callbacks remaining at a stable priority.
This allows the modal window callback to be at the "bottom" of the handler stack and the popover event handler to be "on top" of that, and to remain that way. In theory more layers of event handling could be layered on top such as 2 simultaneous popovers.
This fix also fixes the dequeue argument in forNextEvent callbacks.
Without this fix, a transient popover would close if the autocomplete menu of a token field contained in it was clicked.
This happened because the popover considered the click to be on a different window. Although not tested, it's likely the same thing would happen if the menu of a combo pop or a pop up button was clicked.
This fix makes it so that any child window of a popover can be clicked without the popover closing.
New: use dedicated class instead of CPString for selection markers
Previously, selection markers were strings, which allowed the possibility that user data could be mistaken for a selection marker.
With this commit, selection markers are global instances of a private class, removing the possibility of clashes with user data.
Fixed: views from other windows cannot be next/previous key views
Previously, a view from another window could be set as the next/previous key view, which would result in unexpected behavior, including an infinite loop.
This commit ensures the proposed next/previous view belongs to the same window as the view to which it will be chained.