Also fixed CPView -(BOOL)inLiveResize
If a view is added during a live resize, it will not receive a
willStart notif.
If a view is removed during a live resize it will not receive a Didend
notif.
Previously a fixed margin of 40px was maintained at the left/right of a window when resizing it, which was excessive.
Now the minimum size allowed during a resize is the same as the minimum margin allowed when moving a window, which is determined based on the type of window.
Previously, window moves were constrained such that a minimum margin of the window was visible on screen, but window resizes were not constrained, allowing the user to effectively move the window off screen.
Now resizes are constrained such that a minimum margin of the window is always visible on screen so that the window does not get "lost".
Previously when using a sheet window in a fullPlatform window, the sheet window started the animation under (the layout) the toolbar.
Now, the sheet animation starts below the toolbar as in cocoa.
It also fixed that only a CPBordelessWindow/CPTitleWindow/HUD can have a toolbar.
It is possible to resize the parent window of a sheet while it is open. Previously, the sheet's top shadow was not adjusted when the parent window was resized, which could lead to it being out of synch.
Now the sheet shadow is adjusted whenever the parent window's size changes.
Previously, Cappuccino was using preprocessor macros internally for the CGPoint/Size/Rect/Inset/Affine functions, as well as for CPRange. These macros had the same name as the corresponding function, but began with _. The functions were actually defined using the macros.
The motivation behind using macros was to increase performance by reducing function calls. However, there were a number of problems with this approach:
- There was an artificial dichotomy between _CG macros and the corresponding CG functions. We never completely replaced CG function calls with _CG macros. In fact, they were often mixed up in the same file. There was an extra burden on the programmer to remember to use the macro instead of the function.
- If a method call was passed as an argument to a macro, performance could actually be significantly *worse* than a function call. For example, _CGGetRectMakeCopy([view frame]) would expand to `{ origin:{ x:[view frame].origin.x, y:[view frame].origin.y }, size:{ width:[view frame].size.width, height:[view frame].size.height } }`. So instead of a single objj_msgSend and a single simple function call, we ended up with 4 objj_msgSend calls, which are way more expensive than simple function calls.
- Because of this expansion problem, to use macros efficiently required us to remember to use variables for all macro parameters. This didn't happen, and shouldn't have to happen.
- Finally, with modern Javascript engines, function call overhead is so small that it really isn't worth using the macros.
This commit eliminates the _CGGeometry, CGAffineTransformation and CPRange macros and replaces them with function calls.
BREAKING CHANGE:
The macros are no longer available. They could only be used with compiled code, but if there is any user code that used them, they will have to be replaced with the corresponding functions.
After bbfaac5, all kinds of strange behavior occurred with window sizing and moving due to overzealous constraining.
Cocoa does not constrain the frame of hidden windows. When a hidden window is ordered in, it is constrained to the usable screen content rect. A visible window has its height constrained when its frame is set. Its origin is constrained such that a minimum margin at the left, right and top is visible, and the top is constrained to be below the menu bar.
This commit fixes a number of problems related to window moving and resizing that were introduced by bbfaac5:
- Sheets are not constrained at all.
- Moving a window does not constrain its size.
In addition, when a window is moved, tracking is relative to the initial click point, which provides proper behavior when the movement is constrained and the mouse keeps moving.
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, 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.
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.
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
- 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.
- 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.
The window views driving non standard windows (such as borderless or bridge windows) did not take the toolbar into account when calculating the content rect.
Apart from being wrong, this could lead to the content view overlapping the toolbar if the content view was set after the toolbar was prepared.
Perhaps the thought was that the base _CPWindowView shouldn't make assumptions about the placement and sizing of a toolbar and leave that up to subclasses, but the _CPWindowView tile method already did.
Didier KorthoudtandGitHub
Martin CarlbergandGitHub
Didier Korthoudtandcacaodev
Didier Korthoudt
Didier Korthoudt
Aparajita Fishman
Alexandre Wilhelm
Alexander Ljungberg
Aparajita Fishman
Antoine Mercadal
Darrell Walisser