Inconsistencies When Working with Attachments

[DrJJWMac]

I have a few observations about the approaches taken to work with Attachments.

* When I show a PDF Attachment in the right-most pane, the Gear menu option says Rename PDF. The first menu option however says Open Attachment With ...

When I context click on the reference in the center pane, the menu option says Rename Attachments...

Is this inconsistency (Rename PDF versus Rename Attachment(s)) supposed to mean that the former does NOT go through the rules while the latter does? Or is this just because the former IS a PDF while the latter is some generic Attachment? Why shouldn't they both be the same (Rename Attachment(s))? Alternatively, why should the first menu option not correspondingly say Open PDF With ...

* Continuing from above, in the case that I choose to Rename PDF (from the Gear menu option), I get a dialog box with the old name, the new name, and an option to change the proposed new name. In the case that I choose Rename Attachments... from the context menu, I get no confirmation dialog. It may be helpful in this second case to have a dialog list of what will be changed, e.g.

--> Renaming: bla.pdf to 2019 - Yancy.pdf, Apple.pdf to 2013 - Jobs.pdf, (and so on).

(Cancel) (OK)

* When I (accidentally) attach a Web archive to a reference, I might want to delete it. Unfortunately, the Attachments panel shows an error panel ...

Can't display this files contents.
Double-click here to open it in a compatible app, if available.

All menu options disappear. Specifically, I cannot select the gear icon to Detach or Remove to Trash. It would be significantly useful to keep that gear context menu specifically to be able to administer the attachment even when it cannot be opened in the app itself. (BTW, I suggest also that "Cannot display this file." or "Cannot display the contents of this file." is a better phrasing to use instead of the phrasing "Can't display this file's [sic] contents.").

* When I use the Rename Attachments... menu option, my preferred setting of Year - Author is not honored with either of the above approaches (I get a compilation of authors (year) - title). Is the Rename Attachments preference only for imports and not for general renames? If so, why? If not, then again we should have a confirmation dialog in the Rename Attachments... context menu to see that our preference is not being honored.

--
JJW

[Jon]

* When I show a PDF Attachment in the right-most pane, the Gear menu option says Rename PDF. The first menu option however says Open Attachment With ...

When I context click on the reference in the center pane, the menu option says Rename Attachments...

Is this inconsistency (Rename PDF versus Rename Attachment(s)) supposed to mean that the former does NOT go through the rules while the latter does? Or is this just because the former IS a PDF while the latter is some generic Attachment? Why shouldn't they both be the same (Rename Attachment(s))? Alternatively, why should the first menu option not correspondingly say Open PDF With ...

* Continuing from above, in the case that I choose to Rename PDF (from the Gear menu option), I get a dialog box with the old name, the new name, and an option to change the proposed new name. In the case that I choose Rename Attachments... from the context menu, I get no confirmation dialog. It may be helpful in this second case to have a dialog list of what will be changed, e.g.

--> Renaming: bla.pdf to 2019 - Yancy.pdf, Apple.pdf to 2013 - Jobs.pdf, (and so on).

(Cancel) (OK)

Both Attachment and PDF are correct, because with this action menu all attachments are PDFs. We use shared code to generate this particular menu item in different places in the app, so the generic term Attachment is used. Normalizing the terms shouldn't be hard.

* When I (accidentally) attach a Web archive to a reference, I might want to delete it. Unfortunately, the Attachments panel shows an error panel ...

Can't display this files contents.
Double-click here to open it in a compatible app, if available.

All menu options disappear. Specifically, I cannot select the gear icon to Detach or Remove to Trash. It would be significantly useful to keep that gear context menu specifically to be able to administer the attachment even when it cannot be opened in the app itself. (BTW, I suggest also that "Cannot display this file." or "Cannot display the contents of this file." is a better phrasing to use instead of the phrasing "Can't display this file's [sic] contents.").

In the Attachment Inspector, either select the attachment and press the Delete key, or right-click on it and select from the various options available (including Delete).

Why the sic? The file possesses its content.

* When I use the Rename Attachments... menu option, my preferred setting of Year - Author is not honored with either of the above approaches (I get a compilation of authors (year) - title). Is the Rename Attachments preference only for imports and not for general renames? If so, why? If not, then again we should have a confirmation dialog in the Rename Attachments... context menu to see that our preference is not being honored.

You should contact support@sonnysoftware.com with screen snaps of the (1) format you created for renaming attachments, and (2) the results you get.

Jon
Sonny Software

[DrJJWMac]

Having the gear icon still remain active and show actions to administer the attachment even when the attachment itself is non-readable would save the step of having to (remember how to) go to the Attachments Inspector to administer the attachment. This is a request to help streamline this particular part of workflow.

I think that “files” requires a possessive as “file’s” but can accept being wrong here.

The question is whether the settings in the global preferences is to be honored across all renaming operations or only across a specific set of operations (i.e. import but not Rename PDF) or only for a specific type of document (i.e. journals but not books). I’ll look further into what is happening before I mark this with an email support request.

—
JJW

[Jon]

#1. We'll have to disagree here. We removed the gear icon from the palette for esthetic reasons (palettes are designed to be small and simple, and the gear icon was clunky). Bookends accepts the Delete key as the most common way to delete list items throughout the application. It's no different here. And the right-click hierarchical menu is available with this list, as it is in ever other list in the application.

#2. Yes, it does require the possessive, and that's what Bookends uses. Your [sic] indicated you thought the possessive was incorrect. In any case, I agree your wording is better.

#3. Yes, the preference setting should be honored when you Rename PDF.

Jon
Sonny Software

[DrJJWMac]

Just so that we agree on what we disagree about.

The ability to manage an attachment through the menu options under the gear icon in this toolbar is useful.

attachment is a pdf

withpdf.png (93.26 KiB) Viewed 3437 times

I suggest that the ability to manage an attachment through the menu options under the gear icon should remain visible even when the attachment is not a PDF. Instead of seeing this ...

attachment is not a pdf

wopdf.png (25.19 KiB) Viewed 3437 times

I might hope instead to see this ...

attachment is not a pdf new

wopdfnew.png (34.54 KiB) Viewed 3437 times

--
JJW

[Jon]

No. Almost all options in that gear popup relate to attachments, they have no meaning for any other kind of document. That gear, and the accompanying Plus sign for adding to the PDF toolbar, are reserved for PDFs.

The Attachment Inspector can handle other types of attachments. You can do everything there with a generic file using a right-click hierarchical menu: open, rename, move to trash, etc.

And if you're dealing with image attachments, you can right-click directly on the image to detach, move to trash, zoom in, and zoom out.

Jon
Sonny Software

[DrJJWMac]

> Almost all options in that gear popup relate to attachments, they have no meaning for any other kind of document.

In the section to manage attachments, a Webarchive appears as an attachment that I can administer *as with any other kind of document*.

attachment list

attachment.png (104.7 KiB) Viewed 3433 times

Yet in the view of attachments, a Webarchive *that is attached as an attachment* is not recognized as an attachment. But ... wait ... it is. I can select it from the popup menu at the bottom. So, it is an "attached file". But ... I cannot administer it as an attachment once I select it.

So, I remain totally confused by the differences in how attached files are treated (right panel and information pane). I have no clue what is meant by "other kind of document" related to the generic term -- attachment. Either a document OF ANY KIND is attached to a reference or it is not. Either I can manage *any kind* of attachment document in the (properly named) Attachments view, or I can only manage ONE KIND of document in the (thereby wrongly named) Attachments view.

I think where this is heading is this ...

> ALL options in the gear popup relate ONLY TO PDF files. They have no meaning for any other kind of document.

In this case, as a feature request, I wish that the limitation on how we can administer attachments would be changed so that we can also fully administer attachments *of any type* (not just PDF files) while viewing in the Attachments section of the right panel.

Alternatively, since the right panel in its current approach is useless to do anything except with PDF files, rename the menu option to be PDFs* and remove entirely the ability to select any other kind of file attachments except PDF files from the popup menu at the bottom of the page.

--
JJW

[Jon]

The Attachments Inspector is a lightweight palette that let's you manipulate attachments. it's not a full fledged display pane, it's not intended to be.

"any other kind of attachment" means "any other kind of attachment". I.e., not a PDF.

Jon
Sonny Software

P.S. I suspect you won't be using the Attachments tab after the next update, and some (not all) this will be moot.

[DrJJWMac]

> P.S. I suspect you won't be using the Attachments tab after the next update, and some (not all) of this will be moot.

OK. I'll step back for the next update.

--
JJW