One of the underpublicized changes we made in v1.10 was the inclusion of a great new
SC.SplitView. The existing view was broken in some key ways, and the new view, which had been marinating in an experimental framework for some time, was snazzy and stable. We decided that few enough people had gotten
SplitView working in their production apps that we could afford to swap in the new view, but it’s API-noncompliant and we should have made a bigger deal about it. Sorry about that!
Luckily, updating to the new
SplitView is easy. The most important thing to do is mix
SC.SplitChild into your
bottomRightView. If you want your views to have an initial height or width, depending on
layoutDirection, just set the
size property (whole-number pixel values only). The best news is that a
SplitView can now handle an arbitrary number of sections – you specify them in its
childViews array, just like a normal view.
Full documentation for the new SC.SplitView available here; more information about the new SplitChild mixin available here.
The first patch release of SproutCore 1.10 is now available. This update includes the following fixes:
- Allows inline text fields to work with automatic child view layout.
SC.Module loading for IE11 and future versions.
SC.Drag cancellation with the Escape key to call dragEnded for cleanup.
- Added a retina image for the default theme of
- Fixed the touch selection of
SC.CollectionView to prevent an item from appearing deselected when touched twice in a row.
- Fixed the insertion point code for
SC.GridView in order to show an insertion view when dragging and dropping onto grid views.
- Fixed an issue with
SC.ScrollView which would cause the HW accelerated content offset to be incorrect when the content view re-renders.
- Improved the deceleration animation of
SC.ScrollView for better performance.
- Fixed an error in the deceleration animation of
SC.ScrollView that could throw an exception when stopped very quickly.
- Changed the
SC.EmptyTheme class name to
sc-empty-theme to avoid conflicts with the use of
sc-empty. This fixes a bug where
SC.ProgressView would always appear empty when used with the empty theme.
- Fixed incorrect behavior of
SC.Statechart sendEvent that allowed events to be sent during a state transition.
- Fixed a bug that prevented queued events due to a state transition from being sent when the state transition was complete.
- Fixed a caching problem with
SC.routes that would allow the location property to be incorrect depending on how it was changed.
- Fixed a regression in determining the OS of Linux and Android in
We’re pleased to announce that Greg Fairbanks and Nicolas Badia have accepted becoming SproutCore Committers. These two have been especially active in submitting fixes and improvements to the framework and are great examples of persevering through the process of vetting pull requests with the core team in order to ensure each change meets the high standards of SproutCore. It can be a tedious process to get something approved, but the end result is better code that stands the test of time. Now that they are official Committers this will become even easier for them.
For those that aren’t sure of the difference between Committers and Reviewers, Committers are actually required to work in their own branches in the repo and submit every change as a pull request to be accepted by a Reviewer. The Reviewers are allowed to make direct fixes, but will most likely submit anything at all substantial as a pull request too in order to get a few other Reviewers’ feedback and acceptance. Both roles also include the responsibility to try to move the outstanding issues and pull requests towards a resolution.
As you can tell from the above description, both roles are a lot of work and it takes people with a real dedication to the project to accept what can be a thankless and demanding task, so please take a moment to catch all of these people on #sproutcore and firstname.lastname@example.org and show them your support.
The SproutCore team is very pleased to announce the final release of SproutCore version 1.10.0. This version is the fastest, most feature-rich and most stable version of SproutCore to-date and includes several new additions and improvements to make development with SproutCore even better and to make SproutCore apps that much more impressive. For a quick introduction to the many changes in version 1.10, please check out the official press release.
For those wishing to install SproutCore for the first time, please visit http://sproutcore.com/install/ for instructions. If you are upgrading from a previous version of SproutCore, simply run the following:
gem update sproutcore
If you have any trouble installing or upgrading to 1.10, be sure to visit the mailing list email@example.com or the IRC channel #sproutcore for support. As always, the team and community are here to help!
Highlights of Version 1.10.0
In this release we dug deep into the core of SproutCore to improve the entire development and runtime experience from start-to-finish. This includes clean-ups of the developer API to improve consistency and memorability; brand new features for automatic layout, transition animations and live updates; extensive internal architectural refactors to boost speed and reduce memory consumption; and more.
Upgrading your project to 1.10 is a no-brainer – even if you never get around to adding a little easy flare with view transitions, you get a free performance boost from the plugged memory leaks and Tyler’s great work refactoring SC.View. 1.10 also makes some changes under the hood which take some previously not great practices and turn them into warnings or breaks. These are good changes, and enable a lot of the efficiency gains that we packed into this release, but there are some previously-common practices that trigger some new developer warnings, so I want to go over what’s causing them and how to fix it.
You should read this post if you’re receiving unexpected developer warnings to the effect of “
Developer Warning: invokeOnce called outside of the run loop. This can cause problems in production code if not addressed.” I’m going to cover these possible causes of this issue:
- Misusing .create() when defining your view layer
- Using SC.MenuPane.create() when defining your view layer
- Using SC.FileFieldView ever
- Handling browser events directly, without setting up a run-loop