Feature Survey for next Navigator

[Geoff Canyon]

Navigator 3.0 <http://www.inspiredlogic.com/navigator/> (page not 
updated yet) is about ready to go final, so this young man's fancy 
turns to features. ;-) Here are a few that I'm thinking of. Feel free 
to comment on how useful they would be, or add your own.

-- Custom properties in a list
With 3.0, I added the ability to show an object's (or a group of 
objects') standard properties in a list. It would be good to be able to 
display custom properties in a list like that as well, with the ability 
to switch between custom property sets, or to display them all at once.

-- Standard properties in an organized list
Currently the standard properties list displays the standard properties 
alphabetically. Would it make more sense to have them grouped by family 
-- colors together, dimensions and locations together, etc.?

-- Inherited properties available in list
I'm thinking of a way to display an object's inherited value for a 
property in the property list. Maybe put it in parenthesis? Currently 
editing a value in the list edits the property's actual value, so if a 
card's backcolor is empty, editing it shows empty. If I add inherited 
values, it would display the inherited value and you'd have to blank 
the entry field to retain the existing value. I'm not sure I like that. 
Likewise, making the default the existing behavior and making some 
other method edit the inherited value would hide the ability to edit 
the inherited value.

-- (really geeky) Edit inherited values directly
Let's say that a card has no backcolor, but the backcolor of the stack 
is red. Let's say you want to change the card's color, but you don't 
want to set it directly -- you want to change the color of any cards 
that also inherit that color. It would be simple enough to allow you to 
edit the properties of the card, see that the inherited color is red, 
and let you edit the backcolor of the stack directly from that point. 
You could change the color of all the cards that inherited that color 
by editing from any one of them. I'm betting no one would ever think to 
use that, but I'm offering it as an idea.

-- Drag and Drop between copies of Navigator
Currently you can have two copies of Navigator running at the same 
time. (The limitation to two will be removed based on an upcoming 
release of Revolution) You can copy and paste objects between them, 
copy and place backgrounds between them, etc. You can drag and drop in 
a single instance of Navigator to change the layer of an object, place 
it into a group, etc. How beneficial would it be to drag an object out 
of one copy of Navigator and into another copy of Navigator? This would 
make it easy to move stacks from one mainstack to another, copy cards 
from one stack to another, and copy objects and groups from one card to 
another or to another stack.

-- Navigator Front Script
Navigator already uses a frontscript when it runs in the MetaCard 
environment. In Revolution, it uses only the built-in messages. With a 
frontscript, it would be possible to have a key combination to show the 
properties list in Navigator for the selected objects, or to bookmark 
the selected objects, or to copy (in Navigator) a reference to the 
selected objects. Any of these could be applied to the mouse object as 
well. This is one of my most wanted features, but I hesitate to add a 
frontscript.

-- More editors
Navigator currently has custom editors for colors and resizing. Are 
those useful? What additional editors might be helpful. One I'm 
considering is a simple "move" dialog -- one that moves the hilited 
objects based on your input. I'm thinking that would be useful in cases 
where the object was invisible, in a group, or locked.

-- Command to locate a handler
Navigator can currently open the script editor directly to any handler 
in an object's script. If an object's script calls a certain handler, 
there is no good way to get to that handler unless you already know 
where it is. I'm thinking of a command in Navigator that lets you 
hilite a control, enter a message name, and opens the script editor for 
the object that contains the handler that will receive that message if 
it comes from that object. A limitation is that the command chain in 
Revolution is dynamic. With frontscripts it's possible that at runtime 
another object's script could intercept the message. But that seems 
like a small thing compared to the general utility of such a command.

If there are others, feel free to chime in. Don't tell me to add 
animated graphics; I can't draw and Navigator is supposed to be clean 
and simple ;-)

regards,

Geoff Canyon
gcanyon at inspiredlogic.com