Re: Donation of TLF word processor
>Do you have something other than a video that we can read to learn more about this code? Nothing else unless I build or write something for you. I'm juggling my time between a few things right now - what do you require? It's pure actionscript, and the UI is completely custom built. >Do you actually own the code or was this done for a customer or employer? This was a self-indulgent and time-consuming unfunded project. (Like MadComponents is!). >Did anyone other than you contribute code? No. >Any other third-party components? It uses Adobe's TLF, the Squiggly spell check, and as3corelib.swc >What is the current license for the code? I've never released the source to anyone - so no license right now. On Sat, Feb 23, 2013 at 3:31 PM, Alex Harui wrote: > > > > On 2/22/13 8:54 PM, "Daniel Freeman" wrote: > > > I've started a new thread for this, as the discussion started off-topic. > > > > I agreed to donate my TLF-based word processor to this group. > > > > @Harbs said he'd be interested to help getting it ready for donation - > and > > I wondered if anyone else would be interested in helping to get it ready? > > > > It was quite a sophisticated and self-indugent project. Text Wrapping > > wasn't its only novel feature. > > > > I've decided to bundle it with e2vector, as they share many classes, and > > the two apps work together. > > > > http://e2easy.wordpress.com/2010/04/28/e2publish-video-tutorials/ > > > > http://www.youtube.com/watch?v=VvakUrX9Hvc > > > > What licensing do I use to hand it over? MadComponents is MIT licensed - > > do I use the same? Any particular text comment to put at the top of the > > source code? > Do you have something other than a video that we can read to learn more > about this code? > > Do you actually own the code or was this done for a customer or employer? > > Did anyone other than you contribute code? > > Any other third-party components? > > What is the current license for the code? > > -- > Alex Harui > Flex SDK Team > Adobe Systems, Inc. > http://blogs.adobe.com/aharui > >
Re: Donation of TLF word processor
Hi Justin, Out of interest, what new feature has the most number of votes ? I'm not enamoured with the idea of donating these apps just for asset stripping. If I was writing this flex component - I might borrowing a little from something already written - but I'd be likely to write it afresh. On the jira request - I see that Razvan Andei Surdu volunteered to write this if someone with TLF expertise assisted him. I could do that (subject to other my commitments) - if he (or someone else) takes on the hard graft development. My e2publish app incorporates two text wrap algorithms. A simple one, and an advanced one. The advanced one is based on TLF containers for each line of text, so it is capable of this: https://issues.apache.org/jira/secure/attachment/12556084/text-wrap-final.jpeg (In my app - I get the user to draw around the image, rather than detecting transparent pixels - but I'm sure automatic boundaries for images isn't too hard). On Mon, Feb 25, 2013 at 10:45 AM, Justin Mclean wrote: > Hi, > > This is currently our second highest votes on issue: > https://issues.apache.org/jira/browse/FLEX-33287 > > Would the donated code help with this? > > Thanks, > Justin >
Re: Donation of TLF word processor
> How do you see the project as a whole being useful as a donation... from the perspective of Apache? Possibly as a cool showpiece for the capabilities of TLF. But I'm ok if Apache doesn't want to receive this. If there's enough interest in it - I might release the code as open source anyway - on github or google-code. As I said, I can lend some advice and guidance to the development of your text wrapping Flex component. I'd just like to explore - - do you think there would be any interest from Apache for my other projects? MadComponents and MC3D. MadComponents is a popular alternative to mobile Flex. http://madskool.wordpress.com/2012/01/23/why-developers-are-using-madcomponents/ MC3D is my Stage3D enhancement to MadComponents, transitions and effects. See: http://www.youtube.com/watch?v=S5mx9YVDmyo The justification in Apache managing these would probably be that they are popular with AIR/Flash-Platform developers. I'm almost ready to let go a bit, and allow other developers more contribution. Apache would be a great way to manage this transition - if you feel it comes under your remit. Just an idea. On Tue, Feb 26, 2013 at 10:45 PM, Harbs wrote: > Here's all issues sorted by popularity: > > https://issues.apache.org/jira/browse/FLEX#selectedTab=com.atlassian.jira.plugin.system.project%3Apopularissues-panel > > Number 1 is a Maven/Flexmojos build: > https://issues.apache.org/jira/browse/FLEX-33086 > > On Feb 26, 2013, at 2:20 PM, Daniel Freeman wrote: > > > Out of interest, what new feature has the most number of votes ? > >
Re: FXG to SVG - working example
I wrote one of those. I wrote SVG -> AS3 graphics. And extending that class, I wrote FXG -> AS3 graphics. It wasn't a complete implementation of the SVG or FXG standards. It didn't handle text, and complex gradients weren't perfect. The FXG class was based on Adobe's first FXG definition. But it worked pretty well. This was one of the features of the applications I offered to donate. Actually, if you go back to build r53 of extendedMadness. SVG was in there. I took it out, because I didn't think too may people would be interested - and to reduce the bloat. (I didn't want my Framework getting like Flex - did I), http://code.google.com/p/mad-components/source/detail?r=53# See example here: http://code.google.com/p/mad-components/source/browse/trunk/MadComponentStuff/src/MadComponentsDesktop.as?spec=svn53&r=53 FXG isn't too different from SVG. ... I've mentioned this before, but I'd like to relinquish control a little over maintaining MadComponents, ExtendedMadness, and MC3D. I've offered before to donate them to this Apache group. Bear in mind that people aren't using Flex to build mobile apps. They're using MadComponents (General Purpose / Enterprise) or Feathers (Game UI). In fact, I've had clients engage my freelance services because they tried to build a mobile app using bloated Flex - and regretted it. http://madskool.wordpress.com/2012/01/23/why-developers-are-using-madcomponents/ Is there any interest in this group in MadComponents? On Sat, Mar 16, 2013 at 4:01 AM, Michael Schmalle wrote: > > Quoting Alex Harui : > > In my simple mind, Falcon generates the AST then at some point in time the >> futures task for that compilation unit is asked for output. Current >> Falcon >> code calls the BURM which eventually calls an emitter, I'm assuming >> FalconJX >> does an AST tree walk instead of calling the BURM. There is no reduction, >> just emitting. CSS for JS is probably just going emit text from the tree. >> > > Yes this is correct basically. > > Each compilation unit implements its own handleASBRequest() that gets > called during a generator request. This request ONLY happens AFTER the > handle AST and Scope requests have been processed. > > Its very complicated below that principle because of the future tasks and > outgoing dependency requests that trigger other files to be parsed, scopes > built etc. > > THe framework is elegant. The only thing I wish I could tear out and > abstract is how they have SWF baked into ITarget and Target. > > This really makes it hard to do what we are doing without all this > "baggage". > > As I said, parsing is multithreaded right now in FalconJx, I can easily > get the source code generation multithreaded to now that I have learned how > the framework wheels move together. > > I'm just not at the point to worry to much about it at the moment because > in a couple of my test projects, the compiler is wicked fast, I also have > an implementation that uses the Workspace and only loads config once, which > is using the framework like and IDE does... > > Mike > > > > >> On 3/15/13 1:44 PM, "Michael Schmalle" wrote: >> >> BTW, >>> >>> I have not seen one thing that you are asking for that doesn't contain >>> an AST and node framework in the Falcon package. >>> >>> If it was me, I would create all the emitters exactly the same way be >>> parsing the file, handling the AST, traversing it while outputting to >>> the target, then writing it in its file format. >>> >>> Its simple and I guess the FalconJx framework is mainly due to me >>> dealing with inheritance and dependency madness with Flex components >>> for years. I said all my future projects will use composition, this >>> one does big time. >>> >>> Mike >>> >>> Quoting Michael Schmalle : >>> >>> Quoting Alex Harui : > > > On 3/15/13 1:14 PM, "Michael Schmalle" > wrote: > > The problem is, SWF is so >> interconnected in the generator packages that you might have a problem >> getting a polarity with using the BURM. >> > Don't know what "polarity" meant, but hopefully it doesn't really > matter. > Bad word, I meant polarity in emitters as what the BURM generators offer right now with FalconJS, properties, css, as, mxml. On that note; This would take more study to fully understand, but at >> the moment I don't have time to investigate. I guess you will have to >> weigh the options or get a "feel" for the Falcon framework when your >> not under as much of a timeline/deadline? >> >> That being said, the FalconJx framework was meant to be created in >> component sections, so if your end goal is to create things with it >> fully, I would suggest things being ported to its emitter, or it will >> for ever have a crutch on SWF. >> >> Good point about the generators being tied to SWF constructs. But I > am > assuming you that, in order to service different file
Re: FXG to SVG - working example
Sorry, I read this thread too quickly, and without thinking. FXG -> SVG. I was talking about going in the other direction. Parsing and displaying SVG or FXG in Flash (Dynamically, at run time). Nevertheless, if someone is interested in that - you may find my comment useful. On Sat, Mar 23, 2013 at 11:39 AM, Daniel Freeman wrote: > I wrote one of those. I wrote SVG -> AS3 graphics. And extending that > class, I wrote FXG -> AS3 graphics. > > It wasn't a complete implementation of the SVG or FXG standards. It > didn't handle text, and complex gradients weren't perfect. The FXG class > was based on Adobe's first FXG definition. But it worked pretty well. > > This was one of the features of the applications I offered to donate. > > Actually, if you go back to build r53 of extendedMadness. SVG was in > there. I took it out, because I didn't think too may people would be > interested - and to reduce the bloat. (I didn't want my Framework getting > like Flex - did I), > > http://code.google.com/p/mad-components/source/detail?r=53# > > See example here: > http://code.google.com/p/mad-components/source/browse/trunk/MadComponentStuff/src/MadComponentsDesktop.as?spec=svn53&r=53 > > FXG isn't too different from SVG. > > > ... I've mentioned this before, but I'd like to relinquish control a > little over maintaining MadComponents, ExtendedMadness, and MC3D. I've > offered before to donate them to this Apache group. > > Bear in mind that people aren't using Flex to build mobile apps. They're > using MadComponents (General Purpose / Enterprise) or Feathers (Game UI). > In fact, I've had clients engage my freelance services because they tried > to build a mobile app using bloated Flex - and regretted it. > > > http://madskool.wordpress.com/2012/01/23/why-developers-are-using-madcomponents/ > > Is there any interest in this group in MadComponents? > > > On Sat, Mar 16, 2013 at 4:01 AM, Michael Schmalle > wrote: > >> >> Quoting Alex Harui : >> >> In my simple mind, Falcon generates the AST then at some point in time >>> the >>> futures task for that compilation unit is asked for output. Current >>> Falcon >>> code calls the BURM which eventually calls an emitter, I'm assuming >>> FalconJX >>> does an AST tree walk instead of calling the BURM. There is no >>> reduction, >>> just emitting. CSS for JS is probably just going emit text from the >>> tree. >>> >> >> Yes this is correct basically. >> >> Each compilation unit implements its own handleASBRequest() that gets >> called during a generator request. This request ONLY happens AFTER the >> handle AST and Scope requests have been processed. >> >> Its very complicated below that principle because of the future tasks and >> outgoing dependency requests that trigger other files to be parsed, scopes >> built etc. >> >> THe framework is elegant. The only thing I wish I could tear out and >> abstract is how they have SWF baked into ITarget and Target. >> >> This really makes it hard to do what we are doing without all this >> "baggage". >> >> As I said, parsing is multithreaded right now in FalconJx, I can easily >> get the source code generation multithreaded to now that I have learned how >> the framework wheels move together. >> >> I'm just not at the point to worry to much about it at the moment because >> in a couple of my test projects, the compiler is wicked fast, I also have >> an implementation that uses the Workspace and only loads config once, which >> is using the framework like and IDE does... >> >> Mike >> >> >> >> >>> On 3/15/13 1:44 PM, "Michael Schmalle" wrote: >>> >>> BTW, >>>> >>>> I have not seen one thing that you are asking for that doesn't contain >>>> an AST and node framework in the Falcon package. >>>> >>>> If it was me, I would create all the emitters exactly the same way be >>>> parsing the file, handling the AST, traversing it while outputting to >>>> the target, then writing it in its file format. >>>> >>>> Its simple and I guess the FalconJx framework is mainly due to me >>>> dealing with inheritance and dependency madness with Flex components >>>> for years. I said all my future projects will use composition, this >>>> one does big time. >>>> >>>> Mike >>>> >>>> Quoting Michael Schma
Stage3D accelerated Flex components
I've done some experiments with Stage3D accelerated Flex components, derived from MadComponents classes. http://madskool.wordpress.com/2013/01/21/madcomponents3d-part5-stage3d-accelerated-flex/ It is my intention to port MadComponents to AS"next". I propose that these ported MadComponents/MC3D classes might form the basis of a new Flex mobile framework that utilises hardware GPU rendering. I'm aware that Thibault Imbert has proposed that a new Flex framework should be based on Starling and Feathers. But I believe that the MC3D approach is better suited to the next Flex mobile framework. MadComponents is a fully fledged framework, not just a UI framework. It allows for versatile styling of components (without having to design texture skins), server communication, and memory management. However, until we know more about AS"next", which framework approach to choose is mostly speculation. So I'd like the members of this group to read my blog post, and let me know what they think.
Re: Stage3D accelerated Flex components
"I would expect the Open Flex group to put in the development work for this ? not me."... Let me clarify what I mean. It is my intention to port MadComponents/MC3D over to AS"next". This is quite an undertaking. Combined with the effort that I've already put into the framework, and the new GPU-enabled effects. To turn this into a Flex framework - all you'd need to do is write Flex wrappers. Along the lines of the examples that I demoed in 2011, but writing them in such a way as to maintain the familiar conventions of Flex in mxml. Also, tweaks to the MD3D classes to allow them to work within Flex. But most of the hard work will be already done. So this is a little more than free consultancy (although that in itself would have been generous).
Re: Stage3D accelerated Flex components
On Mon, Jan 21, 2013 at 10:31 PM, Avi Kessner wrote: > Conceptually, I don't understand why you would want to have more than "just > a UI framework", if your goal is to make use of the GPU. > > The fewer dependencies the better. > > @Avi, I see memory management, and server communication as important aspects of MadComponents. Not dependencies. How do you mean? @Michael, I don't see anything wrong with drawing a line as to how much more my time I can dedicate to this project. Or asking for commitment and work from the Open Flex developers. I just didn't want everyone to run away with the idea that I was going to do ALL the work (in my experience, people usually expect that). MadComponents/MC3D are free and open source. http://opensource.org/licenses/mit-license.php I wouldn't be adverse to maintaining it under Apache, as I think that getting more developers involved in the core MadComponents/MC3D classes could be positive. But it's a little early to talk about that now. I was thinking we should maintain the code separation between the Flex wrappers, and the core MadComponents/MC3D classes.
Re: Stage3D accelerated Flex components
@Mike, I've updated my wording slightly. But it's getting late (Brisbane time), and I'll see how things look in the morning. I don't apologies for carefully qualifying my expected contributions, and my expectations of other people's contribution. While I've changed the wording and dressed it up a little differently - I'm still not willing to write all of this for you - with no contribution from this group. As MadComponents has became popular - there's been increasing expectation on me to maintain, enhance, and support developers using it. While I've tried to share the burden with other developers - I've still had to contribute more time to this project than I've been comfortable with.
Re: Stage3D accelerated Flex components
@Om, I think people misunderstand what I've demoed here. The demo was a very quick and dirty proof of concept. An experiment I didn't want to spend too much time on - because too much investment at this time might be lost when we get to the other side of the AS"next" cataclysm. I could have subclassed viewStack and dealt with transitions there, solving any synch problems the way I do in MadComponents. But I went with a quick lash-up. My intention for MC3D"next" is to fully integrate Stage3D capabilities into MadComponents. Maybe you've noticed that my Stage3D MC3D classes aren't fully integrated into MadComponents. If you think that they're bolted on the side - you'd be right. And there's a good reason for this. Stage3D is bolted on the side of AS3. The further that I get into work-arounds, the more I'm probably wasting effort on matters that will hopefully be resolved in AS"next" anyway. I have a lot of display-list Sprite.graphics drawing going on right now. And unrestricted styling of display-list text. I'm hoping that AS"next" will provide new vector graphics and text classes for Stage3D - and if it does, re-writing my existing component rendering code might be straightforward. And I might not need a geometric renderer work-around after all. But I don't know yet. Personally, I wouldn't invest too much effort in a new framework now. ( Unless, you're on a beta programme for AS"next" that I don't know about ). For me, there are too many unknowns right now. If I were you, I would plan to work on this intensely on this as soon as an AS"next" beta programme kicks off. Om, I've come onto this forum being completely honest about my intentions. And people don't like my attitude. It is my intention deliver MC3D"next". Not Flex"next". My idea is to offer these classes as the basis for Flex"next" - if you want. On Wed, Jan 23, 2013 at 9:04 AM, Om wrote: > On Mon, Jan 21, 2013 at 3:30 AM, Daniel Freeman >wrote: > > > I've done some experiments with Stage3D accelerated Flex components, > > derived from MadComponents classes. > > > > > > > http://madskool.wordpress.com/2013/01/21/madcomponents3d-part5-stage3d-accelerated-flex/ > > > > It is my intention to port MadComponents to AS"next". I propose that > these > > ported MadComponents/MC3D classes might form the basis of a new Flex > mobile > > framework that utilises hardware GPU rendering. > > > > I'm aware that Thibault Imbert has proposed that a new Flex framework > > should be based on Starling and Feathers. But I believe that the MC3D > > approach is better suited to the next Flex mobile framework. > > > > MadComponents is a fully fledged framework, not just a UI framework. It > > allows for versatile styling of components (without having to design > > texture skins), server communication, and memory management. > > > > However, until we know more about AS"next", which framework approach to > > choose is mostly speculation. > > > > So I'd like the members of this group to read my blog post, and let me > know > > what they think. > > > > > Daniel, > > Thanks for your interest in helping out Apache Flex! > > I have been following Madcomponents and your blog for a while now. I > looked your example in your "stage3d accelerated flex" post [1]. While > that is good for a nice looking demo, I dont think that the approach you > suggest can be used to support an real framework like Flex. > > Whenever I see a reference to FlexGlobals.topLevelApplication anywhere in a > component's code, I always think of it as a hackish workaround trying to > cover up for the lack of a good design. More specifically, this approach > would blow up when there are two instances (Lists in your example) on the > stage and we try to animate both of them at the same time or at a slight > lag. The topLevelApplication goes invisible, the first List does its thing > on the gpu, then sets the topLevelApplication to be visible. Now, if the > second component had already started the transition, it would expect the > topLevelApplication to be invisible while it runs. But the first component > would have made it visible because it had finished running. This would > cause quite serious rendering issues to say the least. > > While I have your attention, I would like to talk about another blog post > of yours that I had bookmarked a while ago [2] Here, you talk about > building a set of UI components from scratch that would directly draw to > Stage3D (no starling or anything in between) I think that your ex
Re: Stage3D accelerated Flex components
@Harbs, Yup agreed. Wait until AS"next". My text wrapping (eMagazine) project seems such a long time ago. I had a couple of commercial enquiries about developing this further - but nothing materialised in the end. I moved onto other projects, planning to come back to this - but realistically I don't think I'll ever have time. OK - I could donate it to open-source if there was interest. I'd need to do a bit of tidying-up first. The AIR app is no longer available, but there are some youtube videos on my old blog: http://e2easy.wordpress.com/2009/12/03/first-beta-prototype-of-e2publish-here-now/ http://e2easy.wordpress.com/2010/04/28/e2publish-video-tutorials/ On Thu, Jan 24, 2013 at 5:39 PM, Harbs wrote: > I'm not sure that people have a problem with your attitude. (I definitely > don't.) I think that it wasn't totally clear what you were proposing. > > Basically, there's not much to talk about until ASNext is available and > the actual work on these components could be done. What you say about > waiting makes sense to me. It seems likely to me that building on your > components will make sense, but I don't see how we can know until we see > what develops between now and then. > > On a totally separate topic: > > I know you did work a while back on implementing text wrap for TLF. What's > the status of that work? Is it something you might consider donating? I'm > sure many of us would not mind polishing it up, if it's not yet ready for > publication… > > Harbs > > On Jan 24, 2013, at 4:23 AM, Daniel Freeman wrote: > > > @Om, I think people misunderstand what I've demoed here. The demo was a > > very quick and dirty proof of concept. An experiment I didn't want to > > spend too much time on - because too much investment at this time might > be > > lost when we get to the other side of the AS"next" cataclysm. > > > > I could have subclassed viewStack and dealt with transitions there, > solving > > any synch problems the way I do in MadComponents. But I went with a > quick > > lash-up. > > > > My intention for MC3D"next" is to fully integrate Stage3D capabilities > into > > MadComponents. > > > > Maybe you've noticed that my Stage3D MC3D classes aren't fully integrated > > into MadComponents. If you think that they're bolted on the side - you'd > > be right. And there's a good reason for this. Stage3D is bolted on the > > side of AS3. The further that I get into work-arounds, the more I'm > > probably wasting effort on matters that will hopefully be resolved in > > AS"next" anyway. > > > > I have a lot of display-list Sprite.graphics drawing going on right now. > > And unrestricted styling of display-list text. I'm hoping that AS"next" > > will provide new vector graphics and text classes for Stage3D - and if it > > does, re-writing my existing component rendering code might be > > straightforward. And I might not need a geometric renderer work-around > > after all. > > > > But I don't know yet. > > > > Personally, I wouldn't invest too much effort in a new framework now. ( > > Unless, you're on a beta programme for AS"next" that I don't know about > ). > > For me, there are too many unknowns right now. If I were you, I would > > plan to work on this intensely on this as soon as an AS"next" beta > > programme kicks off. > > > > Om, I've come onto this forum being completely honest about my > intentions. > > And people don't like my attitude. It is my intention deliver > MC3D"next". > > Not Flex"next". My idea is to offer these classes as the basis for > > Flex"next" - if you want. > > > > > > On Wed, Jan 23, 2013 at 9:04 AM, Om wrote: > > > >> On Mon, Jan 21, 2013 at 3:30 AM, Daniel Freeman < > madcompone...@gmail.com > >>> wrote: > >> > >>> I've done some experiments with Stage3D accelerated Flex components, > >>> derived from MadComponents classes. > >>> > >>> > >>> > >> > http://madskool.wordpress.com/2013/01/21/madcomponents3d-part5-stage3d-accelerated-flex/ > >>> > >>> It is my intention to port MadComponents to AS"next". I propose that > >> these > >>> ported MadComponents/MC3D classes might form the basis of a new Flex > >> mobile > >>> framework that utilises hardware GPU rendering. > >>> > >>> I'm aware t
Re: Stage3D accelerated Flex components
Sorry, yes. I was referring to the new roadmap.
http://www.adobe.com/devnet/flashplatform/whitepapers/roadmap.html
I've blogged about the news here:
http://madskool.wordpress.com/2013/01/30/adobes-cut-price-roadmap-and-mc3dnext
@Kevin, I can accomplish miraculous graphics performance when I code
natively in: Android Java / Objective-C / MarmaladeSDK, just using
canvas-style graphics: SurfaceView / Core Graphics / Iw2D - and I STILL get
better graphics performance than I can get fiddling around with Stage3D at
a low level, juggling with vertices, and indices, and AGAL shaders.
I'm pretty attached to freely styling component appearances, and freely
styled text labels. I don't want to build a framework where developers
need to make new SpriteSheets and Bitmap Font sheets - to change styling.
Right now I'm stuck with drawing to the display-list first, and then
converting DisplayObject surfaces to Stage3D textures. That's a
bottleneck. DisplayObject -> Texture.
I don't want to use the old legacy display list. So I've put in a feature
request for a better way to draw vector graphics and freely-styled text to
textures (or BitmapData, or some other data type that uploads quickly as a
texture).
For example:
texture.graphics.beginFill(0x00);
texture.graphics.drawRoundRect(10.0, 10.0, 100.0, 50.0, 20.0);
texture.graphics.drawText("Hello", 30.0, 40.0, textFormat);
