Something like UITableView on iOS.

Use-case: If I change a button's label to a longer string, the button should get bigger, unless I previously told the button to be a specific size.

Phase 1: Make it work by performing full validation on children to measure, similar to how the initial auto-size works now. Children should not be explicitly sized unless their parent is explicitly sized (hopefully, that's possible). DONE

Phase 2 (maybe): Expose a smarter measurement that doesn't do a full validation, but only calculates the ideal dimensions.

Hi,
I think you should add a method like this one in ListCollection
because you usually don't know exactly the exact objet to remove from a list
say for example you have a ListCollection of players
you want to remove them when they disconnect :
your going to remove them by their id or name
not knowing the others properties of the user.

var item:UserListItem = new UserListItem(name);
item.data = { name:name, user:userObj.getInt('id'), status:userObj.getUtfString(GameState.GAME_STATUS) };
_userList.push(item);
// and later
_userList.removeItem(_userList.getItemByProperty('name', uname));

it usually helps so you don't have to keep 2 datasources one for the data and the other one for the display list.

      /**
     * Return an item by a property
     *
     * @param $property  :String
     * @param $value      :*
     *
     * @return item  :ListItem
     */
    public function getItemByProperty($property:String, $value:*):*
    {
        var item:*;
        var l:int = data.length;

        for (var i:int = 0; i < l; ++i)
        {
            item = data[i];

            if (item.data[$property] === $value)
            {
                return item;
            }
        }

        return null;
    }

The current inheritance is a result of being created long before the rest of Foxhole existed. Benefits of this change:

• They'd be resizable. Currently, the dimensions must be hard coded or they must use stageWidth and stageHeight. This could allow side by side navigators. DONE
• It simplifies the APIs for Screen (it has a similar lifecycle to FoxholeControl already, but the template functions have different names) DONE

Things to think about:

• Optional clipping will be needed. DONE
• Transitions need to be updated. DONE
• Should Screen and/or ScreenNavigator continue to support automatic stage sizing?
  • Yes, ScreenNavigator will automatically size to the stage. Screen will be sized based on ScreenNavigator. DONE

Should be customizable so that it can be interactive with increment and decrement buttons for desktop apps or just a visual cue for mobile apps.

Placeholder text that is removed when the TextInput has text, or if it has focus.

On iOS and Android, an item renderer won't react to a touch right away just in case the user is going to scroll. You need to hold for a moment before it highlights. SimpleItemRenderer should do the same.

Currently, while item renderers are reused, the assigned items may change during scrolling even if the same item exists. Since rendererMap exists, maybe it can be used to reactivate a renderer with the same item to avoid redrawing.

Enforced minimum dimensions. Still allows auto-sizing.

Feature request:

I know you initially designed these controls for mobile, but some users might be deploying their apps on both desktop and mobile and it might be nice to also support optional hoverSkins when running on desktop. Thanks

Identical to the recent bug with ListDataContainer's renderer_touchHandler

Create content in a PickerList larger than can currently be displayed, any non-zero scroll position causes a proper selection but the popup won't close.

Applying a similar technique to PickerList's list_onItemTouch like:

if(this.parent.y == 0) //TODO: fix this
{
location.y += list.verticalScrollPosition;
}
if(displayRenderer.hitTest(location))
...

seems to do the trick here as well...

Feature request:

Current PopUpManager works great for PickerList, but it really is targeted for a mobile (smaller screen) display going fullscreen based on stage size.
On tablets or desktops it would want to work more like a limited size clipped popup list aligned and positioned relative to the PickerList button.

If you don't think you will get around to implementing this soon, could it allow a custom class specified as the active PopUpManager with an IPopUpManager interface to conform to?

Thanks!

Similar to how ToggleSwitch has different on and off skins.

See iOS slider, where left side is highlighted blue and right side is plain white/gray.

Has a viewPort property, similar to Scroller, to define what is displayed in the callout. Callouts don't have scrolling by default, though. The viewPort should define those behaviors.

Needs a "tail" to indicate where it originated.

Vertical and horizontal touch-based scrolling container.

Minor negative display issue, but with SimpleItemRenderer being a subclass of button and with an active selection skin, if you start a scroll by initially hitting the currently selected item, the selection flickers momentarily until you start scrolling.
I assume because the button takes over its own change state eventing even if the list container actually delays changing or modifying the selection if a scroll action takes place instead of a simple click to select.

If I use a custom IListItemRenderer built with a labal and background skin I can prevent the initial click flicker but is there a way to modify the behavior of SimpleItemRenderer acting as a 'renderer only' to circumvent the button's default click to select?
(I realize there really isn't a good or necessary way of treating downSkins any differently as they are somewhat inappropriate for an item renderer)

Flash Player doesn't support StageText, so we get to reimplement the same type of fallback that desktop AIR provides.

Latest github drop.
I've create a List with a data container of about 20 items. I display the List with clipContent=true showing about 9 items.
Selection clicks work fine on the visual items when scroll position is 0. As soon as the list is shown in any significant non-zero scroll position, clicking anywhere in the list doesn't properly trigger selection changes on the items anymore. Scrolling back to zero position scroll allows clicking and selection changes again on the first visible items in the list.

In addition to the one that applies to all sides. Probably want to rename it defaultPadding to follow convention with other default values.

Not an issue - just couldn't see anywhere better to ask - feel free to delete if too busy!

Really intrigued so was wondering if there are screenshots / movies anywhere?

• Layout tabs horizontally (and maybe vertically too).
• Use a ToggleGroup to control the selection.
• tabProperties for all tabs.
• firstTabProperties and lastTabProperties to optionally customize first and last tabs differently from others.

To workaround XMLList limitations.

Returns a display object.

Probably possible to implement with ScrollContainer, but maybe a specialized toolbar for a row of buttons and/or other controls.

Listen for when new controls are added to the stage and pass in property values based on the class or an id of some sort.

Or maybe it should be a part of individual components that use the collections? This would allow multiple components to share the same collection while having different filters.

There are cases where I would like to use a liveDragging slider because I might have a label showing the value next to the slider, but I still might want to delay updating other components of this onChange only after the dragging is finished.

So it would be nice if the isDragging was exposed as a getter so in a default onChange callback I can still have some components update during a livedrag but some only update at the end of the drag.

Reproduced on iPad 1.

Needs to be applied to scrollRect.x and scrollRect.y before they modify scrollRectOffsetX and scrollRectOffsetY.

Possible optimization or simplification.

Support some basic layout implementations (vbox, hbox, tile) with an option to implement custom layouts through an interface.

If you have a List with clipped content and scroll all the way past the last item so either the last item is at the top of the clipped view or even past it, the List will not snap back and will get stuck. In adl a click anywhere in the list causes it to snap back while on an actual device like an iPad or iPhone tapping will not fix the list and there is no workaround but to quit and restart the app.

Feature request:

I can use the defaultTextFormat no problem, but even Apple's default toggleswitch uses an inverse color scheme for the text, and since the color is bundled with textFormat, it might be nice to optionally offer separate onTextFormat and offTextFormat and if not set, default to the defaultTextFormat that exists now.

Uses StageText. Maybe fallback to a TextField on platforms where StageText isn't supported?

• This will be a situation where bitmap fonts are not used.
• Needs a background skin and disabled background skin.

If smoothing is turned off, and it's snapped to a sub-pixel, it'll look weird.

If the TextInput moves indirectly, the StageText won't follow. TextInput should draw the StageText to a bitmap and swap the two as needed.

Already hacking the name property for this a bit for sub-components, but we need a more robust way to add, remove, and check for multiple classes/names.

These can be used in AddedWatcher sub-classes to conditionally initialize skins. Eventually, they could be useful in a selector query system.

With the new scale property of textures (for retina displays etc...) it looks like the base value needs to include the division by the texture's scale (like the latest Starling BitmapFont uses for the other properties of the bitmap font)

For groups of items that can be separately toggled.

I actually have a real world set of cases where I use a scale-9 based skin that is white/greyscale based and want to set a color property that then gets applied to the nine child Images (similar to the smoothing property you currently expose)

(think custom slider skins for RGB sliders in a color panel)

The default color would have to be 0xffffff like Quad since it needs to support changing in an additive way though not everyone may want it set by default so maybe you want a way to expose the child images directly or a setter-only color property that only optionally gets applied when called...

The one other area of the framework that needs updated when you are ready to support the latest Starling.contentScaleFactor feature is when using setScissorRectangle

context.setScissorRectangle requires rectangle position and dimensions in pixels.

The two cases of setScissorRectangle in the Image and Sprite subclasses simply need to multiply the helperRect by current scale.
(see the latest Starling RenderTexture class for how it uses scale in its setScissorRectangle)

In the case of Image, it should probably get the scale from mTexture.scale (like RenderTexture), but in the case of Sprite, it will probably have to just ask for Starling.contentScaleFactor

I locally added this scale factor in these two places in my app and deployed and tested on retina displays on the new iPad and an iPhone 4 and the scrollRects in List and ToggleSwitch worked great once this scale factor was added to the rect for setScissorRectangle,

Currently, if you set isSelectionRequired = false ToggleGroup will not allow a deselection of an item.
It still wants to preserve the item that is clicked even if you are trying to toggle its state to not selected.
You should be allowed to have this clicked item deselect and have no active selected index if isSelectionRequired = false