Opus 10 - Navigation Lock, and Rename

Does anyone else find that the Navigation Lock feature in v10 behaves very differently to v9?

I've had situations where I've been browsing through folders with navigation lock turned on, have lost the synchronisation, and even changed to an entirely different folder in an attempt to get synchronisation back.

It seems a little buggy, and more intrusive too.

Would it be better to have the information bar about losing synchronisation slide up from the bottom of the Lister view instead of the top? At least this way, files that I'm about to click on won't slide down and mean I end up clicking on other things.

Also, with the Rename dialog, there's a subtle behaviour change from v9 to v10 that is bothersome - in v10, if you change the rename type to "Find and Replace" (or any other option other than the default one) it resets the content of the Old/New filename boxes to the original content.

It didn't do this in v9, and I've grown accustomed to typing in my find and replace parameters, then tabbing into the type box and selecting find and replace using the keyboard - which in v10, resets the find and replace parameters and I have to tab back and do it again.

Would it be better to have the Type option before the old/new boxes so the tab chain doesn't have to be traversed again?

Hallelujah... someone other than me :slight_smile:.

[quote="GazChap"]I've had situations where I've been browsing through folders with navigation lock turned on, have lost the synchronisation, and even changed to an entirely different folder in an attempt to get synchronisation back.

It seems a little buggy, and more intrusive too.[/quote]
So, what you're seeing is what "I" have attributed to changes made in Opus 10 to try and be more intelligent about putting you back in either the first or last known in-sync position once sync is lost... and that's a worthy objective on the part of Opus.

However it's actually quite maddening when you "intentionally" go out-of-sync (say - in order to get some files or folders from someplace else that has nothing to do with my sync'ed navigation activity) but after which you want to go back to where you were last in-sync. In v9, if you DID go out-of-sync... as soon as you navigated your way around and clicked on a foldername that also existed in the other file display - you'd automatically go back in-sync without having to TELL Opus to explictly do so (via the "reset the sync position" link in the well-intentioned but oh-so-intrusive dialog box that shifts the display down a few rows - more on that below).

Also, in cases if you have MULTIPLE folder tabs on one of side of the dual-display - each of which perhaps contains a different "subset" of folders that are otherwise ALL commonly located in a single folder tab on the 'other' file display - switching tabs, then navigating to one of the folders located in your 'second' tab, but not in your 'first' causes you to go out-of-sync. Hitting the back button at this point then changes the 'second' folder tab to the folder path that the 'first' folder tab was opened to... clearly that's just plain wrong. But again, I think it's evidence of Opus trying to get you back to what it knew was an in-sync position.

Those are specific sorts of workflow scenarios I find myself in VERY often that I guess others do not - but in ANY case, my own feedback to GPSoft has been that any sort of folder action that Opus takes on it's own in order to try and re-establish sync AFTER going out-of-sync should be an optional setting. At least then - for whomever these changes are working out ok for - they can keep them; and for those of us who think Opus should just sit back and watch, we can kindly ask it to do so.

I welcome another voice on this - as the v10 behavior has unfortunately caused me to abandon Navlock for situations where I have lots of folder changes and do alot of transient out-of-sync navigation... in SOME of those cases, I've resorted to using my last v9 config from USB... but that's just a shame I have to do that - and I can't even rely on that for all cases since some of my workflows are related to things I've started using Libraries quite a bit for.

After alot of what I'm sure just came across as complaining (;-)) I just recently suggested the same thing if an option to re-enable the flashing File Display Border just wasn't something they could stomach... you'd still lose some visibility of files... but it wouldn't be any MORE loss of visbility than is currently the case - and it would NOT SHIFT the file display up and down. Somehow, I don't think I've managed to convince them that this is just totally intrusive, moreso than in any other situation in the application where this new non-modal message box appears - because it interferes with the sole purpose for which you're using Navlock... "navigating". Personally, I'd rather have the old flashing FDB. I guess some people were confused and didn't know what it meant... but I personally would have responded to such people with "RTFM" instead of implementing a method that was even 'marginally' intrusive to folder navigation.

For your other observations about the Rename dialog - it's best to open another thread for that as it's not specific to Navlock... Or, since it seems like it's a pretty straight case of un-desired behavior that could/should be "fixed", maybe just open a support ticket through the GPSoft website. I doubt there's much of a sensible "workaround" to what you're seeing there.

[quote="GazChap"]Does anyone else find that the Navigation Lock feature in v10 behaves very differently to v9?

I've had situations where I've been browsing through folders with navigation lock turned on, have lost the synchronisation, and even changed to an entirely different folder in an attempt to get synchronisation back.[/quote]

I haven't noticed it losing sync when it shouldn't.

Please given an example that we can try to reproduce, otherwise it is difficult to guess what you might be seeing.

One question per post, please.

But I agree, that behaviour is annoying (and you're right, Opus 9 didn't do it). I've put it on my list to look at.

In most cases, it's a similar situation to steje's post above, where I intentionally lose synchronisation to get files from elsewhere, but then Opus doesn't automatically "recover" the synchronisation once I double-click a folder that's on both sides.

In a few cases, once I've intentionally lost synchronisation, I've had Opus change one side to an entirely different folder (not in the navigation trail), and I think in one occasion an entirely different FTP site (that I previously had synchronisation on, not just a random one) to try and get sync back.

The latter cases are difficult for me to reproduce, as I often don't notice so can't reproduce the steps, but I'll see what I can do.

The biggest bugbear (for me) with v10's implementation is the slidey-down information bar. If that just appeared from the bottom of the lister instead of the top (and appeared "over" the files rather than pushing files up the list) it would be so much better. Right now, Opus loses sync but I don't notice straight away, and I'm trying to click on files near the top of the lister when the bar slides down and pushes them down.

Please given an example that we can try to reproduce

Hi Leo,

I think I am having a similar problem. Here is the description.


  • Single Tree
  • Dual Lister with Navlock
  • Viewer Pane
  • Four tabs on left lister, one tab on right lister


  • This is intended to be a layout to look at photos.
  • Each of the tabs contains one of my photo folders.
  • Lister one is in details mode.
  • Lister two is in thumb mode.
  • The viewer pane is on.
  • Minor point: Using tabs rather than a collection because I want to be able to customize the name of the folders (can do that for the tabs, while renaming the folders in the collection renames the actual folder)


  • At layout launch, listers are synchronized
  • On click in the tree, listers stay synched
  • If I switch tabs on the left, synch is lost. I have to click somewhere on the tree to synch again, then click in the tree again on the intended folder.

Is there any way to lock navigation so that switching from tabs 1 thru 4 on the left will display the same folder in the one tab on the right?

Many thanks and warmest wishes


That's normal. NavLock ties two file displays together, and each tab is a separate file display.

(Changing tabs doesn't just navigate you to another place; it hides the current file display and shows a completely separate one. It's like changing from one window to another.)

Hi Leo,

When I asked:

You replied:

Let me see if I understand correctly.

Are you saying that "No, at the moment there is no way to have a complete lock on the two sides of a dual lister"?

If so, since several of us see value in that functionality, that's now officially a feature request.

As you are well aware, it's a great feature of Opus to be able to look at the same folder in two views (such as details and thumbnails) simultaneously.
Right now Navlock is a "relative lock" to browse parallel paths, a relative lock that can be talked into working on a single folder.
What we need is an "absolute lock" that locks two sides of a dual lister together, regardless of what tab you choose.
I'll submit a ticket separately to make it official.

Thanks for your help.


Wishing you a beautiful day,

Well, I for one think it really is an all-together different sort of feature you're asking for. Can't say I can think of any scenario where I'd want or need to show the exact same folder in each file display with different view-modes (as you say - details/thumbs)... but that's just me. Certainly do submit a feature request to GPSoft for your idea :wink:.

I'm also not sure that browsing identical paths in each display is a very common use of Navlock in general. Personally... I'd prefer to have linked relative folder tab selection on each side of a dual file display. I.E. - as you've made note of, if you're currently in-sync, but then switch one of the displays to another folder tab that you might already have open, you then go out-of-sync. In what is a common scenario for "me", I have several different dual file display layouts and tab groups defined with upwards of 5 folder tabs opened on each file display, all to different folders. That said, I've got each set of folder tabs arranged in an order that mirrors my "intent" of navlocking each relatively positioned folder tab with one another. Meaning...

The 'first' folder tab on the TOP file display is a path that I intend to have Navlocked with the the 'first' folder tab on the BOTTOM file display. Likewise, the 'second' folder tab on the TOP display is a path I intend to have Navlocked with the the 'second' folder tab on the BOTTOM file display... and so on. With that being the use-case, the notion of "linking" the tab selection between each file display would be defined as a behavior whereby switching to a different folder tab on one display would cause the same relatively positioned folder tab in the 'other' file display to be activated - and for Navlock sync to be preserved as a result. Even holding down a qualifier key (like or something) when clicking on the folder tab in order to activate it would be a fully acceptable way to trigger such linked folder tab selection/activation behavior.

Anyhow... such a behavior could serve your needs as well - though to be fair you'd likely need to spend more effort "maintaining" left/right top/bottom sets of folder tab groups or go through a bit more work to update saved layouts in order to achieve the effect you're after; whereas a specific option to have the inactive folder tab "follow" the active folder tab path like you're suggesting wouldn't require any work at all on your part to take advantage of... I don't know how common a use-case that really is though, whereas I imagine the sort of scenario I described is fairly common amongst Navlock users.

Linking the top/bottom/left/right folder tab selection as I've put forth would cut down on ~some of the out-of-sync madness that is bothering me more in v10 than was ever the case in v9, and which is related to this OP.Speaking of which - for the ~main cause of the sort of out-of-sync irritation that's been blemishing my v10 experience (and seemingly echoed by the OP - and being, transient and intentional folder changes that result in loss of sync), I've taken to opening another lister all-together in order to temporarily go to other folders in order to grab files or do other transient tasks. It's not the loss of sync that's a problem in those cases... but the incorrect "guessing" on the part of Opus over how best to re-establish sync. I had been running v9 from USB for awhile for almost all of my Navlock chores - but since using Libraries alot more on Win7, as well as coming to use more features unique to v10 in my Navlock related workflows, I just can't get by on v9 anymore. I even ditched Navlock entirely for a few weeks out of frustration, but after years of working with it in v9 I've just come to rely on it too much to walk away. But the current behavior still makes this sort of case along with the sort of multiple-tabs-in-each-display scenario I described a bit of a BEAST to try and accommodate with Navlock in v10. And honestly, opening another lister to do the transient things that make it suck - ALSO kind of sucks. My muscle memory is slowly coming to grips with the need to do this, but it's not a happy place.

FWIW, NavLock already works fine with the same folder on both sides of the lister.

Why do you have the same folder open in multiple tabs?

If you just want a quick way to toggle between viewing a folder in Details and Thumbnails mode, using tabs isn't the best way; make a button/hotkey which runs Set VIEW=Details,Thumbnails instead.

Hi Leo,

Thanks for your message.

It's not the same folder. Each tab contains one of my picture folders.
I have a "Pix" button that launches a layout specifically to browse my pictures, in various places on the computer.

Many of these folders are called "Pix", so to have the layout display a collection of picture folders (instead of tabs) would not work, as I would not know which folders they refer to. (I can rename the tabs for each of the "Pix" folders, but if I rename the folders in the collection, the actual folders are also renamed.)

Thanks, great tip. But I don't want to toggle between Details and Thumbs. Rather, to see them both at once, hence the Navlock. On the left, Detail for grunt work. On the right, Thumbs for quickly finding the right files. And a viewer pane.

One of these days I'll send a screenshot of my toolbar to give you a sense of the kind of workspace that works for me. :smiley:
On a round of tweaking a the moment so a bit early for that.

Oh, so you want changing folders (or tabs) in one side to change to the same folder in the other side... I see what you were saying now. (That isn't much like navlock in that case.)

If I wanted something like that, I still wouldn't use tabs. Instead, I'd create some toolbar buttons (maybe in a menu, or in a toolbar I could toggle on and off as needed) with a button for each folder. Each button would navigate both sides of the lister to the designated folder (and maybe force Details and Thumbnails on the two sides in case it wasn't set that way already).

(You could also do that using Styles, instead of buttons, and Styles can look like a row of tabs if you want.)

Hi Leo,

Isn't that the beauty... Everyone has a different workflow, and Opus (usually) accomodates for our preferences.
For my workflow, I prefer one big button that brings up all my picture folders (in tabs) in a nice layout.

Styles would indeed be a great way to do what I need... if there existed a style that is not so much a "dual lister" as a "mirror lister", ie, two listers showing the same folder. (And one tree to rule them all.)

From the land of Mordor,

Wishing you a relaxing evening


ps: For now I will live with the loss of sync behavior when switching tabs, and patiently wait for the day when either "Absolute Navlock" or "Mirror Lister" gets implemented. :smiley:

For me, there's not much difference between a series of buttons to change folders and a series of tabs. (Other than that if you use buttons you can get what you want now, unlike tabs. :slight_smile: I guess the downside is that the buttons don't give a quick indication of the current folder, but you can get that via Styles...)

Styles can change the current folder in the left and/or right file displays, so I think they would also do exactly what you want (and also allow you to have something that looks like tabs if you prefer the look & feel of tabs over buttons).

Hi Leo,
Sorry for the gap.
I am trying to understand the solution you propose.
Right now, I have one button, "Pix", that displays a layout with a dual lister. The one on the left has all the picture tabs.
Are you suggesting that instead of that of a layout button, Pix become a Styles button?
Okay, so I create a Pix style. Single Tree, dual lister, viewer pane. For the left lister I define a set of tabs.
Now I go to my default lister (details / details).
I click on the Pix Styles.
This shows me a dual lister. The pix tabs are there, but so are all the tabs from the default layout. And I still don't understand how to implement navlock for these tabs.

So you must mean something else. Can you please explain?

Btw, hoping to have an iconset, buttons and screenshots to upload soon. :slight_smile:

Wishing you a fun day

No, create one style per folder, where the style sets both left and right displays to the desired folder (and has no other tabs).

Hi Leo,

Thank you very much for clarifying. I definitely don't think enough about styles.
If I go that way, as you say, I can make the styles look like tabs. I will give that some thought.
I think the options are clear for me now. Thank you for helping me think through them.

To summarize the discussion:

  • Styles Option. Pros: speed, synchronization without the tab glitch. Cons: Gui space, new style needed for each new pix folder.
  • Tab Option. Pros: economize GUI space, fast to add or delete a tab. Cons: lose sync when switching tabs.
  • Still hoping for an "Absolute Navlock" someday so that any shift on the left is reflected on the right, regardless of tabs.