Wednesday, October 28th, 2009

SproutCore 1.0 gets closer; new demos too

Category: SproutCore

<p>SproutCore 1.0 has its first release candidate that you can grab via gem install sproutcore.

sproutcoredemos

There are also new demos to play with and other interesting features:

Animation Layer

I’ve been working on a mixin to add animation to SproutCore views.

The current version only works for layout properties, and does not yet work for centerX and centerY properties (they used to work, but some of the performance optimizations have made it slightly more tricky—I’ll be adding it back soon, though).

I decided to see how fast the code was in different browsers. The tests were done using a test application which generated a specified number of views, and then, once per second, updated a “frames per second” display. The measuring is somewhat subjective, as I have to deduce, based on consistency (or lack thereof) in the numbers, what the frame rate actually is. For the most part, they were pretty consistent, but the WebKit browsers at really low numbers of views (and really high frame rates) could be quite inconsistent at times.

Sprouting—Automated Spriting for SproutCore

A Python script that generates CSS like:

  1. .set-name .icon-name.icon, .set-name .icon-name.icon { /* CSS */ }

which you can work with via:

javascript
< view plain text >
  1. ImageView.design({
  2.   layout: { left: 100, top: 100, width: 64, height: 64 },
  3.   value: "common refresh-64 icon" // using SproutCore's built-in className support for spriting
  4. }
  5.  
  6. View.design({
  7.   layout: {left: 100, top:100, width:256, height: 256},
  8.   classNames: ["common"], // the theme
  9.   childViews: ["styledView"],
  10.   styledView: ImageView.design({
  11.     layout: { left: 100, top: 100, width: 64, height: 64 },
  12.     value: "refresh-64 icon" // using SproutCore's built-in className support for spriting
  13.   })
  14. })

Related Content:

Posted by Dion Almaer at 6:40 am
7 Comments

++---
2.1 rating from 73 votes

7 Comments »

Comments feed TrackBack URI

Why every library has to be totally non-accessible ?
I can’t use keyboard navigation, what happens if the images fails to load, I can’t properly zoom in text-only mode, …
People should really focus more on these points, instead of building the same kind of libraries over and over again.

Comment by Yves — October 28, 2009

Agreed, especially from a release candidate I would expect it to be more accessible. There seems to be some sort of keyboard navigation though; it is, however, not really clear what item currently has focus.

It seems that most projects focus on features first, exceptions later. YMMV, but I think it is a reasonable approach. Most features seem to be complete (for now), so I suppose now is the time for accessibility and exceptional cases such as images failing to load etc.

Comment by MartijnHoutman — October 28, 2009

Yves, interesting point. Let me give you a very brief response on this. Sproutcore is currently imitating the same keyboard navigation as the Mac has enabled by default (only jump between textfields, you can change this in macs in system preferences).

I did some work to enable keyboard navigation through all the controls, using tab. Also I did make sure that all controls (buttons, sliders, etc) respond to arrow keys, returns,etc if they have focus. I would put some of my time to put together a demo.

As a final note, this is a very hard problem as every browser or platform behaves in a different way and there is questions like: should the library imitate the platform? or should we force users into what we believe is a better experience?. when should a textfield loose focus?

My conclusion so far is that nobody has a final answer on this questions, but I would like to hear what people have to say about this.

(excuse my english, if I made any mistakes)

Comment by juanpin — October 28, 2009

I don’t understand the “load the data dynamically” models like the “big_list” demo. First of all, the largest dataset for the demo is 1,000 items. Guess what, loading a table with 1,000 cells would be faster, and it would scroll smoothly. So then the response will be “What if there are 100,000 items?” and the answer is: No one scrolls through a list of 100,000 items. Ever. Large datasets require advanced searching capabilities, not advanced scrolling. It’s a solution in search of a problem.

Comment by rubley — October 28, 2009

where is the dropdown ? Well not impressive… did anyone check in FF3 …

Comment by qualityking — October 29, 2009

The demos are full of bugs in FF3. I guess they aren’t as close to 1.0 as they seem to think…

Comment by daanlib — October 29, 2009

My blog response to the Sproutcore project http://lukesh.wordpress.com/2010/01/02/thoughts-on-sproutcore-and-app-dev-in-general/

Comment by lukesh — January 2, 2010

Leave a comment

You must be logged in to post a comment.