David Burgun wrote:
On 25 Apr 2006, at 19:23, Jim Ault wrote:
Later I am switching windows and happen to click on the Replace
button, and
without realizing it, I have replaced the string "tCounter" with
empty in
every part of my stack script. There is no undo for this, even if I
realized my mistake the moment it happens.. I wish I could get in
the habit
of Always changing from the Find mode of a script window, but not yet.
I would prefer a hidden Replace function since it is so dangerous.
It would be better to have a separate Find/Replace dialog box like
most IDE's I've used IMO.
I NEVER use the find+replace function in the Script Editor, it's way
too dangerous in other ways too. For instance the "whole words"
option doesn't work right, or works oddly in some situations.
I usually copy the whole script into a CodeWarrior window and do the
Find/Replace and then copy back.
Ouch. Sorry to see you work that hard.
What works for end-user apps is sometimes suboptimal in a development
tool.
While it's admirable in many applications that provide search to put it
right in the window like OS X does in the Finder, it's worth noting that
Apple's XCode editor doesn't. XCode's powerful Search and Replace
dialog is a separate window, as it is in MetaCard and will remain when I
externalize its script editor as a plugin.
The windowBoundingRect is another area where what works for end-users
often causes problems for developers: toolbars should rightfully adjust
the windowBoundingRect so maximized windows don't "submarine" their
controls under the toolbar. But a developer isn't just *using* software,
she's *making* software, so she needs the freedom to see how windows
will behave on their own without the IDE changing the way the
environment works. Look at the number of posts to this list expressing
confusion over window placement to get a feel for the scope of this
issue. Adding a simple vertical drag bar to the Mac toolbar so it can
be moved like it can on other platforms takes care of the issue in just
minutes, provided the IDE leaves the windowBoundingRect under the
control of its user.
devolution 2.0 will have an Inspector modeled after the one in
Macromedia Fireworks, which normally sits as a long slender bar across
the bottom of the workspace. It has a vertical drag bar so it can be
moved if needed, and double-clicking the drag bar causes it to snap back
into its preferred location. Simple stuff.
Stepping back to look at the bigger picture, many of these issues come
down to grokking the central role of the engine in the larger story of
the total workflow, accomodating the need to observe and understand the
inherent behaviors that the developer will be delivering to their own
users. A development tool that includes a deployable framework, such as
one might consider the engine, is indeed two separate entities.
Even a well-intentioned desire to blur the lines between the engine and
the IDE in an attempt to provide the appearance of a single cohesive
product ultimately misses the point of such a product: the product
itself is unimportant, what's important is the product its user will
create with it. Maintaining clarity about what the developer uses and
what the developer deploys helps move that along.
An IDE that minimizes the distance between the developer and the engine
they'll deploy to their end-users may not allow as much hand-holding
convenience in some respects, but will make for a more empowering and
productive experience over the whole of its user's development cycle.
Know the engine.
Use the engine.
Trust the engine.
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
