Alex, this fix seems reasonable to me. I will take a look at how the iOS and Android versions react to this change when I get a chance. Worst case, we can ship with a (minor) defect in the new skins.
Thanks, Om On Jan 15, 2015 2:46 AM, "Alex Harui" <aha...@adobe.com> wrote: > I checked in a “workarouund”. It might have broken IOS and Android > versions of SpinnerLists. Someone who knows better should take a look. > > The key issues is that there has always been a default accentColor for all > of Flex, but SpinnerList was not using it until Om fixed it to get > accentColor for at least the IOS skins. > > I added a “useAccentColor” style and set it to false to have the > SpinnerListItemRenderer ignore the accentColor when selected. That way > the old behavior of ignoring accentColor can be preserved. IOS > SpinnerLists sets useAccentColor to true. > > For DateSpinner, I added some png.xml files for the chinese characters > based on 4.13.0. That enabled several tests to pass on 4.14.0. The rest > passed when I adjusted the DateSpinner’s ItemRenderer now that its base > item renderer is trying to think about accentColors. > > I may have limited time or no time to fix any more issues until Friday. > > -Alex > > On 1/14/15, 10:12 AM, "Alex Harui" <aha...@adobe.com> wrote: > > > > > > >On 1/14/15, 9:47 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: > > > >>If it breaks tests, at this point I suggest we (you?) revert that > >>change on the 'release' branch. That way, it lives on to be fixed on > >>the develop branch, but we'll be a step closer to a passing test > >>suite. > > > >Well, I’m assuming that Om made the change so that the IOS and Android > >skins would look ‘right’. We could change the default skin to remain > >black when selected, or we can just say “sorry about backward > >compatibility, but we think it is nicer this way”. And you can change > >accentColor to get back to black. > > > >-Alex > > > >
