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
