Re: Missing Spark Components List

"I pushed for Adobe to remove HGroup and VGroup before the release of spark as I saw these as absolutely pointless" The point is to have the component type that you need ready for you when you need it. Don't re-invent the wheel every time. Some of these are easy to make *for us*. Things like VGro

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

as Re: s:Spacer (was Re: Missing Spark components)) I think it's fine to have a rich set of skins that you can use if you want all of those styling attributes. I would hate to penalize every project though. It still seems to me that, like HGroup and VGroup, we can extend all of these classes and put

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

>one of the main roadmap objectives (someone confirm that?) There isn't really a roadmap it's what each of us works on, commits and votes for. >The question is: can flex include any new lib before having fixed that? Sure, it's just going to be a constant refactoring. >Will it take long to be

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

>Why would someone continue to choose MX if the other solution we are >discussing here exists? Lots of legacy code

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

>Over engineered much? I actually believe UIComponent is way under-engineered... hence the reason it has 14k lines of code

Re: Summary of all ML discussions in wiki - was: (Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components)))

- how can i add a wiki page (as a simple user)? Sign up for wiki and ask on the list for permissions.

Summary of all ML discussions in wiki - was: (Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components)))

Ok thanks. But i dont feel that this wiki page reflects the heavy number of discussion subjects already seen in ML so far. A kind of summary of discussions, list of the point of views and arguments as a conclusion, would be very usefull. And if users could vote for it to show their interest wou

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

I think we all agree with that. And the SparkSimple lib would also need to be optionnaly linked to not penalize other projects. The modularity of the framework has already been heavly discussed in ML and if i get it right its one of the main roadmap objectives (someone confirm that?) The ques

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

Yeah of course i meant MX dying for new components only. Would you like to continue to implement MX version of every new component aside to spark? Why would someone continue to choose MX if the other solution we are discussing here exists? I like the SparkSimple lib that you can optionnally inc

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

My issue with this whole issue is choice. Even if I select "Spark only" its loads the MX library core and Spark components which are based on mx.core.UIComponent. I love the desire for backward compatibility but GIVE ME A CHOICE to cut the mx framework loose. Its still loads 6 RSL with its loading

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

> In Conclusion in my opinion: > Spark should be the base for all components from now on. > MX should die mainly because we cant use it for Mobile and it is not > based on Spark (that makes the SDK more hard to maintain). MX can't die. It is still used by many more projects than Spark. It will ne

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

> By the way, where can we find the results of every ideas that decision board has put aside for later votes, after all those rich discussions from ML? You can find it in the wiki, in the section decisions so far -- Mansour Blanco Software engineer Stackoverflow: http://stackoverflow.com/user

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

When you say that it is the plan, you mean that its already planned to take it in the Apache Flex roadmap? Would be great news for MX easy skinning lovers. By the way, where can we find the results of every ideas that decision board has put aside for later votes, after all those rich discussio

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

That's the plan (loosely). A set of core components and then convenience components. On Sat, Mar 3, 2012 at 3:20 PM, Rob Sheely wrote: > Maybe we can build on the concept of the Spark BorderContainer (quoting > the docs): > > The BorderContainer container provides a set of CSS styles and class

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

Maybe we can build on the concept of the Spark BorderContainer (quoting the docs): The BorderContainer container provides a set of CSS styles and class properties to control the border and background of the container. A set of subclassed Spark components with CSS styling implemented. Or more s

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

I totally agree with this and will try to help with it. On Sat, Mar 3, 2012 at 6:12 AM, sébastien Paturel wrote: > Hi all, > Im new to the mailing list so sorry if i do mistakes :) > > I'm personnally very concerned about the ease of learning curve of Flex > for new users. > Don't forget that the

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

I hope I didn't come on too strong with my tone. I agree that we're not really differing much. And I do agree that spark is a better architecture from a programmers point of view and for the long term. The point that I was trying to make is that many flex users both in the past and in the future w

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

Hi all, Im new to the mailing list so sorry if i do mistakes :) I'm personnally very concerned about the ease of learning curve of Flex for new users. Don't forget that the ease of use and power of this SDK suits to not only enterprise scale projects. It will be more true when the cross compil

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

>I have no doubt that given this experience you are well suited to guide the >core framework internals in the future, but not if you can't recognize that >it's a niche case and that mx covered 95% of most user's needs. Sorry, I seem incapable of getting all my thoughts out coherently tonight. La

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

> To me, that can't be true. If anything, while more verbose Spark > is infinitely friendlier to the little guy. In mx, as soon as > you wanted to do anything different, your only choice was to > hire a component developer to extend/copy/rewrite these classes. > Take for example a circular or carou

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

>...When the little guy was pushed out. > Most projects can't create components for the project. Most projects use > components to build the project. That's why they are called components. I need to respond to this one separately because I think this point is absolutely false and incorrect. In

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

>So if paying for the flex Ide is their only revenue point, to say that the mx >components were badly written is false. They hit exactly the crowd that they >needed to hit with them. You may be happy with the spark >components, but >that's when flex died, after they were introduced. When the lit

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

> > So if paying for the flex Ide is their only revenue point, to say that the > mx components were badly written is false. They hit exactly the crowd that > they needed to hit with them. You may be happy with the spark components, > but that's when flex died, after they were introduced. When the l

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

Thank you, Micheal for a great response. I think what we have here are two radically different use cases. On the one hand flex needs to be a good enough framework that a team of three can create something of real value on a 10-30 thousand dollar budget in a few months. Without rock stars. On the

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

hem. Spark is a step in the right direction. All the best, - Aaron From: Michael A. Labriola [labri...@digitalprimates.net] Sent: Friday, March 02, 2012 12:29 PM To: flex-dev@incubator.apache.org Subject: RE: Why Spark? (was Re: s:Spacer (was Re: Miss

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

>Haha, yeah maybe you're right. I've always taken AOP as a loosely defined term >(like OOP), to mean the "composition of objects with cross-cutting concerns," >where DI would be a design pattern in which to achieve AOP. I didn't >realize >the term was specific to the methodology. I always use DI

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

ubject: Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components)) > > > One of the re-occurring discussions on this list has been the desire > > to > break down components into smaller parts. > > > > The spark architecture goes some way to achieving this. T

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

>Hmmm, I think the right term would be composition-based design. In most cases >dependency injection would be the pattern to use to configure the compositions. >Sorry for being a smart-ass by the way... :) Working on both. As soon as I can push something to the whiteboard I will.

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

+1 on the DI From: Roland Zwaga To: flex-dev@incubator.apache.org Sent: Friday, 2 March 2012, 17:46 Subject: Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components)) > > > One of the re-occurring discussions on this list has been the

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

> > > One of the re-occurring discussions on this list has been the desire to > break down components into smaller parts. > > > > The spark architecture goes some way to achieving this. Take scrolling, > if you want it you wrap you group on a Scroller > > and off you go. Same for layouts. In this w

Re: Missing Spark Components List

On 3/2/12 3:59 AM, "Arnoud Bos" wrote: >> >> >> One question, apart from sdk size, is there any >> additional overhead when using VGroup for example >> rather than Group and adding a layout? > > not AFAIK, > > you get just shorter and more readable code :-) > > putting them in a separate

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

> One of the re-occurring discussions on this list has been the desire to break > down components into smaller parts. > > The spark architecture goes some way to achieving this. Take scrolling, if > you want it you wrap you group on a Scroller > and off you go. Same for layouts. In this way spar

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

>Ok. I'm totally willing to believe you and to think that I'm missing something >here but I think you have to explain that a little bit more. What kind of apps >were these? Were they super detailed subcomponents? Or was a >combobox >something that needed an item renderer? What other UI set are y

Re: Missing Spark Components List

> > > One question, apart from sdk size, is there any > additional overhead when using VGroup for example > rather than Group and adding a layout? not AFAIK, you get just shorter and more readable code :-) putting them in a separate package is the way to go i think. Arnoud

RE: Missing Spark Components List

rather than Group and adding a layout? Glenn tinylion -Original Message- From: Tink [mailto:f...@tink.ws ] Sent: 02 March 2012 09:42 To: flex-dev@incubator.apache.org Subject: Re: Missing Spark Components List I'm with Jonathan on this I pushed for Adobe to remove HGroup and VG

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

On 1 Mar 2012, at 23:12, Omar Gonzalez wrote: Maybe, I am completely off base here, but exactly what is the motivation of the spark component set? Is it the new skinning paradigm, or is it better performing versions of existing components or is it a completely different set of component

Re: Missing Spark Components List

I'm with Jonathan on this I pushed for Adobe to remove HGroup and VGroup before the release of spark as I saw these as absolutely pointless. In spark we should use a container or data control and then add the required layout. There is no need to bake in layouts and expose their properties

Re: Missing Spark Components List

On 1 Mar 2012, at 20:03, Jonathan Campos wrote: On Thu, Mar 1, 2012 at 1:59 PM, Omar Gonzalez >wrote: Does ButtonBar do that? Honestly I haven't tried to make a ToggleButtonBar so I can't say. I want to say it does, but there is always some margin for error. -- Jonathan Campos The re

Re: Missing Spark Components List

On 1 Mar 2012, at 08:28, Omar Gonzalez wrote: http://www.tink.ws/examples/**apache-flex/index.html If anyone is interested in looking at those, the source and examples source is in my whiteboard. Tink Nice, Tink. I'll add a link to t

Re: Missing Spark Components List

You know, you're right. I think I was reacting to carol's response to it and thought that the word vaporware was in there but it doesn't seem to be. I do think that the term vaporwear would have been unprofessional as it would imply an unnecessarily jaded view that they'll never get them done. I t

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

Ok. I'm totally willing to believe you and to think that I'm missing something here but I think you have to explain that a little bit more. What kind of apps were these? Were they super detailed subcomponents? Or was a combobox something that needed an item renderer? What other UI set are you compa

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

>the mx components were very well designed and complete and (though >complicated) hit a nice sweet spot between many trade-offs. I do agree that it was often about what types of apps you were building, however, just to provide another perspective, the mx components were neither well designed

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

Actually this is a very good question and I think that folk have many different opinions. Often based on the kinds of apps that they work on or the kind of work that they do. While I have no true window into the motivation, I believe that the motivation of the spark component set is two fold. The

RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

>Spark was supposed to enable fully-declarative skins for Flash Catalyst and >leverage a lot of other lessons learned from MX. But that didn't happen. True, however, just moving the child instantiation out of the component has made this architecture so much easier to work with and extend in prac

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

>> >> Maybe, I am completely off base here, but exactly what is the motivation of >> the spark component set? Spark was supposed to enable fully-declarative skins for Flash Catalyst and leverage a lot of other lessons learned from MX. But that didn't happen. >> Is it the new skinning paradigm, o

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

On 3/1/12 3:25 PM, "Om" wrote: > Right, but why are mx components shipping when equivalent spark versions > are available? This to me is the biggest sticking point. Can we nix mx > components from future releases if that is the 'old' way of doing things? > > Was the original plan (by Adobe

Re: s:Spacer (was Re: Missing Spark components)

On 3/1/12 3:33 PM, "Omar Gonzalez" wrote: >> >> I hadn't realized you could do this, so this essentially has the same > effect as moving the class to a new namespace, so I'm fine with that since > it's already working. I'll update the wiki to reflect that. > I think that was a hack of sorts.

Re: s:Spacer (was Re: Missing Spark components)

I updated the wiki with the information Carol shared about unreleased Spark components from Adobe and also updated the Spacer entry. https://cwiki.apache.org/confluence/display/FLEX/Missing+Spark+Components -- Omar Gonzalez s9tpep...@apache.org Apache Flex PPMC Member

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

I believe Adobe needed to support a backwards compatible product. My own preference is to take the same approach as certain software companies, and leave it to clients and companies to migrate to a faster, better, leaner platform (because we're not supporting backwards compatibility). On Thu, Mar

Re: s:Spacer (was Re: Missing Spark components)

Thanks for (re)pointing that out Carol. Looks like it was done with http://bugs.adobe.com/jira/browse/SDK-28369 -Ryan On Thu, Mar 1, 2012 at 11:28 PM, Carol Frampton wrote: > Someone said this several messages back but I don't think everybody saw > that since people are talking about when ther

Re: s:Spacer (was Re: Missing Spark components)

On Thu, Mar 1, 2012 at 3:28 PM, Carol Frampton wrote: > Someone said this several messages back but I don't think everybody saw > that since people are talking about when there is a s:Spacer. > > There is an entry in the spark manifest that points to mx:Spacer so > s:Spacer is mx:Spacer. > > It h

Re: s:Spacer (was Re: Missing Spark components)

Someone said this several messages back but I don't think everybody saw that since people are talking about when there is a s:Spacer. There is an entry in the spark manifest that points to mx:Spacer so s:Spacer is mx:Spacer. It has already shipped so you can't/shouldn't turn it into something els

Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

On Thu, Mar 1, 2012 at 3:12 PM, Omar Gonzalez wrote: > > > > Maybe, I am completely off base here, but exactly what is the motivation > of > > the spark component set? Is it the new skinning paradigm, or is it > better > > performing versions of existing components or is it a completely > differe

Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))

> > Maybe, I am completely off base here, but exactly what is the motivation of > the spark component set? Is it the new skinning paradigm, or is it better > performing versions of existing components or is it a completely different > set of components that happen to have similar names? If this i

Re: s:Spacer (was Re: Missing Spark components)

On Thu, Mar 1, 2012 at 2:05 PM, Michael A. Labriola < labri...@digitalprimates.net> wrote: > >See, I have a problem with this. Why would we not want to do that? The > ideal scenario is keep the interface same/similar but support everything. > >Internally, we can do things efficiently. > > That a

Re: s:Spacer (was Re: Missing Spark components)

On Thu, Mar 1, 2012 at 4:39 PM, Omar Gonzalez wrote: > I should reiterate the fact that this list is not a proposition that each > MX component be match 1:1 with what should be available in Spark. This is > why in some cases in the list, like for mx:ApplicationControlBar, I point > to spark.compon

Re: s:Spacer (was Re: Missing Spark components)

> > > Completely agree. This was my issue with the 1-1 list, just because it was > done once doesn't mean it should be done the same way forever. > > -- > Jonathan Campos > I should reiterate the fact that this list is not a proposition that each MX component be match 1:1 with what should be avail

Re: s:Spacer (was Re: Missing Spark components)

On Thu, Mar 1, 2012 at 4:05 PM, Michael A. Labriola < labri...@digitalprimates.net> wrote: > That assumes that the way it did work was ideal or even good in some > cases. I have no desire to make transitions harder for people but you also > don't want to couple all future development to the interf

RE: s:Spacer (was Re: Missing Spark components)

>See, I have a problem with this. Why would we not want to do that? The ideal >scenario is keep the interface same/similar but support everything. >Internally, we can do things efficiently. That assumes that the way it did work was ideal or even good in some cases. I have no desire to make tra

Re: s:Spacer (was Re: Missing Spark components)

+1 [1] http://www.nytimes.com/2012/03/01/technology/impatient-web-users-flee-slow-loading-sites.html?_r=1&ref=technology On Thu, Mar 1, 2012 at 4:49 PM, Ryan Frishberg wrote: > +1 what alex said. Let's support the common use-cases only and work to > achieve better performing Flex apps. > > -R

Re: s:Spacer (was Re: Missing Spark components)

+1 what alex said. Let's support the common use-cases only and work to achieve better performing Flex apps. -Ryan On Thu, Mar 1, 2012 at 9:18 PM, Alex Harui wrote: > > > > On 3/1/12 12:37 PM, "Om" wrote: > > > It might not be a very common use case, but it is a valid use case > > nevertheless

Re: s:Spacer (was Re: Missing Spark components)

On 3/1/12 1:31 PM, "Om" wrote: > On Thu, Mar 1, 2012 at 1:18 PM, Alex Harui wrote: > >> >> >> >> On 3/1/12 12:37 PM, "Om" wrote: >> >>> It might not be a very common use case, but it is a valid use case >>> nevertheless. >> I would prefer that we don't try to serve the uncommon use case

Re: s:Spacer (was Re: Missing Spark components)

On Thu, Mar 1, 2012 at 1:18 PM, Alex Harui wrote: > > > > On 3/1/12 12:37 PM, "Om" wrote: > > > It might not be a very common use case, but it is a valid use case > > nevertheless. > I would prefer that we don't try to serve the uncommon use case. Why make > everyone pay for a full UIComponent

Re: s:Spacer (was Re: Missing Spark components)

On Thu, Mar 1, 2012 at 3:21 PM, Om wrote: > Because in some cases, you cant. For example, mx:TabNavigator will not > take non Halo components as children. There are workarounds needed in some > cases where you mix mx and spark components. > Yup, the NavigationContent component. -- Jonathan C

Re: s:Spacer (was Re: Missing Spark components)

On Thu, Mar 1, 2012 at 3:06 PM, Omar Gonzalez wrote: > On Thu, Mar 1, 2012 at 1:05 PM, Jonathan Campos >wrote: > > > On Thu, Mar 1, 2012 at 2:56 PM, Om wrote: > > > > > This will help developers smoothly > > > migrate their existing apps to the spark architecture and reduce the > > > confusion w

Re: s:Spacer (was Re: Missing Spark components)

On Thu, Mar 1, 2012 at 1:05 PM, Jonathan Campos wrote: > On Thu, Mar 1, 2012 at 2:56 PM, Om wrote: > > > This will help developers smoothly > > migrate their existing apps to the spark architecture and reduce the > > confusion while doing so. > > > > Why is it bad to say (as part of the migration

Re: s:Spacer (was Re: Missing Spark components)

On 3/1/12 12:37 PM, "Om" wrote: > It might not be a very common use case, but it is a valid use case > nevertheless. I would prefer that we don't try to serve the uncommon use case. Why make everyone pay for a full UIComponent just for space? You are welcome to create a sample "SpacerWithT

Re: s:Spacer (was Re: Missing Spark components)

> > Now that is a much better argument and that should be something we can fix > up. Though I am guessing you won't see any "spark only" radio buttons in > Flash Builder. > > Its already there. I don't remember when it was added but its in your Properties -> Flex Build Path in FB 4.6. It also shows

Re: s:Spacer (was Re: Missing Spark components)

On Thu, Mar 1, 2012 at 3:04 PM, Daniel Reicher wrote: > I don't think mx needs to go away, but it would be nice for developers to > be able to hit the "Spark Only" radio button in Flash Builder and not have > to worry about paying the download tax. > Now that is a much better argument and that s

Re: s:Spacer (was Re: Missing Spark components)

On Thu, Mar 1, 2012 at 1:05 PM, Jonathan Campos wrote: > On Thu, Mar 1, 2012 at 2:56 PM, Om wrote: > > > This will help developers smoothly > > migrate their existing apps to the spark architecture and reduce the > > confusion while doing so. > > > > Why is it bad to say (as part of the migration

Re: s:Spacer (was Re: Missing Spark components)

On Thu, Mar 1, 2012 at 2:56 PM, Om wrote: > This will help developers smoothly > migrate their existing apps to the spark architecture and reduce the > confusion while doing so. > Why is it bad to say (as part of the migration process), "you can still use all the old components the same exact wa

Re: s:Spacer (was Re: Missing Spark components)

> > > Why do we need to get rid of the mx namespace? If it ain't broke don't fix > it. While I can understand personal preference to see s: instead of mx: I > don't really think that this is a huge necessity. > The "RSL tax" for me is the most obvious reason. Admittedly, using mx:Spacer alone doe

Re: s:Spacer (was Re: Missing Spark components)

Sorry, my wording was unclear. I was NOT talking about getting rid of the mx namespace from the Flex SDK. I dont want to start a war here :-) My point is that if we are going to create a s:Spacer class, it should support the same functionalities that mx:Spacer currently supports. We can add fun

Re: s:Spacer (was Re: Missing Spark components)

On Thu, Mar 1, 2012 at 2:37 PM, Om wrote: > I see the performance argument, but we want to also make sure that existing > apps can easily get rid of mx namespace as easy as possible. > Why do we need to get rid of the mx namespace? If it ain't broke don't fix it. While I can understand personal

Re: s:Spacer (was Re: Missing Spark components)

> > I think it should be a subclass of Rect for performance reasons...if people > need something else, they will figure it out. If people want a Skinnable > or fancier spacer, they can create a simple custom class for their own > purposes. > But you cant do things like this: It might not be a

Re: s:Spacer (was Re: Missing Spark components)

1 mar 2012 kl. 21.07 skrev Omar Gonzalez: > in my tags annoys the shit out of me. Sometimes Flex cheats. mx.controls.Spacer is also a spark class. Through the manifest files it lives in multiple namespaces. But remains the same class. You can do both and . If this is convenient or confus

Re: s:Spacer (was Re: Missing Spark components)

On Thu, Mar 1, 2012 at 12:01 PM, Om wrote: > mx.controls.Spacer is nothing but a UIComponent. It adds nothing and it > modifies nothing. The only difference is the usage in a given context. To > keep it consistent, we should just copy it over to spark.components.Spacer > and call it a day. I

Re: s:Spacer (was Re: Missing Spark components)

Wow, the thread on this simple topic has gotten quite large. One of the main complaints against how Spark was originally written was that it was too inconvenient. That is the main reason the ship date for Flex 4 got delayed. We need to find a good balance point between ease-of-use and strict co

Re: Missing Spark Components List

On Thu, Mar 1, 2012 at 1:59 PM, Omar Gonzalez wrote: > Does ButtonBar do that? Honestly I haven't tried to make a ToggleButtonBar so I can't say. I want to say it does, but there is always some margin for error. -- Jonathan Campos

Re: s:Spacer (was Re: Missing Spark components)

mx.controls.Spacer is nothing but a UIComponent. It adds nothing and it modifies nothing. The only difference is the usage in a given context. To keep it consistent, we should just copy it over to spark.components.Spacer and call it a day. This addresses the problem of halo vs. spark component

Re: Missing Spark Components List

On Thu, Mar 1, 2012 at 11:53 AM, Jonathan Campos wrote: > On Thu, Mar 1, 2012 at 11:35 AM, Omar Gonzalez >wrote: > > > ToggleButton !== Button, I think another component is needed here no? > > > I *may* need a new skin. But in this case I would use composition with the > togglebutton, not the but

Re: Missing Spark Components List

On Thu, Mar 1, 2012 at 11:35 AM, Omar Gonzalez wrote: > ToggleButton !== Button, I think another component is needed here no? I *may* need a new skin. But in this case I would use composition with the togglebutton, not the button. You may remember that there is a toggle button in spark already.

Re: Missing Spark Components List

On Thu, Mar 1, 2012 at 11:39 AM, Cortlandt Winters wrote: > I think this is a great list but that it should be more courteous and > professional in tone. I'm happy to edit the page, I don't see where it is being unprofessional. Can you point out what you would like to see edited or what you take

Re: Missing Spark Components List

username: Mansuro -- Mansour Blanco Software engineer Stackoverflow: http://stackoverflow.com/users/612920/mansuro Blog: zuro.blogspot.com github: https://github.com/Mansuro

Re: Missing Spark Components List

I think this is a great list but that it should be more courteous and professional in tone. I am really thankful that Adobe's committed to finish out the spark set and I'm sure it's a lot of work. Lets cheer these folk on instead of making any timeline that isn't tomorrow a failure. That would be v

Re: s:Spacer (was Re: Missing Spark components)

> > Fair enough, I was thinking about how inconsistent VGroup and HGroup were > to a tighter lighter framework. Heh, it is what it is at this point. > > What if we put these convenience classes like s:TileList and > s:LinkButton in another package, like spark.components.convenience, or some > ot

Re: s:Spacer (was Re: Missing Spark components)

On Thu, Mar 1, 2012 at 12:55 PM, Omar Gonzalez wrote: > What if we put these convenience classes like s:TileList and > s:LinkButton in another package, like spark.components.convenience, or some > other name. We can then compile that into its own SWC and it can be an > optional part of the framewo

RE: s:Spacer (was Re: Missing Spark components)

>Unless you really know that that space is really just blank space the argument >could be made that having a visual characteristic that you can't easily style >or change is premature optimization. Which I say is actually a good argument for not making a component but rather letting you put any

Re: s:Spacer (was Re: Missing Spark components)

I'd say that this depends on workflow. If you have a photoshop composite that you know you are going to stick to like glue then you want to use the minimaly weighted set of components necessary to make it look that way and get the potential performance gains. But if you expect a lot of design cha

Re: s:Spacer (was Re: Missing Spark components)

On Thu, Mar 1, 2012 at 10:37 AM, Michael A. Labriola < labri...@digitalprimates.net> wrote: > >I didn't put 100%, I put just 100, 100 pixels. :P > > I know and I knew you were going to call me on that but my over the top > approach didn't work as well with 100 pixels. > > >But I get what you're sa

RE: s:Spacer (was Re: Missing Spark components)

>I didn't put 100%, I put just 100, 100 pixels. :P I know and I knew you were going to call me on that but my over the top approach didn't work as well with 100 pixels. >But I get what you're saying, however, I still think that easing the migration >path is a worthy endeavor. I'm not saying we

RE: s:Spacer (was Re: Missing Spark components)

9:58 AM To: flex-dev@incubator.apache.org Subject: Re: s:Spacer (was Re: Missing Spark components) I didn't put 100%, I put just 100, 100 pixels. :P But I get what you're saying, however, I still think that easing the migration path is a worthy endeavor. I'm not saying we need a

Re: s:Spacer (was Re: Missing Spark components)

On 3/1/12 9:48 AM, "Michael A. Labriola" wrote: > Why set the width to 100% on a space, why not have or > then you don't need to set the properties at all? > Incidentally, I support that idea (honestly) if someone want to compose > objects in their own framework or project for their own use,

Re: s:Spacer (was Re: Missing Spark components)

On Thu, Mar 1, 2012 at 9:48 AM, Michael A. Labriola < labri...@digitalprimates.net> wrote: > > This is exactly why I feel we should have these. People first > > instinct, at least mine was, was to look for an equivalent. Subclassing > with convenience setters would go a long way toward reducing >

RE: s:Spacer (was Re: Missing Spark components)

> This is exactly why I feel we should have these. People first > instinct, at least mine was, was to look for an equivalent. Subclassing > with convenience setters would go a long way toward reducing > frustrations people have had with migrating. Not everyone is immediately > aware of >all th

Re: s:Spacer (was Re: Missing Spark components)

> > > I wouldn't be opposed to a subclass of s:Rect called s:Spacer if folks > think > it will help with migration and learning curves. Same for s:Line to > s:Vrule/s:Hrule > > -- > Alex Harui > Flex SDK Team > Adobe Systems, Inc. > http://blogs.adobe.com/aharui > > This is exactly why I feel we s

Re: Missing Spark Components List

On Thu, Mar 1, 2012 at 7:34 AM, Jonathan Campos wrote: > On Thu, Mar 1, 2012 at 2:13 AM, Omar Gonzalez >wrote: > > > I've added a page to the wiki to keep track of the current inventory of > MX > > components, their Spark counterparts, and whether they are currently > > missing. > > > > I don't w

Re: s:Spacer (was Re: Missing Spark components)

On 3/1/12 7:47 AM, "Michael A. Labriola" wrote: > > Or, in the Flex 4 model, you can but an empty rectangle in the 'space' that > you need. It doesn't carry the weight of a whole component and is much more > performant. I wouldn¹t object if you wanted to have a graphical element which > just

Re: Missing Spark Components List

The missing point to Flex SDK is, Move on! If those components are not sparked by spark itself, move on. Don't replicate legacy code into a new formula. Let's be more creative people, implementing new components based on Spark Architecture. Because later on, we will have a new architecture that

Re: Missing Spark Components List

On Thu, Mar 1, 2012 at 7:18 AM, Carol Frampton wrote: > Omar, > > I am sorry that this is going to sound a little snippy but would you > prefer we stop working on getting the compiler and mustella ready and work > on moving the new spark components over to apache? I'm guessing not. Definitely

  1   2   >