When using the new "Resource-specific notes file" option, resources with very long names messes up the Visual Filter menu:
So, the design flaw could be in how Logos names "resource-specific" files or it could be in that the visual filter menu should truncate names after so many characters. Or both?
I think it would be better to keep the long names in the document name, but truncate it in the menu. If you truncated the document name you could end up with difficulties with resources like this both ending up with the same name
I think it would be better to keep the long names in the document name, but truncate it in the menu.
+1... although I think you should be able to hover for the long name.
Mark - How has this been implemented? Does L6 auto generate the name? Can you change it?
It does that in the Documents menu, so the behaviour should be consistent.
I've made a case for this.
Can you make a case for the other as well? Resource specific note files must be RESOURCE specific, irregardless of the book's title.
This is a known issue that probably won't be fixed in this release. You can work around it by renaming the resource to have a unique title (e.g., add the author's name in parentheses).
This is a known issue that probably won't be fixed in this release.
Ok, but when? Do you have a plan? I don't want to spend hours migrating highlights to discover that 1) they get lost because of a bad migration or 2) I am stuck with cross contaminated note file.
When using the new "Resource-specific notes file" option, resources with very long names messes up the Visual Filter menu: I've made a case for this.
This should be fixed in 6.4 Beta 4.
For clarification: The "fix" was to set a max length for the visual filter menu, right? I don't see the full name on hover. Was that intended or no?
Also, I know this thread got sidetracked a bit... sorry. Did I ever create a new thread about ensuring "resource specific" note files are indeed "resource specific" (i.e. two resources with the same name don't get mixed up)? Was a case created? (I know Eli knows about the issue). I can create a new thread if needed.
At this point I don't plan to migrate to the new system until that issue is addressed, nor would I recommend the feature be shipped to stable channel either. It would not be good for users to either waste time migrating note documents nor for them to lose or have mixed up data.
Did I ever create a new thread about ensuring "resource specific" note files are indeed "resource specific" (i.e. two resources with the same name don't get mixed up)? Was a case created? (I know Eli knows about the issue). I can create a new thread if needed.
I don't recall if you created a new thread, but we're aware that "resource-specific notes files" are matched by title, not by resource ID.
It would not be good for users to either waste time migrating note documents
I'm not sure what you mean by "migrating". Is it anything more than renaming an existing notes document so that its title matches the resource?
nor for them to lose
I'm not aware of any way in which users can lose data with this approach. Is there something we should know?
or have mixed up data
IIRC, this feature is not on by default. The documentation could make it clear that the link is done by resource title and that to avoid having "mixed up data" you should use the resource renaming feature. (A lot of people already like to do that--often adding the author's name or series title--to avoid having ambiguously-named tabs and hyperlinks in the software.)
When using the new "Resource-specific notes file" option, resources with very long names messes up the Visual Filter menu: I've made a case for this. This should be fixed in 6.4 Beta 4.
Ok. Truncated but full title available on hover
If you are seeing "full title on hover" on windows, then there is a bug on Mac:
