GP SoftwareTwitter
Opus FAQsManualCommandsObjects

NavSync - an alternative to NavLock


#1

PHPBB_IMPORT_WARNING CODE_NEAR_LI

Note: I rather imagine this script will work with earlier releases - but as most of the finishing work on it was done on Opus Beta builds 11.16.1.0 and 11.16.3.0, and some sanity testing on the most recent stable release 11.17.0.0 - I went ahead and made the minimum release 11.16.0.0.

This script was written for ME, and indirectly - maybe a little bit for Jon and Leo, since I’ve been a bit of a prick to them over the past few years since the old NavLock behavior from v9 was changed… So now they don’t need to hear me whine about it anymore :slight_smile:. I had actually intended to finish this script LONG before now - I started this during the original v11 BETA’s when scripting was first implemented, but hit a bunch of limitations at the time and put it to the side. But GPSoft have made so many awesome improvements to the scripting interface since then - it’s time to finish the damn thing! Also, with having recently started working with multiple Opus configs for different environments, as well as using multiple monitors much more frequently than I used to - the fruits of the labor are enough to get me to work on it!

So ENOUGH preamble… however, just know that THERE ARE SOME ISSUES WITH THE SCRIPT… see next post for details!

What does it do?:
The purpose of this script is to provide an alternative to the built-in NavLock feature in Opus. The differences between this script and NavLock are as follows:

Loss of sync notification:

  • NavLock throws up a slide-down notification at the top of the file displays with useful options for handling loss-of-sync situations, but I find that method far too disruptive to my use of the file display. Like… REALLY!
  • NavSync instead provides several user-configurable options that allow control over how the script notifies you of a loss-of-sync condition. The Script Configuration option that controls this is SYNC_LOSS_PROFILE, and it allows the following selections:

[ul][li]NONE: No action is taken when loss-of-sync occurs.[/li]
[li]CUSTOM: When set, the script will look for the Opus Command values set by the user in each of the SYNC_LOST_ACTION and SYNC_REC_ACTION script config options.[/li]
[li]FORMAT: The script will change the folder format of the linked tab(s) that lost sync to a user-defined favorite format that must be called ‘navsync’. The user must first create this format themselves for this option to work.[/li]
[li]RESYNC: The script will attempt to automatically create the missing folder path(s) to automatically recover (really, prevent) loss of sync… If the attempt fails, no obvious action is taken other than any errors that might be thrown by the failed attempt to create the folder.

NOTE: This behavior can also be triggered on-demand by the NavSync RESYNC command.[/li][/ul]
Multiple Lister support:

  • NavLock only works with two FILE DISPLAYS in the same lister.
  • NavSync works with tabs across multiple LISTERS in order to make NavLock-like functionality available to users who want to sync navigation across listers. This is an obvious nice-to-have for those of us that work with multiple monitors.

    Switching between tabs:
  • NavLock establishes a link between the current paths in each file display. In cases where you might have more than just TWO sets of similar folder structures, switching to one of them in another tab once you’ve navigated down the folder tree in the initial TWO synced tabs makes it cumbersome to true up the THIRD tab with either of the other two without seeing alot of the crazy out of sync notifications described above, as well as some cases where you end up with the exact same paths in both tabs, which I don’t think I ever want to have happen :slight_smile:
  • NavSync allows the user to switch tabs similarly to how linked slave tabs work where the synchronized navigation takes place explicitly between the linked tabs as opposed to whatever the current source and destination tabs are (which could be different than the tabs that are actually linked).

    FUTURE == Optionally handle different tab situations in either of the following ways:

    [ul][li]Automatically attempt to position the newly activated folder tab to the same relative position as the folder tab which was just left (the one that was just deactivated, in the same file display). If the path is not valid, optionally prompt user to perform the ‘resync’ function in order to create the missing folder path(s) in the newly activated tab.
    [/li]
    [li]Automatically ‘reset’ the tab in the other file display back to the initial folder path it was in when NavSync was turned on. This is to provide an easy way of enabling NavSync between one of the originally synced tabs and the newly activated one - assuming the new tab has been opened to a common enough starting point with a similar folder structure as the other tab in the original synced pair of tabs…[/li][/ul]
    Multiple (more than 2) tab support:
    FUTURE
  • NavLock only works with TWO tabs (again, in the same lister).
  • NavSync WILL support link and sync of up to FOUR tabs, open across up to FOUR listers by creating a vector of linked tab ID’s in the navsync environment variable of each tab. A more common use case than FOUR separate listers is probably two dual-display listers…


    How to install and use it?:
    The script is provided here as an Opus Script Package… which in turn is actually a zip file with a VBScript packaged inside. It can be installed by either manually copying the OSP file to the /dopusdata\Script AddIns folder, or via drag-and-drop into the Preferences / Toolbars / Scripts page.

    NavSync.osp (8.09 KB)
    Notes:
    2015-12-18: v1.0.9 (vb) - Initial release…
    2015-12-23: v1.1.1 (vb) - Update release: Re-implemented as a BeforeFolderChange event handler.
    2016-01-01: v1.2.1 (vb) - Update release: Had some failures in some Library path situations, so started using FSUtil.DisplayName to strip out the “?” based member folder notations from the path strings before comparisons, checks and log messages.

    In addition to the script package, here is a sample Toolbar Button that calls the Script Command implemented by the script to control NavSyncs’ features. You can copy and paste the code below directly to your toolbar… It’s a three-button button, where the LMB toggles Navsync ON and OFF, and the RMB opens a menu with buttons for the TOGGLE, RESET, RESYNC and STATS commands. Details on these commands are provided below…

    <?xml version="1.0"?> <button backcol="none" display="icon" label_pos="right" separate="yes" textcol="none" type="three_button"> <label>NavSync</label> <icon1>#navlock</icon1> <button backcol="none" display="both" label_pos="right" textcol="none"> <label>NavSync</label> <icon1>#navlock</icon1> <function type="normal"> <instruction>@toggle:if $src:navsync</instruction> <instruction /> <instruction>@ifset:$src:navsync</instruction> <instruction>NavSync OFF</instruction> <instruction /> <instruction>@ifset:else</instruction> <instruction>NavSync ON</instruction> </function> </button> <button backcol="none" display="both" label_pos="right" textcol="none" type="menu"> <label>NavSync Tools</label> <icon1>#navlock</icon1> <button backcol="none" display="both" label_pos="right" textcol="none"> <label>NavSync TOGGLE</label> <icon1>#navlock</icon1> <function type="normal"> <instruction>NavSync TOGGLE</instruction> </function> </button> <button backcol="none" display="both" label_pos="right" textcol="none"> <label>NavSync RESET</label> <icon1>#navlock</icon1> <function type="normal"> <instruction>NavSync RESET</instruction> </function> </button> <button backcol="none" display="both" label_pos="right" textcol="none"> <label>NavSync RESYNC</label> <icon1>#navlock</icon1> <function type="normal"> <instruction>NavSync RESYNC</instruction> </function> </button> <button backcol="none" display="both" label_pos="right" textcol="none"> <label>NavSync STATS</label> <icon1>#navlock</icon1> <function type="normal"> <instruction>Set UTILITY=OtherLog</instruction> <instruction>NavSync STATS</instruction> </function> </button> </button> </button>
    After installing the script package, users can modify the options described above to control things like the logging level, and what type of actions to take when a loss-of-sync condition occurs… This can be done via the scripts Configuration dialog.



    The script configuration provides the SYNC_LOSS_PROFILE option for overall control over the scripts behavior when loss-of-sync occurs. By default, it is set to NONE. It also allows the user to select CUSTOM which will then read user defined commands to take when sync between source and linked destination tabs is both lost (SYNC_LOST_ACTION) and recovered (SYNC_REC_ACTION). As an example, if you might usually use this script in a single dual-display lister, perhaps you could set a SYNC_LOST_ACTION of “Set DUALSIZE 10”, and a SYNC_REC_ACTION of “Set DUALSIZE 50”… or whatever other command might give you a more agreeable visual indicator that sync has been lost. If the CUSTOM profile selected, but no commands have been entered in both the SYNC_LOST_ACTION and SYNC_REC_ACTION options, the script will behave as if NONE had been selected in order to avoid errors.



    Personally, I have the SYNC_LOSS_PROFILE option set to FORMAT. As mentioned above - this option requires the user to create a standard Opus FAVORITE folder format in Preferences that change the current folder format to something visually unique. For myself, I’ve created a format that sets the background image to a large folder icon with a lock symbol on it, as well as sets the background color to an opaque-ish red color (RGB = 255, 175, 175). This (to me), is a far less disruptive style of notification that sync has been lost than what we get with the built-in NavLock feature, and was the primary motivation for me to start writing until I started heavily using multiple monitors. However, there are some caveats (see the NOTES in the next post).

    In addition to the Event Handler that does the work when you change folders, the script also implements a Script Command (NavSync) that has several options to control the behavior of the event handler. These are the commands that the sample toolbar button runs:

    [ul][li]NavSync ON: Explicitly sets NavSync to ON. If NavSync is already enabled for the source tab when you run this command, any existing NavSync relationship will be cleaned up and a new one set for the cuurent source and destination tabs (see the NOTES in the next post).[/li]
    [li]NavSync OFF: Explicitly sets NavSync to OFF.[/li]
    [li]NavSync TOGGLE: As with most Opus RAW commands, toggles between and off. Honestly, probably not super useful since any toolbar button relies on environment state to show enabled vs disabled, and the checks to do so make it more sensible to just use explicit ON/OFF commands instead. But… it’s in here.[/li]
    [li]NavSync RESET: The RESET option moves the source and destination tabs back to the folder path when NavSync was initially enabled. This is safety net for in case my logic (which has some issues) falls apart and you find yourself out-of-sync even though you should be good to go. This gets you back to sanity without having to just turn NavSync OFF, then manually reset the paths in each folder tab back to the initial paths you were in when turned on NavSync.[/li]
    [li]NavSync RESYNC: This is an on-demand command that does a one-time operation the same as setting the SYNC_LOSS_PROFILE Script Configuration option to RESYNC. It causes the script to attempt to recreate the missing folder paths in the destination tab that were missing and caused you to go out-of-sync. This command option can be used however many levels down you might be out-of-sync. In other words, you don’t have to do it 5 times if you’ve gotten 5 folder levels out-of-sync deep in the source tab. Just get all the way down through the folder structure you’re trying to get to in the source tab, and then run this command. It will create all the intermediary paths in between where the destination(s) originally lost sync and wherever you find yourself.[/li]
    [li]NavSync STATS: This is really a debug commands to spit out the current environment variable values in effect whenever this command option is run. If you’re getting really weird results - I’d ask you to enable the DEBUG Script Configuration option and repeat whatever steps caused things to go nuts and then post the script output log. But sometimes this might be useful to work things out on your own even without debug logging without previous actions captured in-log.[/li][/ul]

THERE ARE SOME ISSUES WITH THE SCRIPT… see next post for details!

Appreciate any and all feedback!


LinkedTab_AutoOpen_Handler: Open related folder tabs automatically
LinkedTab_AutoOpen_Handler: Open related folder tabs automatically
#2

As mentioned above, THERE ARE SOME ISSUES WITH THE SCRIPT

Firstly, the scripts behavior after sync has been lost, and particularly after a RESYNC operation has been performed - attempts to preserve the back/forward history of the sync’ed tabs involved, but once you’ve gone out of sync - depending on how many levels down you may have gone before manually triggering a RESYNC - then going BACK in the out-of-sync tab can goof up the ability to preserve back/forward history at the same time between the tabs.

In addition, though I really like the FORMAT behavior of the script, when encountering the sort of situation above (and a few others) it can happen that even though you are properly in Sync (folder changes continue to work between linked tabs), you may see the sync-loss (navsync) format in one of the file displays. It’s usually just because Opus is “remembering” the format that folder had when I set to the sync-loss (navsync) format, and is just re-applying it like it normally would when going back or forward to that same folder. I may switch to reverting the format BEFORE changing paths on sync-loss recovery to solve it, just don’t want alot of visual jerking around…

Not so much an ‘issue’ with the script - but a side effect of all the code running after the “source” tab has already switched folders… there is a noticeable LAG in the linked (destination) tabs folder change. I may consider re-implementing this as an OnBeforeFolderChange event handler script to improve that in the future.

The script works just fine with LINKED tabs, I use it myself. However, things get real screwed up if the linked tabs are also SLAVE tabs. The script will look to see if any of the tabs it’s being asked to sync are slaved… and abort if that is the case (at least when trying to toggle it ON). I have to add a similar check to abort if NavLock is enabled. I meant to do that before posting the first release - but forgot :slight_smile:.


#3

So here’s my lister when I go out of sync - with NavSync set to use the FORMAT control:


Particularly since I am making folder changes to the SOURCE tab (on the LEFT) and ~want to be doing so, I prefer the notification about going out of sync to appear in the DESTINATION tab. I don’t want the notification to visually disturb me in the SOURCE - where I’m still actively working.

Here’s what happens in the same lister with NavLock:


With NavLock, the notifications routinely ruins my navigation when I am muscle memory clicking through the first or second sub-folder in the source display. I’ll often hit the Name column and resort the list because of where the notification drops down.

And here’s what happens in the same lister with the linked tabs set to slaved as well (denoted by the italicized text in the tabs):


I don’t really understand why - if having opened DIFFERENT folder paths to begin with - it’s ever useful to all of a sudden have both displays show the same folder. But to each their own… I could certainly implement that in NavSync as an additional option, with the upshot that the BACK/FORWARD histories should then be preserved much more easily than my script can manage after loss-of-sync conditions at the moment.

Anyway, this was just an example visual explanation of the differences in behavior between the built-in features vs NavSync. If other ppl care to give it a try - I can certainly add other ways of handling and recovering from loss-of-sync. Perhaps some ppl like message popups :slight_smile:


#4

Yeah, an OnBeforeFolderChange variant of the script is alot smoother visually. Needs some additional work before ready for posting…


#5

Root post updated with new version of script - re-implemented as a BeforeFolderChange event handler.

Also noticed when my laptop was particularly busy thrashing disk or cpu that new tabs in newly opened layouts would sometime linger on ‘Empty Tab’ state before filling in having read the folder. To be fair, it happens even without the script, but I added a first check for Tab.initial to try and speed things back up when launching new listers. Seemed to help ~marginally.

There are also some logic changes - where I now revert the format as soon as I detect that the new destination/linked tab exists. I’m hedging bets that the folder read will work if the folder exists.

In light of that statement - it’s worth noting that there is very little testing of this script when directories that exist can’t be read in the destination (say perhaps due to permissions issues). Something I’ll need to do something about sometime soon.

Also some logic changes in how loss-of-sync is handled. Still trying as best I can to preserve each tabs ‘history’. As long as navsync is in fact in a synced state, the script will rerun whatever action changed the source tabs path (back, forward, parent, etc). But if sync has been lost, then changing folders in the destination will be an explicit ‘Go PATH’ action - thereby trashing the sync of the history between tabs.

I’ve posted several enhancement requests that would let me manage things alot better, as well as be useful for other scripting ideas.


#6

Posted an update to fix some failures with Library paths due to the member folder “?” being in the path string and throwing off path comparisons.

Also experimenting with a folder format to be applied when setting NavSync ON, and when re-syncing… based on the clamor of requests for such from the one other user trying out NavSync - ROTFL…


#7

Whaaaoooh Steje !!!

This is one amazing script. :thumbsup:

I have also mixed feelings about Navlock and Slave tabs…

I used to use Navlock, but I always found that the fact you can only use it with 2 tabs very annoying
Then I discovered Slave tabs, which works better for my workflow (I try to use only one lister, so I like to open other tabs then come back to my linked tabs), except I really dislike when It gets out of sync…

Here comes NavSync… which tries to bring the best of both worlds :wink:

The thing is … I use Navlock or Slave tabs to navigate both locally and online (ftp servers) and that DOES NOT work with NavSync :frowning:
an other thing I miss is the coloring and icons of the synced tabs.

Well anyway, big up to you and thanks for the script.
Hope maybe you can make it even better :wink:

do you have other scripts ??

Nitrix


#8

Note that the behavior of slave tabs in Opus 12 is now identical to navigation lock (they are basically the same thing now, except navlock always works between the two active tabs).

Additionally navlock is much better at staying in sync (or getting back in sync) than it was in Opus 11.

(And for steje’s benefit, the “out of sync” message is nicer too :slight_smile: )


#9

Great!

i will try it right away :wink:


#10

I’ve got some significant weirdness with this script in v12 that I’m hoping to chase down soon.

FWIW - Jon made some good behavioral changes to standard Navlock in v12 which I appreciate alot. In fact - there are times now when I have two listers open (1 on each of my 2 monitors), use NavSync to bind the two single pane listers together, then additionally open dual file displays in each one and enable standard Navlock within each lister to sync the two local file displays.

The result is I’ve got 4 file displays that are synced together. I don’t expect many ppl to have the same sort of use cases as I have in order to appreciate the usefulness of this - and it’s imperfect since it doesn’t provide all of the NavSync features in all 4 file displays… but, I dig being able to do it when I have some data that I want to manually copy to 4 different drives that I know already have all the same dir paths (so I happen to know I won’t have an out-of-sync condition).