> I assume you are using -link-report and some viewer like ItDepends? Yeah. I did. I used LinkReportAIR for visualization, but it was not really that helpful.
What I found to be the most helpful was opening up the swf in Sothink SWF Decompiler. That allows me to see exactly what's in there. The results were pretty enlightening… ;-) On Mar 5, 2013, at 10:59 PM, Alex Harui wrote: > > > > On 3/5/13 12:54 PM, "Harbs" <gavha...@gmail.com> wrote: > >> My concern was really because selecting "Spark only" in Flash Builder makes >> those classes unavailable. I'm not sure how much of an issue that really is. >> Does that compiler option really make any difference in app size if you don't >> use mx components? > No, I don't think it makes a difference in the output. It just tries to > make sure you don't use those components at development time. > > Like I said, we can look into what would happen if we move those classes > from mx to framework. > >> >> I've been spending a LOT of time (like tens of hours) minimizing dependencies >> in my app. It's horribly painful... :-( > I assume you are using -link-report and some viewer like ItDepends? > > >> >> On Mar 5, 2013, at 7:26 PM, Alex Harui wrote: >> >>> I think you have to pick some goals. What is the main purpose of a Spark >>> Tree? Is it just to allow for Spark skinning of the control? Does it have >>> to run on mobile (Spark DataGrid is not recommended for mobile either and >>> the Adobe version of Spark Tree was going to be based on Spark DataGrid). >>> >>> If mobile isn't a requirement, then a dependency on ITreeDataDescriptor and >>> HierarchicalCollection isn't the end of the world. I think those classes >>> are now in the mx.swc which is in most Flex projects except for mobile. And >>> you can always map the classes in the manifest into the spark namespace (we >>> already do that for ArrayList) >>> >>> You could move some of these classes back into framework.swc so the default >>> mobile projects will have the classes, but check to see what else they drag >>> in so we know the full set of what we're moving. >>> >>> I believe the Spark Tree on my blog also used these classes. I don't recall >>> any real need to want to re-write the collection and descriptor APIs. >>> >>> -Alex >>> >>> >>> >>> On 3/4/13 11:29 PM, "Harbs" <harbs.li...@gmail.com> wrote: >>> >>>> On second blush, it looks like spark-tree has all of the same dependenciesŠ >>>> >>>> What's the correct way to go about this? >>>> >>>> On Mar 5, 2013, at 9:11 AM, Harbs wrote: >>>> >>>>> Okay. I'm looking into this now. >>>>> >>>>> I've tried Spark-Tree as well as this one. >>>>> >>>>> Both seem to have dependency on mx. >>>>> >>>>> Spark-Tree has a dependency on >>>>> mx.controls.treeClasses.ITreeDataDescriptor2 >>>>> >>>>> alatarus/tree has even more dependencies: >>>>> mx.collections.HierarchicalCollectionView; >>>>> mx.collections.HierarchicalData; >>>>> mx.collections.IHierarchicalData; >>>>> >>>>> An additional issue with Spark-Tree is a conflict between some style names >>>>> and private vars. That was easily fixed by renaming the vars. >>>>> >>>>> I think duplicating the ITreeDataDescriptor2 interface should be easy >>>>> enough. >>>>> >>>>> Anyone know who Kachurovskiy is for a donation? Alternately, Alexey, would >>>>> you be interested in donating your implementation? >>>>> >>>>> On Feb 25, 2013, at 2:42 PM, Alexey Taran wrote: >>>>> >>>>>> My implementation: >>>>>> https://github.com/alatarus/tree >>>>>> Supports sorting and filter function. >>>>>> >>>>>> >>>>>> 2013/2/22 Paul Hastings <paul.hasti...@gmail.com> >>>>>> >>>>>>> On 2/22/2013 5:18 PM, Bogdan DINU wrote: >>>>>>> >>>>>>>> Hi, I've used Kachurovkiy's version - seems well written. >>>>>>>> >>>>>>> >>>>>>> +1 (not that i'd know anything "well written" in flex but it works as >>>>>>> advertized). >>>>>>> >>>>> >>>> >>> >>> -- >>> Alex Harui >>> Flex SDK Team >>> Adobe Systems, Inc. >>> http://blogs.adobe.com/aharui >>> >> > > -- > Alex Harui > Flex SDK Team > Adobe Systems, Inc. > http://blogs.adobe.com/aharui >
