fix: import file only once to document

[letsfindaway]

This PR fixes #1156 where the first page of a PDF document was repeated at the end when importing the PDF by dropping it to the board.

• when importing a file to the board, the file was offered to all import adapters
• if multiple import adapters support the same file extension, then the file was imported multiple times
• this was especially true for pdf documents, where in some environments also the image adapter supported rendering a pdf document (preview image of first page)
• this commit leaves the loop iterating over the adapters once one of them has successfully imported the file

@sebojolais: could you test this PR whether it fixes the problem for you?

[sebojolais]

Hi,
Thank you for your PR.
It fixes the issue #1156 I observed in my side.
tested with Qt 5.15 and 6.7

[sebojolais]

One question about this PR:

It make sense to let only one adapter to import the document.
But how we can be sure is the best adapter for this format ?

In other words, with a example:
Currently, the adapters list is :

The PR fixes the #1156 issue because the PDF adapter is before the Image adapter in the list.
If it was not the case, the PR should not fixes the #1156 issue.
But it will be always the case because the order of the adapters is defined in the constructor:

OpenBoard/src/core/UBDocumentManager.cpp

Lines 94 to 103 in 3b38085

	UBImportDocument* documentImport = new UBImportDocument(this);
	mImportAdaptors.append(documentImport);
	UBImportDocumentSetAdaptor *documentSetImport = new UBImportDocumentSetAdaptor(this);
	mImportAdaptors.append(documentSetImport);
	UBImportPDF* pdfImport = new UBImportPDF(this);
	mImportAdaptors.append(pdfImport);
	UBImportImage* imageImport = new UBImportImage(this);
	mImportAdaptors.append(imageImport);
	UBImportCFF* cffImport = new UBImportCFF(this);
	mImportAdaptors.append(cffImport);

So I try to answer to my question: But how we can be sure is the best adapter for this format ?
We can not be sure, but the double adapters import happens only for PDF in a specific environment. And in this case the good PDF adapter will be always used first.

[letsfindaway]

So I try to answer to my question: But how we can be sure is the best adapter for this format ?
We can not be sure, but the double adapters import happens only for PDF in a specific environment. And in this case the good PDF adapter will be always used first.

Yes, exactly. This is a very good question, and I also asked it to myself. To make the answer a little bit more generic:

To find the right adapter when multiple adapters would offer to handle a file format we can have two approaches:

• Some kind of voting, where each adapter expresses a "suitability" and we choose the highest.
• Or a fixed sequence, which orders the preferred adapter first.

The current code guarantees a fixed order, so the second approach works well. (Side note: a registration approach where each adapter offers its capabilities to the document manager in an unspecified order would require the first approach.) If we care to order more specific adapters before more generic ones, then this solves the problem. The current sequence already fulfills this condition.

And as you said, PDF is currently the only one where this occurs. And the image adapter is the only one where the list of supported file formats can vary. All others return a fixed string list.

[letsfindaway]

Shall I rebase this branch, too? I must admit, I do not fully understand what the merging of dev actually did and hope to get a cleaner history after rebasing.

[kaamui]

yes, please

[letsfindaway]

yes, please

done