deckerst
"Restore Element from Trash" overlays Video Seekbar/Playbutton
Describe the bug It's a visual bug. When Deleting a Element, no matter whether image or videos, there is a 3sec overlay for restoring the element. Tis overlays exactly the Playbutton and Seekbar of Videos.
Expected behavior The restore-Message / Overlay shall be displayed a bit higher to not overlap the Seekbar of Videos.
Additional context This is a slightly annoying bug when, after a longer vacation, one wants to go through all captured elements and delete one by one. Because it always blocks me for 3 seconds from seeing whether the next auto-selected element is a video (which obviously I want to shortly play before deciding whether I want to delete it or not).
I understand the issue and could address it, but in the meantime you could enable video auto play so that you don't have to wait to press play. Also, you can dismiss the message by swiping it.
I understand the issue and could address it, but in the meantime you could enable video auto play so that you don't have to wait to press play. Also, you can dismiss the message by swiping it.
Thanks, you are right - I always forget about swiping it. But I also found the setting now to completely deactivate it - yes it changes the functionality, but I only need the restore-function rather rarely - so I'll just keep the overlay message disabled, as I anyhow know I can manually restore from the trash :)
Ah and one more question @deckerst - is it "normal" that even on flagship devices (I own the Samsung S23) the delete from the normal gallery always takes a short while, maybe 1 sec? It is very weird if you wanna quickly delete some elements, there's always a short "break". I can only imagine that it is due to some internal Android API being used which is not the fastest!? I mean, flagging a file for deletion or moving it to some other folder should only take microseconds, shouldn't it!?
Thanks!
due to some internal Android API being used which is not the fastest!? I mean, flagging a file for deletion or moving it to some other folder should only take microseconds, shouldn't it!?
Correct. As a gallery app Aves doesn't have access to the straightforward API for file handling. I need to jump through hoops and use indirect APIs for media handling through "content providers". Anyway, I hope to find a faster way to do this, but for now I'm stuck with these sluggish file operations.
due to some internal Android API being used which is not the fastest!? I mean, flagging a file for deletion or moving it to some other folder should only take microseconds, shouldn't it!?
Correct. As a gallery app Aves doesn't have access to the straightforward API for file handling. I need to jump through hoops and use indirect APIs for media handling through "content providers". Anyway, I hope to find a faster way to do this, but for now I'm stuck with these sluggish file operations.
Yeah, thought so, because I kinda remembered that Android reworked a lot of its internals w.r.t. file handling, access rights in the past etc...
But it's incredible that Android, as it seems, still doesn't provide a good (fast) way of handling these things. Or would it be, in general, possible if you rework the app to ask general filepermissions at a different layer (globally) somehow?! Because IIRC I've seen apps that handle fileaccess (moving / deleting etc) with great speed. Probably all file explorer apps like Solid, MiX etc... Can't imagine those being so slow file by file... but maybe this cannot be implemented in a Gallery app, not sure!?
Beyond APIs and technical limitations, there are also store policies. An important Play Store policy (with which I personally agree) is that gallery apps should only access media files and shouldn't request the permission to all files. The permission to all files is only permitted for generic file managers. That's why Solid, MiX, etc. can directly access any files.
Beyond APIs and technical limitations, there are also store policies. An important Play Store policy (with which I personally agree) is that gallery apps should only access media files and shouldn't request the permission to all files. The permission to all files is only permitted for generic file managers. That's why Solid, MiX, etc. can directly access any files.
Interesting, understood, thanks! The original gallery app of my samsung though can handle deletion way faster. Wondering how that can happen, but maybe it's due to the APK being installed as system app and not over playstore and therefore the possibility to directly incorporate direct access to all files right from the beginning?
Yes, OEM gallery apps are exempt from this limitation. It's not a fair playing field for 3rd party developers! ^^
Idea / Question: Wouldn't it be possible to have a separate build of the APK and just release it on GitHub and/or F-Droid with the ability to request permission to all files and therefore be able to handle deletions etc way faster?! I think this would be a really great addition and I'd be looking forward to install it directly from GitHub instead of over PlayStore...
As I said above, I agree with the policy because gallery apps have no business accessing other files. Also, I want to avoid different builds with different behaviours. The current flavours of Aves only differ in insignificant ways and I'm happy with that.
Sorry, must have missed that. I do fully understand your reasons, even though, as a developer myself, I also tried to balance the tightrope walk to also maximize "value" / usability for the end-user and not purely focus on my own intent / perspective. But hey, I don't mean to critizise you in any way, please don't get me wrong here - just wanted to point out that this slowness could indeed be a bit of a stumbling block for some users, but I totally understand this is because of Android policy.
Thanks for all considerations and your fast responses. Wish you a nice day!
Hi @deckerst
I just came back from vacation, took way too many pictures / videos and now gonna view/organize/delete some of them. A bit frustrated again about the deletion-delay when dealing with dozens, let alone hundreds of files.
I understand that the Android Framework is the reason for these short delays upon deletion. So one idea I just came up with: Would it be possible to at least do the deletion "non-blocking"? I.e. delete in the background while already showing the next image/video in the usual manner?
I think this way this annoyance posed by the slow Android framework could be circumvented just a bit.
Thank you very much for your consideration!