good call
-----Original Message----- From: [EMAIL PROTECTED] on behalf of Martin Wood Sent: Mon 8/8/2005 1:37 PM To: Open Source Flash Mailing List Cc: Subject: Re: [osflash] OFD Project a couple of great feautures for a debugger as well are call stack and tooltips for source items that show their current value. :) Scott Hyndman wrote: > The core features of a debugger are as follows: > > -The ability to step through code > -Object inspection > -Watch windows (an auto-watch would be great) > -The ability to set and remove breakpoints while the debugger is running > > A few of these require source code to be displayed to the user. I'm just > wondering how AT can do something like this. > > /Scott > > -----Original Message----- > From: [EMAIL PROTECTED] on behalf of john grden > Sent: Mon 8/8/2005 1:21 PM > To: Open Source Flash Mailing List > Cc: > Subject: Re: [osflash] OFD Project > I guess I'm confused on what you think it should be doing then. load in > source files - what do you mean by this? > > On 8/8/05, Scott Hyndman <[EMAIL PROTECTED]> wrote: > >>That really doesn't answer my question. >> >>I'm interested as to how AdminTool will load in source files...and for >>that matter display them appropriately. I'm not saying AdminTool (and it's >>brethren) aren't useful, just that it just doesn't sound well suited for the >>task. >> >>/Scott >> >>-----Original Message----- >>From: [EMAIL PROTECTED] on behalf of john grden >>Sent: Mon 8/8/2005 12:31 PM >>To: Open Source Flash Mailing List >>Cc: >>Subject: Re: [osflash] OFD Project >>Well first, I guess a fundamental look at the AT first will help, then >>maybe >>that'll help solve whether or not you think it is or isn't a debugger. >> >>First off, I made the AdminTool out of need. I was in a job >>(zing.com <http://zing.com><http://zing.com>) >>where I need a tool that took me beyond the 1 dimensional debugger >>(Flash's) >>and well into the 2D world of Flash debugging. See, in the FAME world, >>it's >>easy to forget that this is a visual medium we're debugging - it's not >>just >>1 & 0's and form/data validation - our eyes are tricked by what we see >>(Chris, feel free to give up your example of 24 hrs wasted on a 'visual >>misque' that the AT helped solve in 5 minutes ;). So, with saying that, >>the >>Admintool is a debugger for EVERYONE who uses flash. Maybe calling it a >>"debugger" is loosly termed here - maybe we should put it in the Xray >>Scanner category. >> >>That's what the AdminTool's real mission has been: Make sense of of the 2D >>application Flash is showing us - to diffuse the confusion of what our >>mind >>sees in front of us. >> >>That's why "Logging" is only 1/10th of what the admintool does: >> >>1. Logging >>2. Treeview relationship of movieclips/buttons/textfields/objects/arrays >>etc >>3. Trace panel >>4. Execute panel - execute any line(s) of actionscript you want (does the >>Flash debugger- or any other debugger do that?) >>5. Change/update properties at runtime with more designer specific tools >>(jog wheel rotator, frame slider etc). ( won't even go into the many >>tools/ways you can play with movieclips/objects - too many to list) >>6. Control Video at runtime as well as view runtime properties of the >>NetStream object >>7. Control Sound at runtime. See your objects properties and change them. >>play your sound back and loop it >>8. Active highlighting - rollover objects in the treeview, highlights the >>object on stage makeing it far easier to ID movieclips that the freakin' >>designer forgot to give instance names to. >>9. Dragable - click on a treeview node and make the movieclip dragable >>10. Change history - after moving all your dynamic objects around on stage >>and changing their properties in the PI, get a list of those changes so >>you >>can use them in code/IDE >>11. FPS Meter >> >>And the list really does go on and so does the list of TODO's that I have >>planned for new features. >> >>So, I hope you can see, that the Admintool's much more than a logger - >>it's >>meant to be a all around Flash Controller/Viewer and the logging just >>happens to be in there ;) >> >>I'd love to get break points working personally, that would REALLY bring >>it >>into a very usable "debugger" for the hardcore Flash developers. That's >>why >>I'm out here at OSFlash.org and using FAME more and more. An ideal >>situation >>would be to develop the connection with sockets, like we've discussed here >>a >>bit, and allow the AdminTool, and any other logger out there, to hook into >>the API so that break points can be leveraged in a consistant manner. It >>doesn't make sense for me to add a middleware socket solution that needs >>to >>be installed JUST to use the Admintool. One thing that's really attractive >>about the admintool is that it's not proprietary - if there's a flash >>player >>installed on the user's computer, you can use that AdminTool. It's light, >>and fairly easy to use as well. And, I would argue, it's plenty powerful >>enough to debug the toughest applications out there (Gush being one of >>them). So, having a socket solution as an open source project makes total >>sense and allows me to retain the integrity of the Admintool's direction. >> >>So, sorry to be long winded, but I think an over view like this really >>helps >>people see what the AdminTool's directive is. Shoot, maybe I should rename >>the thing ;) >> >>Hope that helps, >> >> >>On 8/8/05, Scott Hyndman <[EMAIL PROTECTED]> wrote: >> >>>Could you explain to me how you intend for AdminTool to become a >>>debugger? Because I'm thinking about it, and I just can't see it. How do >>>you intend for this thing to work? >>> >>>/Scott >>> >>>-----Original Message----- >>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>>On Behalf Of Allen, Christopher S. >>>Sent: Monday, August 08, 2005 11:39 AM >>>To: Open Source Flash Mailing List >>>Subject: RE: [osflash] OFD Project >>> >>> >>>>IMHO There is only need for middleware if the UI does not support >>> >>>server >>> >>>>sockets. The protocol is quite easy to use and at best the middleware >>>>would >>>>only do some binary => xml translation which changing much of the >>> >>>data, so >>> >>>>most of the work have to be done on the display of the informations >>>>received. >>> >>>Nicolas, >>> >>>You are absolutely right about this. It's just that the AdminTool is >>>already >>>written in Flash and has most of the pieces in place for a full featured >>>Debugging tool. Therefore most of the UI work that you talk about is >>>done. It >>>would be a shame to have to rewrite all of that. And in terms of >>>performance, I >>>haven't really had any issues using the AT. So this is really the >>>reason for >>>this middleware idea. >>> >>>As you already pointed out, this piece would really be very simple >>>binary => xml >>>translations, and I think that's a good thing. >>> >>>-Chris >>> >>> >>> >>>_______________________________________________ >>>osflash mailing list >>>[email protected] >>>http://osflash.org/mailman/listinfo/osflash_osflash.org >>> >>>_______________________________________________ >>>osflash mailing list >>>[email protected] >>>http://osflash.org/mailman/listinfo/osflash_osflash.org >>> >>> >>>_______________________________________________ >>>osflash mailing list >>>[email protected] >>>http://osflash.org/mailman/listinfo/osflash_osflash.org >>> >> >> >> >>-- >>John Grden - Blitz >> >> >> >> >>_______________________________________________ >>osflash mailing list >>[email protected] >>http://osflash.org/mailman/listinfo/osflash_osflash.org >> >> >> > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > osflash mailing list > [email protected] > http://osflash.org/mailman/listinfo/osflash_osflash.org _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
<<winmail.dat>>
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
