Navigator 6.4 alpha 1 is out

Geoff Canyon gcanyon at gmail.com
Tue Sep 25 00:19:23 EDT 2018


I forgot -- I also added in-line editing of properties identified as
single-line in Navigator's property editor. Meaning:

1. If the property is "colors" (this would only be displayed if you add
colors to the control's properties in Navigator's preferences dialog) then
Navigator will immediately open the color editor.
2. If the property is true/false, it will simply toggle between those two
values.
3. If the property has a defined set of values (the style of a button, for
example) then the list of styles will pop up for you to select. If I have
missed any of these in Navigator's configuration, let me know.
4. If the property is defined as single-line in Navigator's configuration,
it will edit in-line in the property editor. This is also a configuration
in Navigator, so if I have missed any of these, let me know.
5. If none of the above apply, the standard Navigator editor window will
open.

gc

On Mon, Sep 24, 2018 at 8:19 PM Geoff Canyon <gcanyon at gmail.com> wrote:

> As usual, you can get Navigator here
> <https://www.dropbox.com/s/kz3zqi4botzglgq/navigator.zip?dl=1>. Or grab
> it from GitHub <https://github.com/gcanyon/navigator>.
>
> 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"?
>
> NEW FEATURES
>
> 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
> done.
>
> 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
> enhance this.
>
> 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 somewhat
> retained -- as long as the control's long id doesn't change, it should
> continue to be hilited. This means dragging controls into or out of
> groups breaks this functionality, and situations where the control is
> copied will break it as well.
>
> regards,
>
> gc
>



More information about the use-livecode mailing list