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
