Re: [Proposal] Missing Spark Components : Alert, ColorPicker, HDividedGroup, VDividedGroup

Hi everyone, I saw the discussions regarding SDK inclusion process. In my case, it's true that I cannot improve any component without having requests for that. The submitted components reflects exactly what I needed them to do at the time they were created. In Alert's case, it's written in the sa

Re: [Proposal] Missing Spark Components : Alert, ColorPicker, HDividedGroup, VDividedGroup

I've tried this but the biggest challenge was the touch point. Fingers tend to be not as accurate as mouse pointers. What I was thinking was a hybrid interface that would include a base set of colours and then the sliders to fine tune them. Having said that, does anyone have any other proposals

Re: [Proposal] Missing Spark Components : Alert, ColorPicker, HDividedGroup, VDividedGroup

Menu and MenuBar (based on List component) were added to the same github repository.

Re: [Proposal] Missing Spark Components : Alert, ColorPicker, HDividedGroup, VDividedGroup

This is where I was going. I wrote my own because the Adobe ones sucked for mobile. It comes down to this IMO. User Interface: - is the person familiar with RGB, et al value an can use sliders to determine the value? - does the user need to be guided by a better UI to find the colour. To test

Re: [Proposal] Missing Spark Components : Alert, ColorPicker, HDividedGroup, VDividedGroup

Seems one could break the color selector down into a couple of possibilities: 1. Discrete set of color values 2. A color range Either of these could be presented using a number of layouts, such as square, spiral, or line gradient, and a number of item renderers (maybe for discrete values only).

Re: [Proposal] Missing Spark Components : Alert, ColorPicker, HDividedGroup, VDividedGroup

The MX color picker was okay but very hard to use on mobile. Even if you scale it, it is hdd to predict the expansion of colors based on horizontal vs. vertical. To be honest, I like your idea. The colour class logic is very simple (getColor, setColor). The UI component maybe needs a rethink?

Re: [Proposal] Missing Spark Components : Alert, ColorPicker, HDividedGroup, VDividedGroup

Hi, > Having thought about the CP's for a while, I came to an opinion. I used > to think that the uber-does-everything color picker was probably the best > idea. > > My gut feeling is having a few different colour classes might be the > ultimate answer and let users pick which ones they want.

Re: [Proposal] Missing Spark Components : Alert, ColorPicker, HDividedGroup, VDividedGroup

Having thought about the CP's for a while, I came to an opinion. I used to think that the uber-does-everything color picker was probably the best idea. Think of the Photoshop CP with all the different filters etc. After using CP's in various projects though, I came to the conclusions that there a

Re: [Proposal] Missing Spark Components : Alert, ColorPicker, HDividedGroup, VDividedGroup

On 12/03/2012 06:00, JP Bader wrote: Martin - do you have the source code on git or google that we could look into this? I'd be happy to look at the CPs people have mentioned so far, review complexity and Spark-ability, and write some unit tests to cover them, and bring that to a whiteboard. JP

Re: [Proposal] Missing Spark Components : Alert, ColorPicker, HDividedGroup, VDividedGroup

Martin - do you have the source code on git or google that we could look into this? I'd be happy to look at the CPs people have mentioned so far, review complexity and Spark-ability, and write some unit tests to cover them, and bring that to a whiteboard. JP On Thu, Mar 8, 2012 at 4:02 AM, Marti

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: [Proposal] Missing Spark Components : Alert, ColorPicker, HDividedGroup, VDividedGroup

Adobe does not have a spark ColorPicker. We did some investigation since there are many different ways to select color but we didn't go farther than that. I haven't looked at these yet to know what the UI is but I do know some people want to pick from a limited set of "swatches" and some people w

Re: [Proposal] Missing Spark Components : Alert, ColorPicker, HDividedGroup, VDividedGroup

I have been working on a colorpicker too [1], a while ago, and anyone interesting in converting it to Flex code is welcome. yours Martin [1] http://dl.dropbox.com/u/19407988/ColorEditor.swf On 08/03/2012 18:16, Duane Nickull wrote: I built a colour picker that is very basic, but you are welco

Re: [Proposal] Missing Spark Components : Alert, ColorPicker, HDividedGroup, VDividedGroup

essential (in my >view) having well tested code makes it far more likely that the code will >be accepted into the SDK (via community consensus). > >Thanks, >Justin > >1. >https://cwiki.apache.org/confluence/display/FLEX/Missing+Spark+Components

Re: [Proposal] Missing Spark Components : Alert, ColorPicker, HDividedGroup, VDividedGroup

I built a colour picker that is very basic, but you are welcome to have. http://technoracle.blogspot.com/2011/05/flexair-mobile-color-picker.html I wouldn't claim it to be super fancy, but it does work and has had over 25,000 downloads. It's your to use. D President/COO ­ Über

Re: [Proposal] Missing Spark Components : Alert, ColorPicker, HDividedGroup, VDividedGroup

ential (in my view) > having well tested code makes it far more likely that the code will be > accepted into the SDK (via community consensus). > > Thanks, > Justin > > 1. > https://cwiki.apache.org/confluence/display/FLEX/Missing+Spark+Components -- http://www.badu.ro

Re: [Proposal] Missing Spark Components : Alert, ColorPicker, HDividedGroup, VDividedGroup

ache.org/confluence/display/FLEX/Missing+Spark+Components

[Proposal] Missing Spark Components : Alert, ColorPicker, HDividedGroup, VDividedGroup

Hello everyone, my version of Alert, ColorPicker, HDividedGroup, VDividedGroup components can be found here . Looking forward for feedback or questions. Best regards, Bogdan DINU http://www.badu.ro

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

  1   2   >