Is there a way to mark multiple files or folders so that they always appear at the top of the lister, regardless of sort order (of the rest of the lister)? It would also work if I could define a wildcard for this for example "__*". Or a split lister could also work, so that you can sort the top section one way, and bottom section another way.
Under Preferences / Labels / Label Definitions, create a label with the Pin to top option on.
Applying that label to a file or folder will then fix it at the top of the list. (Can be done via right-click context menu on files/folders, or from the Properties button's menu on the default toolbars.)
(If folders are set to appear before files, or vice versa, that still takes precedence, but the pinned files will be above the other files.)
Very cool... thx. Yet another section of DOpus that I was unaware of. I'm not surprised.
It almost works. But, not quite.
Pinned already existed in Labels section. So I created a Label Assignment as F:\__* (two underscores) with Label: Pinned and Use Wildcards enabled.
I then opened a new lister and went to F:. 3 folders appear at the top immediately, then one more jumps in shortly after. But, there are actually 9 of them. I click on Name at top of lister to sort by Name, and now all 9 appear. Change to Modified sort, all 9 appear. Closer requester, open again, and go to F:/ Back to only 4 at top.
It would be useful if you could set the Label to have an override sort order. So they appear in Name order (or other) regardless of the lister view.
Assign it via the context menu or toolbar, not Preferences. It needs to be assigned to the folders/files themselves and stored in NTFS ADS metadata rather than in Preferences.
(If it's a network drive, the NAS also needs to support ADS for it to work well. Synology does from my own testing, but others may not, and it may also depend on the NAS configuration.)
Yes it's a Synology NAS and I see that if I scroll the lister down and return to the top, it adds whatever files it encounters within the scroll. Which sort of suggests that the lister doesn't know what's beyond the current view? I'll investigate NTFS ADS on the NAS.
Thinking way back, I may have changed the context menu to show the Windows default one. Though I don't recall why I needed to do that. So, I don't see any option for that. The Prefs method does work though, if I can figure out this slight issue. Plus, I don't think it'd be as useful if I have to remember to turn it on when I want it.... Prefs method means I can forget how I did it. Limited space in my brain as I get older unfortunately.
It doesn't until it has seen the pinned file once and flagged the folder as having pinned items. I'm not sure if that happens if the label is applied via Preferences rather than on the file itself.
This was something that was improved in Opus 13. I think Opus 12 did behave as you describe
Unfortunately, still an issue in 13.
I don't think that it is the case that it doesn't know the contents of the whole lister until you scroll. Cuz, I'm playing with the new status bar option '{ft:sel,frame}', and if I click to look at the File Type Summary, I can click "All Files" and it gives summary for the whole lister. So, it clearly knows everything in the lister. Something else is amiss here I think.
BTW... if you right click the Status Bar you get the option "Edit Status Bar...". If you right click the Filter Bar you get the option "Configure the Filter Bar". Most places it's Configure. And I think the later is missing the "..."
It definitely works in 13 if you do it the way I said, as I use it myself.
(Labels created that way in Opus 12 will need to be scrolled into view once, but shouldn't be after that, provided Opus is able to set NFTS ADS metadata on the folder.)
Try on a local drive in case the NAS is complicating things.
At this time, I don't want to use ADS. I prefer the Prefs method.
The NAS shouldn't be having any effect since the lister knows all the contents. Why would scrolling be necessary, that doesn't make much sense to me.
Also I don't seem to have any context menu options for Pinning. I do see Convert Image, which I don't think is a Windows context option... so seems like I have the DOpus context menu. I'm not using the Explorer replacement mode. But I'm looking at the files in DOpus.
I just noticed something else about this... if I have a lister with a prefs setup to put certain folders pinned at the top, and then I scroll all the way to the bottom, then back to the top... I see all of the expected pinned items. If I then go into a subfolder and then come back out... the pinned items goes back to not showing them all.
I'd sort of felt that directory listings were cached in this kind of scenario. Maybe they aren't? Or if they are... shouldn't this be right when I return?
I did a test assigning the Pinned label to C:\Windows\WinSxS via Preferences, and it works fine here with Opus 13.10.1.
This is what I see if I open a new window and go to C:\Windows without scrolling at all:
This is what I'm using... Anything that begins with __ and ends with __ such as DOWNLOADS
Don't use filter label (they're much slower, and get evaluated in the background and only when things are in view to avoid performance issues).
Use a Folder label (which can include sub-folders) or Wildcard label (if you need wildcards/regex for some reason other than sub-folders).
Okay I understand the efficiency improvement and I've changed it to the below image.
But it still doesn't work right. The only way this pinning works is if I click the header to sort by Name and then click for sort by Modified. Then, if I refresh the lister it's wrong again.
Digging deeper... perhaps its a code conflict with this Folder Format setting:
That’s still a filter label. Delete it entirely, then click Add > Folder Label. (Or Add > Wildcard Label.)
Okay... here's more investigation that I think aims closer at where the issue is.
The F: folder has 484 files/folder of which 10 are matches. Easily determined by typing __ into the lister filer. The lister has room for 44 total files/folders.
In Modified sort, it shows only 5 of the matches... which as I look closer are the most recent of the 10. Those 5 also fall within the range of newer than the last file/folder in the current view of the lister (without scrolling).
In Name sort, it shows all 10. And all of them are newer (2021-2024) than the oldest file that shows in the lister (2018). The reason that Name sort works, is because alphabetically _ will be above all A-Z... which is actually why I use _ for these folder names, so I can find them easier. The goal now though is to not have to sort by Name to find them.
So I believe that you are applying the pinned filter after you determine what fits in the lister. And then pulling out any in the whole directory that fall within the range of the files that are in the lister view. and pinning those.
Instead, pinning should be based on the whole directory contents, regardless of what'll appear in the smaller lister view.
I can see how this code logic bug would be hard to spot in normal testing.
I don't buy this logic for a second. This is overly complicated to code and absolutely not in the logic in which a developer would address what has to be done here.
Anyway, I really think you need to stop trying to create your label via filtering. As said by Leo, this will be unnecessary slow and put unnecessary load on your computer resources.
Make a Folder label (it's easier), and I'm quite confident everything will be just fine.
Only because you're using the wrong type of label. Filter Labels are evaluated in the background and only when files become visible. They are not suited to pinning. That is why I told you not to use them for this.
Filter Labels are slow, and can potentially take several minutes per file with some filter definitions. They aren't suitable for pinning, where the list of pinned files has to be determined as soon as the directory is read, not later, else things will jump around. They also aren't needed for what you're doing, so there's no reason to use them at all.
Use a label applied directly to the folder (e.g. via right-clicking it and using the menus).
Or one applied to the folder path in Preferences (as either a Folder Label or Wildcard Label).
Basically, use anything other than a Filter Label.