On 8/8/05, Ethan Sutin <
[EMAIL PROTECTED]> wrote:
Debugger needs to integrate with a source editor for setting
breakpoints, etc...
john grden wrote:
> 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]
> <mailto:[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]
> <mailto:[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]
> <mailto:[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]>
> [mailto: [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] <mailto:[email protected]>
> > http://osflash.org/mailman/listinfo/osflash_osflash.org
> <http://osflash.org/mailman/listinfo/osflash_osflash.org>
> >
> > _______________________________________________
> > osflash mailing list
> > [email protected] <mailto:[email protected]>
> > http://osflash.org/mailman/listinfo/osflash_osflash.org
> >
> >
> > _______________________________________________
> > osflash mailing list
> > [email protected] <mailto:[email protected]>
> > http://osflash.org/mailman/listinfo/osflash_osflash.org
> >
>
>
>
> --
> John Grden - Blitz
>
>
>
>
> _______________________________________________
> osflash mailing list
> [email protected] <mailto:[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
--
John Grden - Blitz
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
