You're viewing all posts tagged with sproutcore
Sliders: Themed.

Sliders: Themed.

Pointer buttons, too!

Pointer buttons, too!

Capsule buttons!

Capsule buttons!

File this under “Amazingly Easy” when using a new modification to Chance.

LESS, Easier Chance + Ace 2.0

Ace 2.0 theme compiler, Chance, just gained a few extra goodies: it post-processes with LESS, has an extra directive, and is now easier to invoke.

Before you can use it, you’ll have to install LESS (in addition to Chance’s other prerequisites), but that is easy: “sudo gem install less”. Now you can build by simply going to the Ace 2.0 folder—sproutcore/themes/sc_ace—and running “./build”

In addition to LESS, a new Chance directive has been added: @theme. It maintains a stack of class names to be added to any view.

What do LESS and this new directive provide?

Take a look at this before and after (ironically, in reverse order): http://gist.github.com/354114

As you can see, @theme is being used to keep track of the “sc-small-size” class name, and LESS allows nesting.

Together, they make the CSS dramatically more readable.

Styling a new Ace 2.0 button size (art and sample controls app already set up).

And now I decided to tweak buttons a bit more. Specifically, the button sprites I have not already tweaked. They were a bit off, due to my tweaks on the first set. The bigger issue here, however, is that I NOW HAVE TO TWEAK ABOUT 1000 BUTTON-RELATED IMAGES!
Partial list needing changing: Checkbox Normal, Checkbox Selected, Checkbox Mixed, Segmented Selected, Segmented Normal, Select Normal and Select active.
Basically, the selected and active states of any button that has a squarish shape.

And now I decided to tweak buttons a bit more. Specifically, the button sprites I have not already tweaked. They were a bit off, due to my tweaks on the first set. The bigger issue here, however, is that I NOW HAVE TO TWEAK ABOUT 1000 BUTTON-RELATED IMAGES!

Partial list needing changing: Checkbox Normal, Checkbox Selected, Checkbox Mixed, Segmented Selected, Segmented Normal, Select Normal and Select active.

Basically, the selected and active states of any button that has a squarish shape.

New version of Sample Controls app! Yay!

Segmented view in the new theme.

Segmented view in the new theme.

Help Wanted: New Ace Theme and Renderers

Two features of the next SproutCore are finally ready to be worked on (by those aside from me): Ace 2.0 and Renderers. They are in SproutCore’s master branch, ready for you to hack on.

Ace 2.0 (demo here) is the new SproutCore theme. Unfortunately, it is unfinished. Doubly unfortunately, there are a lot of things to theme. So, help would be much appreciated.

It is easy to contribute artwork: fork SproutCore (the theme is in themes/sc_ace), create a PSD, drag in elements from existing PSDs (to ensure styles remain consistent), do your thing, submit a pull request.

If you don’t need to change the DOM for a control, then it is also easy to actually theme the control: in your fork, just create a CSS file in a properly named folder, put in some @view() and sprite() magic (see the other CSS files, or Colin’s excellent write-up on Chance), run Chance, and Boom! It is themed. Submit a pull request. For your convenience, Chance is actually in the Ace theme folder (under the chance directory); assuming you have RMagick installed (the toughest part), you can run “chance/chance.rb ace.light” to generate the theme.

But, there is a slight complication. Some controls’ current DOM is, shall we say, not appropriate for the new theme. Why? Well, let’s take ButtonView as an example: old Ace’s ButtonView was structured like this: <a><span><label>(Text)</label</span></a>. This means that the different slices overlapped each other. Okay, well, that’s fine in some circumstances.

It is not fine for Ace, which uses images with semitransparent parts, such as borders. When the slices overlap, they’d look awful. Unfortunately, we can’t easily change the DOM in the view itself, as that would risk breaking other themes (including the original Ace).

The solution is Renderers. Renderers are objects that handle rendering for views, but which are not defined in the views themselves; instead, they are defined in the themes. Using this method, current themes could use the default renderer, but Ace 2.0 could override with a different renderer. What’s even better is that further themes could override with their own renderers for spectacular results. In short, DOM can now be custom.

But there is a catch here as well: the controls have to be converted to use renderers. So far, there are only a few: button, control, panel, and title. All controls should eventually be converted to use renderers. For some, it is not very urgent: CheckboxView, for instance, works fine with the new theme and the current DOM. It should still be converted, but it is not necessary for the completion of Ace 2.0.

Others are a bit more immediately required: SegmentedView, for example, needs conversion (I am working on this, but if someone wants to beat me to it, they should feel free).

Any assistance you can provide with Ace 2.0 or converting controls to renderers (even only the default empty_theme renderers) would be greatly appreciated.

For more information:

Ace Contributors’ Guide

Themes Overview

SC.Renderer Class Overview

SC.Renderer Class Reference

Complex Renderer Case: Segmented Renderer

Automatic Resizing in SproutCore

I have just made a simple example of how you can make an element automatically resize based on its text content in SproutCore. For instance, you can make a text field expand as you type, or a button automatically resize with its title (for instance, like the buttons in iPhone’s toolbar). The respository is on GitHub: http://github.com/ialexi/auto_resize

So, how does it work?

It’s rather simple. Whenever the text changes you have to measure the text. There is a function in SproutCore that will do this for you: SC.metricsForString. What about font sizes and such? The function takes an example element as an input parameter, and can copy the calculated styles from it.

The measuring code is all in the main_page.js file, and consists of three functions (two elements are being measured, however, bringing it to a total of six measuring functions).

  • value/titleDidChange: a simple observer to detect when the title changes, as obviously, we would need to adjust the size in this case. It calls autoResize.
  • didCreateLayer: We have to have the layer (the DOM element backing the view) to be able to pass the “example element” to SC.metricsForString. As the value/title could be changed without this layer being present, we need to know when the layer is created.
  • autoResize: Very simply gets the layer, calls SC.metricsForString, and adjusts the width. The only sophisticated part is the padding it adds. For the text field view in the example, it adds a constant 10px. For the ButtonView, it makes sure it is at minimum the size of the ButtonView’s “titleMinWidth” property, and adds 16 (for some space on either side).

The whole file, containing two automatically resizing elements, is about eighty lines of code, including comments and whitespace. In fact, here it is:

Clone it and try it out!

(Incomplete) Todo List for Ace

Growing Todo List:

  • SliderView
  • List Views
    • bg color for selected items—currently is gray, should probably be blue
    • Anything special needed to make icons, checkboxes, unread count or whatever indicator show up properly?
  • Grid View? (doesn’t appear to have much of a style at the moment—should that be changed?)
  • Disclosure Buttons
  • Capsule buttons
  • Indeterminate progress bar
    • May be impossible to do with rounded corners unless pattern fades at edges
  • SegmentedView
    • Start with PSDs for Button; they should use very similar (if not the same) styles.
  • WellView
  • PickerPane, especially PickerPane.pointer
  • AlertPane
    • Set up icons (redesign some for new Ace?)
  • Alternate control sizes? (I’m not sure what the alternate sizes are supposed to be at the moment)
  • Checkbox corners look rough; can this be fixed?
  • Progress bar tracks are too dark
  • Selected style for menu items (for instance, in SelectView)
  • Testing of buttons, radio buttons, and checkboxes with icons

Optional goodies:

  • Revise ButtonView so it will have the option of creating true three-part buttons where the PIECES DON’T OVERLAP!!! This would allow semitransparent borders, which would help buttons work on a variety of backgrounds.
  • Make things use semitransparent borders (see above); test on many backgrounds.

Needing Discussion:

  • Icons. Keep same? Make sedate? Some of each?

There may be other things too…