Making scrollbar dimensions as style properties

I haven't looked at your code, but like I said, we normally don't have<br />styles that match property names in part because it isn't clear in MXML<br />whether you're referring to the style or property. In a local MXML<br />definition of a style value in an attribute, you are setting the style<br />on the object's style block and the expectation is that you can access<br />it via getStyle. This would not be true for a width attribute.<br /><br />Having styles get used first and property setters second is equivalent<br />to allowing type-selector values to override local attributes which is<br />backwards of typical style behavior.<br /><br />Tooling for a styles helper in FlexBuilder would also have to understand<br />this distinction, and if our styles helpers got smarter and used the<br />class definitions for allowed styles in a type-selector, it would<br />require [Style] metadata on the various classes which could lead to<br />further confusion.<br /><br />We already introduced left and top styles to distinguish them from x and<br />y properties. If anything, a good suggestion of alternative names for<br />width/height might be a better answer.<br /><br /> <br />-----Original Message-----<br />From: Sean Christmann [mailto:member@adobeforums.com] <br />Sent: Thursday, March 06, 2008 5:10 PM<br />To: flexsdk-dev@adobeforums.com<br />Subject: Re: Making scrollbar dimensions as style properties<br /><br />A new message was posted by Sean Christmann in<br /><br />Developers --<br /> Making scrollbar dimensions as style properties<br /><br />You don't *really* create a style called width, you only look to see if <br />values exist for it when styles are applied. Since all styles are simple<br /><br />Objects, you don't have to bake in definitions for them. If you run the <br />example I posted above with different values you'll see that the <br />resulting canvas respects both the styles that are applied first, and <br />the property setters that are applied second. It would be no different <br />then defining a background-color in both the stylename, as well as <br />locally in the mxml definition, the local mxml definition always wins.<br /><br /><!-- in main file --><br /><mx:Style><br />.myCanvas {<br />x: 20;<br />y: 20;<br />width: 20;<br />height: 20;<br />background-color: #FF0000;<br />}<br /></mx:Style><br /><local:TestCanvas x="100" height="100" styleName="myCanvas"/><br /><br /><!-- TestCanvas.mxml --><br /><mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml"><br /><mx:Script><br /><br /> override public function set styleName(value:Object):void{<br /> super.styleName = value;<br /> var classSelector:Object = StyleManager.getStyleDeclaration("." <br />+ value)<br /> var w:Object = classSelector.getStyle("width");<br /> var h:Object = classSelector.getStyle("height");<br /> var newx:Object = classSelector.getStyle("x");<br /> var newy:Object = classSelector.getStyle("y");<br /> if(w != null) width = int(w);<br /> if(h != null) height = int(h);<br /> if(newx != null) x = int(newx);<br /> if(newy != null) y = int(newy);<br /> }<br /><br /></mx:Script><br /></mx:Canvas><br /><br />Again this is a very halfassed and covers maybe 1/10 of usecases, but it<br /><br />illustrates the order of importance as well as the co-mingling of styles<br /><br />with properties.<br /><br />Sean<br /><br />Ryan Frishberg wrote:<br />> A new message was posted by Ryan Frishberg in<br />><br />> *Developers* --<br />> Making scrollbar dimensions as style properties<br />><br />> If you were to create a component with a style called width and a <br />> property called width, you could always call setStyle/getStyle for the<br /><br />> style one, and access the other one as a property in ActionScript.<br />><br />> However, when you want to use your component in MXML, say:<br />><br />> <MyComponent width="30" /><br />><br />> What does that "width" refer to -- the style or the property?<br />><br />> -Ryan<br />><br />><br />------------------------------------------------------------------------<br />> View/reply at Making scrollbar dimensions as style properties <br />> <a href=http://www.adobeforums.com/webx?13@@.3c0652f6/7><br />> Replies by email are OK.<br />> Use the unsubscribe <br />> <a href=http://www.adobeforums.com/webx?280@@.3c0652f6%21folder=.3c060fa3> <br />> form to cancel your email subscription.<br />><br /><br /><br />------------------------------------------------------<br />View/reply at <a href=http://www.adobeforums.com/webx?13@@.3c0652f6/8><br />Replies by email are OK.<br />Use the unsubscribe form at<br /><a href=http://www.adobeforums.com/webx?280@@.3c0652f6!folder=.3c060fa3> to<br />cancel your email subscription.

You don't *really* create a style called width, you only look to see if <br />values exist for it when styles are applied. Since all styles are simple <br />Objects, you don't have to bake in definitions for them. If you run the <br />example I posted above with different values you'll see that the <br />resulting canvas respects both the styles that are applied first, and <br />the property setters that are applied second. It would be no different <br />then defining a background-color in both the stylename, as well as <br />locally in the mxml definition, the local mxml definition always wins.<br /><br /><!-- in main file --><br /><mx:Style><br />.myCanvas {<br />x: 20;<br />y: 20;<br />width: 20;<br />height: 20;<br />background-color: #FF0000;<br />}<br /></mx:Style><br /><local:TestCanvas x="100" height="100" styleName="myCanvas"/><br /><br /><!-- TestCanvas.mxml --><br /><mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml"><br /><mx:Script><br /><br /> override public function set styleName(value:Object):void{<br /> super.styleName = value;<br /> var classSelector:Object = StyleManager.getStyleDeclaration("." <br />+ value)<br /> var w:Object = classSelector.getStyle("width");<br /> var h:Object = classSelector.getStyle("height");<br /> var newx:Object = classSelector.getStyle("x");<br /> var newy:Object = classSelector.getStyle("y");<br /> if(w != null) width = int(w);<br /> if(h != null) height = int(h);<br /> if(newx != null) x = int(newx);<br /> if(newy != null) y = int(newy);<br /> }<br /><br /></mx:Script><br /></mx:Canvas><br /><br />Again this is a very halfassed and covers maybe 1/10 of usecases, but it <br />illustrates the order of importance as well as the co-mingling of styles <br />with properties.<br /><br />Sean<br /><br />Ryan Frishberg wrote:<br />> A new message was posted by Ryan Frishberg in<br />><br />> *Developers* --<br />> Making scrollbar dimensions as style properties<br />><br />> If you were to create a component with a style called width and a <br />> property called width, you could always call setStyle/getStyle for the <br />> style one, and access the other one as a property in ActionScript.<br />><br />> However, when you want to use your component in MXML, say:<br />><br />> <MyComponent width="30" /><br />><br />> What does that "width" refer to -- the style or the property?<br />><br />> -Ryan<br />><br />> ------------------------------------------------------------------------<br />> View/reply at Making scrollbar dimensions as style properties <br />> <a href=http://www.adobeforums.com/webx?13@@.3c0652f6/7><br />> Replies by email are OK.<br />> Use the unsubscribe <br />> <a href=http://www.adobeforums.com/webx?280@@.3c0652f6%21folder=.3c060fa3> <br />> form to cancel your email subscription.<br />>

If you were to create a component with a style called width and a property called width, you could always call setStyle/getStyle for the style one, and access the other one as a property in ActionScript.

However, when you want to use your component in MXML, say:

<MyComponent width="30" />

What does that "width" refer to -- the style or the property?

-Ryan

Regarding collisions of style names with property names, it seems like rules can be written that handle this sort of thing. I know this example is extremely brief in accounting for all the ways styles are set on an object, but it seems like its possible to let the 2 co-mingle and still be able to resolve when the style is applied vs the property setter. Honestly I'm not looking to submit this as a patch, but its nice to know the angle for why it was avoided. It seems to me this model doesn't create much confusion and comes down to a speed vs convenience thing.

<!-- in main file -->
<mx:Style>
.myCanvas {
x: 20;
y: 20;
width: 80;
background-color: #FF0000;
}
</mx:Style>
<local:TestCanvas height="80" styleName="myCanvas"/>

<!-- TestCanvas.mxml -->
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml">
<mx:Script>
<![CDATA[
override public function set styleName(value:Object):void{
super.styleName = value;
var classSelector:Object = StyleManager.getStyleDeclaration("." + value)
var w:Object = classSelector.getStyle("width");
var h:Object = classSelector.getStyle("height");
var newx:Object = classSelector.getStyle("x");
var newy:Object = classSelector.getStyle("y");
if(w != null) width = int(w);
if(h != null) height = int(h);
if(newx != null) x = int(newx);
if(newy != null) y = int(newy);
}
]]>
</mx:Script>
</mx:Canvas>

Looking at existing styles, this seems more appropriate of a choice as a style for the ScrollBar class, since container and scrollcontrolbase (and by subclass listbase) let you define vertical and horizontal scroll styles already.

Matt - Getting access to your thought process would be really helpful, i suppose in the meantime I'll run ideas past this forum to see whether it would get a yay or nay when it came time to submit. I'd hate to spend too much time on something that would most likely be rejected.

Alex - Thats interesting and I wasn't aware that was the expected approach to skinning. I think I've been burned by this because I tend to use embedded assets (images and flash assets) for skins alot, and I've never seen the size of an embedded asset define the size of the component its being applied as a skin to.

In general, we try not to have styles that collide with property names,<br />so that's why we'd reject styles for x,y,w,h. And those are baked as<br />properties in the player so we have little chance of changing that.<br /><br />You're right that we need other "guidelines". I'll ponder that for a<br />bit.<br /><br />-----Original Message-----<br />From: Matt Chotin [mailto:member@adobeforums.com] <br />Sent: Wednesday, March 05, 2008 6:48 PM<br />To: flexsdk-dev@adobeforums.com<br />Subject: Re: Making scrollbar dimensions as style properties<br /><br />A new message was posted by Matt Chotin in<br /><br />Developers --<br /> Making scrollbar dimensions as style properties<br /><br />I'm not sure we have a design philosophy document for the existing<br />components, but as we begin doing work on the components that support<br />our "design in mind" agenda I think you will see more of those (and they<br />would begin to live on the open source site).<br /><br /><br />Matt<br /><br /><br />On 3/5/08 2:39 PM, "Sean Christmann" <member@adobeforums.com> wrote:<br /><br />A new message was posted by Sean Christmann in<br /><br />Developers --<br /> Making scrollbar dimensions as style properties<br /><br />Also, this kind of raises a bigger question about the framework<br />regarding what is acceptable and what isn't. For instance, I imagine you<br />guys would reject a patch that adds "width", "height", "x", and "y"<br />style properties to UIComponent, but I'm assuming thats because you<br />already decided to leave them out? Is there any documentation other the<br />Coding Conventions doc that go into framework design conventions?<br /><br />________________________________<br />View/reply at Making scrollbar dimensions as style properties<br /><a href=http://www.adobeforums.com/webx?13@@.3c0652f6/0><a href=http://www.adobeforums<br />.com/webx?13@@.3c0652f6/0><br />Replies by email are OK.<br />Use the unsubscribe<br /><a href=http://www.adobeforums.com/webx?280@@.3c0652f6!folder=.3c060fa3><a href=http:/<br />/www.adobeforums.com/webx?280@@.3c0652f6!folder=.3c060fa3> form to<br />cancel your email subscription.<br /><br /><br /><br /><br />------------------------------------------------------<br />View/reply at <a href=http://www.adobeforums.com/webx?13@@.3c0652f6/2><br />Replies by email are OK.<br />Use the unsubscribe form at<br /><a href=http://www.adobeforums.com/webx?280@@.3c0652f6!folder=.3c060fa3> to<br />cancel your email subscription.

ScrollBar is supposed to size to its skins. If it doesn't that's the<br />bug. In general there is a size-to-content/skins philosophy so there<br />aren't many styles that dictate sizes.<br /><br />-----Original Message-----<br />From: Matt Chotin [mailto:member@adobeforums.com] <br />Sent: Wednesday, March 05, 2008 6:47 PM<br />To: flexsdk-dev@adobeforums.com<br />Subject: Re: Making scrollbar dimensions as style properties<br /><br />A new message was posted by Matt Chotin in<br /><br />Developers --<br /> Making scrollbar dimensions as style properties<br /><br />I'm trying to get more of the devs on the list to have this discussion.<br />In the meantime, the hardcoded value is not exactly an oversight but not<br />my first choice. So something that addressed this would be worth<br />investigating. However, you'd need to keep in mind that we'd need to<br />consider whether we should apply this to the list classes as well, and<br />there'd be a huge amount of testing that would go into accepting a patch<br />like this. So it wouldn't necessarily be accepted quickly.<br /><br />Matt<br /><br /><br />On 3/5/08 2:21 PM, "Sean Christmann" <member@adobeforums.com> wrote:<br /><br />A new discussion was started by Sean Christmann in<br /><br />Developers --<br /> Making scrollbar dimensions as style properties<br /><br />One thing about scrollbar thats always annoyed me is that the thickness<br />for scrollbars is hardcoded to 16 pixels as a const. The scrolltrack,<br />scrollthumb and scroll arrow skins also reference this constant for<br />determining their size. The question is, is this intentional and would a<br />patch that turns these into style properties be rejected? I would like<br />to bake the styles into Container and ScrollControlBase as the style<br />properties "horizontalScrollBarThickness" and<br />"verticalScrollBarThickness".<br /><br />________________________________<br />View/reply at Making scrollbar dimensions as style properties<br /><a href=http://www.adobeforums.com/webx?13@@.3c0652f6><a href=http://www.adobeforums.c<br />om/webx?13@@.3c0652f6><br />Replies by email are OK.<br />Use the unsubscribe<br /><a href=http://www.adobeforums.com/webx?280@@.3c0652f6!folder=.3c060fa3><a href=http:/<br />/www.adobeforums.com/webx?280@@.3c0652f6!folder=.3c060fa3> form to<br />cancel your email subscription.<br /><br /><br /><br /><br />------------------------------------------------------<br />View/reply at <a href=http://www.adobeforums.com/webx?13@@.3c0652f6/1><br />Replies by email are OK.<br />Use the unsubscribe form at<br /><a href=http://www.adobeforums.com/webx?280@@.3c0652f6!folder=.3c060fa3> to<br />cancel your email subscription.

I'm not sure we have a design philosophy document for the existing components, but as we begin doing work on the components that support our "design in mind" agenda I think you will see more of those (and they would begin to live on the open source site).<br /><br />Matt<br /><br /><br />On 3/5/08 2:39 PM, "Sean Christmann" <member@adobeforums.com> wrote:<br /><br />A new message was posted by Sean Christmann in<br /><br />Developers --<br /> Making scrollbar dimensions as style properties<br /><br />Also, this kind of raises a bigger question about the framework regarding what is acceptable and what isn't. For instance, I imagine you guys would reject a patch that adds "width", "height", "x", and "y" style properties to UIComponent, but I'm assuming thats because you already decided to leave them out? Is there any documentation other the Coding Conventions doc that go into framework design conventions?<br /><br />________________________________<br />View/reply at Making scrollbar dimensions as style properties <a href=http://www.adobeforums.com/webx?13@@.3c0652f6/0><a href=http://www.adobeforums.com/webx?13@@.3c0652f6/0><br />Replies by email are OK.<br />Use the unsubscribe <a href=http://www.adobeforums.com/webx?280@@.3c0652f6!folder=.3c060fa3><a href=http://www.adobeforums.com/webx?280@@.3c0652f6!folder=.3c060fa3> form to cancel your email subscription.

I'm trying to get more of the devs on the list to have this discussion. In the meantime, the hardcoded value is not exactly an oversight but not my first choice. So something that addressed this would be worth investigating. However, you'd need to keep in mind that we'd need to consider whether we should apply this to the list classes as well, and there'd be a huge amount of testing that would go into accepting a patch like this. So it wouldn't necessarily be accepted quickly.<br /><br />Matt<br /><br /><br />On 3/5/08 2:21 PM, "Sean Christmann" <member@adobeforums.com> wrote:<br /><br />A new discussion was started by Sean Christmann in<br /><br />Developers --<br /> Making scrollbar dimensions as style properties<br /><br />One thing about scrollbar thats always annoyed me is that the thickness for scrollbars is hardcoded to 16 pixels as a const. The scrolltrack, scrollthumb and scroll arrow skins also reference this constant for determining their size. The question is, is this intentional and would a patch that turns these into style properties be rejected? I would like to bake the styles into Container and ScrollControlBase as the style properties "horizontalScrollBarThickness" and "verticalScrollBarThickness".<br /><br />________________________________<br />View/reply at Making scrollbar dimensions as style properties <a href=http://www.adobeforums.com/webx?13@@.3c0652f6><a href=http://www.adobeforums.com/webx?13@@.3c0652f6><br />Replies by email are OK.<br />Use the unsubscribe <a href=http://www.adobeforums.com/webx?280@@.3c0652f6!folder=.3c060fa3><a href=http://www.adobeforums.com/webx?280@@.3c0652f6!folder=.3c060fa3> form to cancel your email subscription.

Also, this kind of raises a bigger question about the framework regarding what is acceptable and what isn't. For instance, I imagine you guys would reject a patch that adds "width", "height", "x", and "y" style properties to UIComponent, but I'm assuming thats because you already decided to leave them out? Is there any documentation other the Coding Conventions doc that go into framework design conventions?