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 > > > -- John Grden - Blitz
<<winmail.dat>>
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
