I’m sorry but could you please read one more time this bug report? I did update description a bit.
Please keep in mind that I’m the author of the patch and I found a bug in NextCloud integration while I was creating this patch.
There is nothing I can fix on my own it’s a problem with NextCloud integration.
I explicitly mentioned that there’s no problem if you pick up mail as a destination for sharing.
Seems to only work with email? Bluetooth, single file, random android app, doesn’t work at all, dropbox, single file again… It’s a feature request from what I can tell
well thank you for the information. I didn’t check Bluetooth. I’ll add this to the bug report.
I’ll repeat one more time. It’s not a feature request. I’m not doing anything that’s not handled by the official documentation. If you can point me to official information that says that I can’t share multiple files using Bluetooth or Nextcloud through Sharing API then I’ll consider this as a feature request. Otherwise if mail works fine, then it means BT and Nextcloud should be fixed to be in line with mail or shouldn’t be shown in the sharing api window when ShareAction.resources is populated with more than one element.
Can you point me where it says it will support a list? If share.action supports lists but only email accepts them (which is why it supports lists in the first place), you patching adding lists to recipients that do not support them (yet maybe? Maybe a feature???) is not a bug, feature request
Of course, here:
you can read:
resources : list
A list of resources to be shared.
No, where did you came up this from? I’m using official api the way it was designed. I have no control over what’s happening with it later. It’s simple, just file up an array and call trigger() the rest is handled by the OS.
Oh and btw I’m not sure if single bt transfer from a list was caused by list or windows receiving, so probably bad to include it in this bug report, might work on linux, might work with different list implementation (could work from file manager? No idea), throwing into a bug report with 0 info is just bad manners
no it won’t. As I stated above and explained how this works in the system.
Yes, lists are supported and it was passed, emails can process them and handle multiple attachments other recipients won’t and will process one item per call, ignoring your list, you have to feed them one by one, or request a feature for a recipient to handle more than one item (you could have a share plugin for imgur or youtube and they won’t accept 20gb of your videos folder as a list, you can’t force apis to do extra functionality just because you sent more items, but shareapi supports lists, bug)
no no no, there’s no mention in the docs that I should bypass api functionality. If that’s not allowed then ShareAction.resources should accept only single element. Instead it accepts many so it’s up to the receiver to do it’s job and in this case NextCloud and Bluetooth are not doing their job while mail is doing. So it’s a bug, a left over. It would be different if I’d ask to change the shareaction.resources to accept multiple files but right now it already does this and it’s not on my side of the app to handle the situation you’re describing.
So in your case - uploading GB of data, a share plugin should handle the workload and not the sender and this is the case this time. The receiver/share plugin is not doing it’s job properly as the system was designed.
What bypass? Sharing api allows sending lists - does what it says in the docs.
Not all sharing api recipients handle multiple files - share 5 videos to a tv recipient, is it going to show 5 screens at once? It will ignore 4 and play 1 of them, BUG
of course it’s a bug, It should queue all of them and play one after another. But it’s a task for receiver not for the sender. As the sender has no idea who will receive what he is sending.
If your recipient is ham radio do you invent a new format that allows queuing?
I’ll repeat it one more time. When sending data using ShareAction.resources I have no idea who will receive the list and I expect the system will handle this properly and won’t allow the user to pick up destination that doesn’t accept multiple items. That’s simple and clear. Then Bluetooth and NextCloud should either:
Right now nothing of this happen, so it’s a bug. I propose how it should be fixed cause there’s no problem from handling it that way as:
Thank you, it’s a feature, nowhere in the OS can you share multiple files to them, which is a conscious decision, the fact that sharing api can handle lists (for email only it seems?) does not mean that all recipients hndle them which is your assumption, you just shove a list and expect every possible receiving api to just handle it, invent a playlist or a queue on the fly as we go
@throwaway69, the API documentation clearly states that a “list of resources” (URLs and strings) can be provided. AFAIR this never worked for Bluetooth, hence @lolek is also right, that is very likely not a regression, but a longstanding issue. Also note, that the example section in Jolla’s documentation explicitly discusses transmitting multiple “resources”. Plus the caller cannot know which target / sink the user chooses, so this must work generically for all supported sinks, not just “email”.
The workaround is easy, the code using this API call can perform a call for each “resource” to be transmitted. But according to the documentation that should not be necessary.
@lolek, please mind that bulk transfers (if they work) generally have a drawback: If something fails during the bulk transfer (not at its start), it is not easy to design a UI for potentially very long lists of “resources”, which properly informs the user what happened, i.e., what is already transferred, what exactly failed why, and which “resources” were not transmitted (or it may simply carry on and continue to transfer as many “resources” as possible). Practically, you may be better off handling this with your own code. Nevertheless, I concur that the API does seem to not work as described.
@throwaway69 actually when I though more about this workaround, in the case of Bluetooth and Nextcloud the use of it is unacceptable cause it would only potentially cause user frustration and would make sharing with mail totally unusable.
It’s because right now, when you want to share something over BT, additional dialog popups which ask for a target. The same is also valid for NextCloud where you have to specify destination.
Now imagine, user select ten files then the user would need, select ten times destination for the share and in case of NextCloud or BT he would need to again select ten times of destination in case of BT while in case of NextCloud we could assume that he will just confirm previous destination.
But then mail destination would suffer and be probably impossible to handle as right when you select mail as a target, a mail client is opened, means that it would require opening ten new mail windows. Is that even possible? And that’s unavoidable with this solution because as it has been explained by me, and by @olf the sender has no idea what will be the target. So there’s no way to know in advance what functionalities will be supported by the target. It’s up to the target/share plugin to properly handle this.
Yes this is how it should be handled. It should proceed with the items from the list one by one and in case of a single failure it should:
There may be some other possible solution, either way is fine as long as user will be able to find out why each item failed.
FYI: there’s this comment in GalleryGridPage.qml:
// TODO: Not sure how we should deal with the error cases e.g. file couldn’t be deleted and
// we don’t even have a design for that yet.
which is related to your concern. Tbh right now the design is already there. Just throw info to the notification and it will show all failures the same way as it’s done right now which is the even screen (I hope it’s the correct name for that part of the system). Probably it is some really old comment which has been forgotten.
I would have thought it was due to this uninitialized boolean (and perhaps it may still be):
But my SeaPrint sharing plugin correctly does not show up when multiple files are shared.
So it sure looks like the plugins register with multi-file capability and doesn’t deliver on it.
and I see no reason why these two plugins can’t provide this 