well - as FlexSDK is mostly "component kit", it would be IMHO beneficial,
to have some optional packages, that could host these "extra" kind of
components. (like data visualization is separate)
Your ideas, comments?
On Thu, Mar 1, 2012 at 6:22 PM, Alex Harui wrote:
>
>
>
> On 3/1/12 8:55 AM, "
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
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
>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
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
>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
>>
>> 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
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
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.
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
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
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
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
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
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
>
> 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
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
On 3/1/12 3 :57PM, "Omar Gonzalez" wrote:
>Hi Carol/Alex,
>
>I updated the Missing Spark Components list with notes that s:Accordion
>and
>s:AdvancedDataGrid are in awaiting review/donation. Are there others you
>could shed some light on that I can update on the list? I don't mean to
>detract you
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
>
>
> 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
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
>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
+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
+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
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
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
Great... good discussion
I don't think a mvc framework should go in the core framework of flex... It
doesn't make sense I agree on that 100%
The idea of extensions sound great to me, but I don't have a lot of
experience with this idea on an opensource project to suggest a model that
would
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
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
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
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
>
> 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
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
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
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
>
>
> 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
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
Hi Carol/Alex,
I updated the Missing Spark Components list with notes that s:Accordion and
s:AdvancedDataGrid are in awaiting review/donation. Are there others you
could shed some light on that I can update on the list? I don't mean to
detract your focus from your current work for the compiler, JI
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
>
> 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
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
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
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
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
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
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
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.
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
username: Mansuro
--
Mansour Blanco
Software engineer
Stackoverflow: http://stackoverflow.com/users/612920/mansuro
Blog: zuro.blogspot.com
github: https://github.com/Mansuro
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
>
> 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
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
>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
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
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
count me in!
Arnoud
On 01-03-2012, at 13:46, Rafael Santos wrote:
> I would like to hear from everyone about this
>
> I have being developing a MVC Framework for Flex for the last 3-4 years
> now. The framework is based on Fake Framework that is on Google Code.
>
> Since last year we wante
>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
What about an extension to the framework (like TLF, OSMF, etc.), that provided
additional "template" components and skins, the purpose of which would serve as
a clear migration path for Halo based projects? This would allow projects to
develop new functionality using Spark concepts, while preser
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,
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
>
> 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
On Thu, Mar 1, 2012 at 14:22, Alex Harui wrote:
>
> On 3/1/12 8:55 AM, "Antonio Hernández de la Rosa"
> wrote:
>
> It is pretty clear to me that we can't just choose to integrate other code
> into the Apache Flex project.
>
> In general, code is "owned" by some entity and has to be donated by th
If you take a look on almost all MVC frameworks (pureMVC, robotlegs) are
not only for Flex. These frameworks can also be used for AS3 and
implemented in Flash, which is not related at all with Apache Flex.
And I agree with Igor, the decision of what MVC framework to use depends on
the developers in
>
>
> 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
I always believe that an MVC approach into Flex SDK will succumb the
freedom of choice by many developers out there.
I suggestion is to adopt a mvc aware that can be fit in any other MVC out
there.
The suggestion of Ruby Gems model I totally disagree, because as in Ruby
Gems doesn't have access
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
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
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
On 3/1/12 8:55 AM, "Antonio Hernández de la Rosa" wrote:
> This is not a relevant / core functionality for flex sdk
>
I'm all for giving related code a home if it needs one.
> El 01/03/2012, a las 17:51, andrei apostolache escribió:
>
>> Even if it might look like a interesting tool for ent
On 1 March 2012 17:13, andrei apostolache wrote:
> And I don't see why I will need a MVC framework directly implemented in
> Flex SDK,
>
That's not I said, it's an extension so the core would never have
dependencies on extensions, otherwise they aren't extensions anymore.
> Each project should
On 3/1/12 9:11 AM, "Jarosław Szczepankiewicz"
wrote:
> what's the purpose? sharing mailing lists? sharing repository? sharing
> documentation? apart from that why framework Parsley, not Matte or
> something else? How this will affect releasing new edition of flex
> sdk? Will we wait with relea
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
On 3/1/12 8:59 AM, "João Fernandes"
wrote:
> I wonder if the Apache Flex couldn't be splitted in core and extensions?
>
> In the core we could have what we have now as the SDK + compiler, what is
> required to get the job done (primary project target) and extensions could
> be small projects
My opinion is that Apache Flex should be only what Flex was in Adobe's era.
A simple SDK that contains only the necessary code to create an RIA.
FlexUnit, FlexCover are already projects set on google code. BlazeDS will
be somewhere in the future donated by Adobe as different project. And I
don't se
what's the purpose? sharing mailing lists? sharing repository? sharing
documentation? apart from that why framework Parsley, not Matte or
something else? How this will affect releasing new edition of flex
sdk? Will we wait with release of 4.9 sdk for bugfixing in library X?
2012/3/1 João Fernandes
On Thu, Mar 1, 2012 at 9:49 AM, David Francis Buhler
wrote:
> Done: pedalfaster
>
> On Thu, Mar 1, 2012 at 11:23 AM, Doug Arthur wrote:
>
>> On Thu, Mar 1, 2012 at 8:21 AM, David Francis Buhler
>> wrote:
>> > I have a BA in English and worked as a Technical Writer for a big
>> software
>> > comp
I wonder if the Apache Flex couldn't be splitted in core and extensions?
In the core we could have what we have now as the SDK + compiler, what is
required to get the job done (primary project target) and extensions could
be small projects that could be associated as enhancements of the project,
l
On Thu, Mar 1, 2012 at 9:55 AM, almansour belleh blanco
wrote:
> I don't have permission to make edits too.
Please send me your username.
This is not a relevant / core functionality for flex sdk
El 01/03/2012, a las 17:51, andrei apostolache escribió:
> Even if it might look like a interesting tool for enterprise development,
> having it in the Flex SDK will just make the SDK size bigger.
> I don't think the majority of developers
I don't have permission to make edits too.
--
Mansour Blanco
Software engineer
Stackoverflow: http://stackoverflow.com/users/612920/mansuro
Blog: zuro.blogspot.com
github: https://github.com/Mansuro
Even if it might look like a interesting tool for enterprise development,
having it in the Flex SDK will just make the SDK size bigger.
I don't think the majority of developers will use it, so is much better to
keep the sdk as light as possible.
Regards,
Andrei.
On Thu, Mar 1, 2012 at 4:34 PM, Ra
Done: pedalfaster
On Thu, Mar 1, 2012 at 11:23 AM, Doug Arthur wrote:
> On Thu, Mar 1, 2012 at 8:21 AM, David Francis Buhler
> wrote:
> > I have a BA in English and worked as a Technical Writer for a big
> software
> > company (writing software manuals). If there's a need to edit and review
> >
What do think about integrating FlexCover in the Apache Flex code base?
http://code.google.com/p/flexcover/
FlexCover is a great tool for test coverage, but as for today we need to
change Flex source and recompile to make it work.
Regarding Enterprise systems it is a powerful tool.
Rafael Santos
>
> We could do that for application frameworks that need a home and don't have
> a separate community as well. The real question is who plans to work on
> it.
> I probably wouldn't work on the application frameworks.
>
> And, you can always fork off a technology later if it does get its own
> com
>Don't think I care for any type of license really... The idea is to make it
>open and get some help from those who find that interesting I would only
>have to refactor >the code and make it compliant with the latest version (I
>would wait for the version 4.8 or 4.9) I prefer putting it
On Thu, Mar 1, 2012 at 8:21 AM, David Francis Buhler
wrote:
> I have a BA in English and worked as a Technical Writer for a big software
> company (writing software manuals). If there's a need to edit and review
> the Wiki Pages so they present themselves as unbiased, professional, with a
> single
2012/3/1 Jarosław Szczepankiewicz
> Let's write a wiki page with categories and links to the projects
> hosted on githud / sourceforge etc.. This will be very usefull for
> everybody looking for libraries / additions to flex.
>
That is a good idea I have a bunch of those... I actually got so
On Sat, Feb 25, 2012 at 7:38 AM, David Francis Buhler
wrote:
> JIRA username: davidbuhler
>
> On Sat, Feb 25, 2012 at 4:54 AM, Sebastian Mohr wrote:
>
>> JIRA username: masuland
Hi David,
I do not see that you are listed as a committer [1], so therefore no
further action is required to give you
On Thu, Mar 1, 2012 at 13:07, Michael A. Labriola <
labri...@digitalprimates.net> wrote:
> >Mike, I agree with you that the core framework should stay simple, but
> maybe we could have some complementary projects don't you think?
>
> Without a doubt. I have developed a few of them. I fully support
2012/2/25 Sebastian Mohr :
> JIRA username: masuland
Hi Sebastian,
Your username could not found in Jira when I tried to add you.
- Doug
On 3/1/12 8:00 AM, "Rafael Santos" wrote:
>
> Mike, I agree with you that the core framework should stay simple, but
> maybe we could have some complementary projects don't you think?
What I think I've learned so far, is that Apache is about community as well
as technology. If there is a not
On Fri, Feb 24, 2012 at 11:28 PM, Justin Mclean wrote:
> Hi,
>
> Also would it be possible to have "Create Shared Object" permission so I can
> share filters.
>
> Thanks,
> Justin
Hi Justin,
I've added you to the committers list in Jira. You would probably have
to ask Infra about the permission
Let's write a wiki page with categories and links to the projects
hosted on githud / sourceforge etc.. This will be very usefull for
everybody looking for libraries / additions to flex.
2012/3/1 Michael A. Labriola :
>>Mike, I agree with you that the core framework should stay simple, but maybe
>
On Thu, Mar 1, 2012 at 11:57, Carol Frampton wrote:
>
> On 2/29/12 10 :20PM, "Rafael Santos" wrote:
>
> >As long as I can remember Spark does not cover every component that exist
> >on mx. Many components were left behind (ViewStack, Accordion, LinkButton
> >and many others).
> >
> >Rafael Santo
On Fri, Feb 24, 2012 at 3:25 PM, JP Bader wrote:
> JIRa username: lordb8r
Hi JB,
I do not see that you are listed as a committer [1], so therefore no
further action is required to give you additional permissions in Jira.
Users automatically have access to submit issues and add comments to
existi
>Mike, I agree with you that the core framework should stay simple, but maybe
>we could have some complementary projects don't you think?
Without a doubt. I have developed a few of them. I fully support the idea of
having something like a gem repository, I just meant I didn't want to see the
ma
On Thu, Mar 1, 2012 at 12:13, Carol Frampton wrote:
>
> On 2/29/12 9 :49PM, "Justin Mclean" wrote:
>
> >Coding style could be in the same format as the existing code. ie If you
> >adding a patch to a file you should code in the same style as what is
> >currently in the file.
>
> I'd also add a p
2012/2/24 Michelle Yaiser :
> JIRA username: myaiser
Hi Michelle,
Your username could not found in Jira when I tried to add you.
- Doug
PopUpButton : Button + PopUpAnchor?
All list variants: Create a List and set its 'layout' property, you don't
even need a special skin.
VRule and HRule: Line.
Haykel
On 1 March 2012 16:34, Jonathan Campos wrote:
> On Thu, Mar 1, 2012 at 2:13 AM, Omar Gonzalez >wrote:
>
> > I've added a page
On Thu, Mar 1, 2012 at 12:45, Michael A. Labriola <
labri...@digitalprimates.net> wrote:
>
> >Should be another project. Such as Ruby is it's own language and then you
> have Ruby on Rails.
>
> My personal opinion is that the Flex framework should stay tight and in
> the realm of a component frame
1 - 100 of 154 matches
Mail list logo
