> 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.
yes, a socket solution would be great. i have experimented with sockets in firefox (you can open sockets for XUL and handle the data with javascript), but unfortunately the socket takes only one piece of XML from the SWF (until the \0 byte, sending data to the SWF works fine). however, i've seen the SWF<->javascript example you added to the flash8 page on the wiki, maybe this can be used for the SWF<->AT connection in an AT-firefox extension? mark On 8/8/05, john grden <[EMAIL PROTECTED]> wrote: > 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) > 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 > > > -- http://snafoo.org/ jabber: [EMAIL PROTECTED] _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
