Turn Off Double-Entry?

[Richard Gaskin]

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