Phew! I discovered a brutal bug in Navigator while coding this update.
Everyone should either update, or avoid the "Save All" and "Save
Stackfiles" popup menu options. The code that iterated over the stackFiles
of a stack to save them all didn't have a test for existence, and thus if
any stackFiles were deleted, but still in the stackFiles property of the
stack being saved, then the loop would die (silently, because of the "rev"
prefix) and not save the remaining stackFiles. I have no idea how I managed
to work on Navigator for the past eight months, using this feature *all the
time*, and not run into this before. But in this case, I ended up having to
code -- and lose -- the functionality listed below *twice* before I twigged
to what was happening. :-(
In any case, the "Save All" function now checks for existence on each stack
before attempting to do anything with it, and if any are missing, will
offer to update the stackFiles property to remove the ones that are missing.
As an aside, does the IDE have any sort of equivalent function? i.e. "run
through the stackFiles of this stack and save them all"?
The "Edit Colors" option on the popup menu now works -- it worked before on
the Properties menu.
Completely reworked the mouse-targeting options:
-- Choose Color
-- Stack menu -> the mouseStack
-- Action menu -> Bookmark -> MouseControl
You no longer need to hold down the option key while using these commands
-- I believe this made these functions useless under Linux, as well as
making them harder to use in general. Instead, as soon as you trigger the
command, Navigator displays a cross-hair. Mouse over the
color/control/stack you want to select, and click, and the selection is
Updated the mouseStack command so that when Navigator displays the current
card of the stack you select, the control the crosshair was over when you
made the selection is hilited in Navigator's list. This has been an awesome
feature for me, I hope it delights you as well, and I'm looking to further
Fixed (I believe) an error where sometimes Navigator would think that it
was still dragging even after the mouse is up. It was tricky to get this to
happen, so we'll see...
Fixed an error in the placement of the drag and drop controls when dragging
from one Navigator to another. This had previously been fixed for dragging
within Navigator, but I just found the remaining issue.
Improved Navigator's handling of hilites when cloning, deleting, and
dragging and dropping, but it's by no means perfect yet. There was an issue
where Navigator's record of what lines are hilited wouldn't be updated
after cloning or deleting controls. This could lead to weird dragging
responses, and this has now been fixed.
Also, you should find that when dragging a control, hilites are retained
*as long as the control's long id doesn't change*. This means dragging
controls into or out of groups breaks this functionality. I'm not 100% sure
that I haven't made some aspects worse at the same time as fixing others --
drag and drop is the bane of my existence -- but I'll compare to what I had
a week ago and take the best of both if possible.