11 Commits
Author SHA1 Message Date
Aparajita Fishman afd5925499 Fixed: _CG and _CP macros were confusing and could degrade performance
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.
2013-03-13 12:22:10 -04:00
Aparajita Fishman 3af2314a70 Fixed: sheet resizing displayed incorrectly
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
2013-03-12 10:20:14 -04:00
Aparajita Fishman 887421c9fa Fixed: window content view overlapped window frame
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
2013-02-25 17:50:12 -05:00
Aparajita Fishman a736bb4e93 fix (CPWindow): prevent empty content view when resizing a window
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
2013-02-24 22:44:29 -05:00
Aparajita Fishman 1a26fbf6f4 Rework CPWindow cluster so CPWindow's code is in its file 2013-01-30 22:35:21 +08:00
Aparajita Fishman 7c831fa19d capp_lint flags deprecated CPPoint/Rect/Size types/functions
- Changed to corresponding CG types/functions in all files
- Fixed some demo app bugs
2013-01-19 16:51:56 +07:00
Antoine Mercadal 7a419c262e Add missing @class 2013-01-18 10:37:51 -08:00
Alexandre Wilhelm 18d0cf51ef Removed unused code 2013-01-10 17:32:47 -08:00
Alexandre Wilhelm 5e1c6ae30d Added class method for the title height 2013-01-09 16:01:51 -08:00
Alexandre Wilhelm 6561e4f84e Init of Aristo2 2013-01-03 11:22:46 -08:00
Alexander Ljungberg aa17d8c700 Pull up window title code to a superclass for reuse. 2012-08-15 01:38:25 +01:00