Closed Bionus closed 1 year ago
Hello!
I'm just coming here to tell that it doesn't seem to support android/oxygen 11 ? It might be normal since it's relatively new, for now I'm just building it myself.
Thank you for creating the application. :)
What do you mean it doesn't support it? It should at least start on it. And how did you build it differently to avoid this issue?
If it's the "Built for an older version of Android" message on start-up it happens on pretty much all Android versions AFAIK, I had the same thing on my Android 10 phone.
Oh right, yes I had the exact same error, I was building it with qtcreator, in fact I wanted to build it later but I realized there was errors during cmake, do you mind to tell me how you're configuring with cmake?
The fact is that I can't even start it because of that error, it's strange. It feels more like crashing at the start though. I've never developed on android so I can't tell you what happens but I'll edit this post until I find more information
Weird. The build is not trivial since it's cross-build so I wouldn't really recommend it. And this message absolutely shouldn't stop the app from opening. Clicking OK should be more than enough and it should go on to the application. It might indeed be some kind of crash, which would be hard to investigate.
Here's the cmake command for Linux:
And here's the one for Windows:
_(QT_CMAKE is something like "C:/Qt/Qt5.12.3/5.12.3/android_armv7/lib/cmake", I couldn't make it work with DCMAKE_PREFIX_PATH
so I put all dirs manually)_
Then you just need to build targeting gui-qml_apk
:
cmake ^
--build . ^
--target gui-qml_apk ^
--config Release ^
-- -j 4
Hm, I'm still having issues generating the project somehow:
What do you recommend me to do? Seems like there's a conflict with /src/lib cmake configuration. Now that I notice it, it's the same errors I get with QtCreator. Do you have a social media so we can chat please when you're not busy ? It would take less time to solve issues (xutaxkamay@gmail.com)
There's a Gitter chat: https://gitter.im/imgbrd-grabber/Lobby
Although your issue seem to be from using a too recent Qt version. I heard they made changes to the way they manage Android in Qt with CMake in recent versions, and that might be the cause. I'm currently using 5.12 for building.
I'll try to build with 5.15 and see if I can reproduce the issue.
Screenshots updated with latest version (Material design, new search field, new results layout).
Regarding the changes made in response to #2201 specifically the 4th point ,when changing the source and then using the phones back button / gesture to return to the prior screen, it seems to not save which source it changed to. If instead, I use the arrow on the top left to return to the previous screen it will correctly change and remember its setting.
For example, starting with danbooru selected, I change it to gelbooru. I then gesture out and search. The log will show it pulling results from danbooru rather than gelbooru. If I go back into the source selection (same session) it will show gelbooru is selected as the source. Exiting the app and reloading will correct this screen to show danbooru as the source its pulling from.
If I instead do the same above but use the UI buttons, it will correctly change and remember when going from danbooru to gelbooru as a source.
--
Some somewhat related further suggestions:
For the action buttons on the top/bottom, could they be spaced out from each other horizontally more? Increasing the spacing by 50% between each would work for my phone's screen size. A UI scaling slider could work to accommodate other's as I'm unsure how it behaves in landscape or differing phone sizes in portrait.
Lastly, when an image is saved with the button, could there be some kind of visual feedback to show it has been saved? Maybe something similar to the desktop where the "save" button turns to "delete" once its on disk in your download directory?
Let me know if I need to clarify anything.
Heyo!
I want to recommend Tachiyomi as an app for potential inspiration.
It's a mobile app, open source manga reader that supports bulk downloading. It's gallery-based like e-hentai, but it looks like you're trying to make a imgbrd/gallery board hybrid, so it should help?
Regarding the changes made in response to #2201 specifically the 4th point ,when changing the source and then using the phones back button / gesture to return to the prior screen, it seems to not save which source it changed to. If instead, I use the arrow on the top left to return to the previous screen it will correctly change and remember its setting.
Indeed, seems to have been an oversight.
For the action buttons on the top/bottom, could they be spaced out from each other horizontally more? Increasing the spacing by 50% between each would work for my phone's screen size. A UI scaling slider could work to accommodate other's as I'm unsure how it behaves in landscape or differing phone sizes in portrait.
I'll consider it, but for now I like having the UI consistent. Maybe I'll add something like that when I add a more advanced theme customizer in the settings (instead of just primary / secondary colors).
Lastly, when an image is saved with the button, could there be some kind of visual feedback to show it has been saved? Maybe something similar to the desktop where the "save" button turns to "delete" once its on disk in your download directory?
Yes it's planned as it's currently not clear when the image is saving / saved. There's also no indicator when an image is already saved.
I want to recommend Tachiyomi as an app for potential inspiration.
I indeed like their UI, but I don't think the UX would fit given how Grabber is more linked to "searching", while Tachiyomi is more tracking individual mangas (or "galleries" in Grabber's terms) and download. π
Didn't know Grabber had an Android version in the works. Assuming its issues are dealt with, there will be little need to even consider some of the listed alternatives, especially when only one of them supports Sankaku (and AFAIK support for that has been broken too). Greatness.
There are two issues I found when using the app, though:
Thanks for taking the time to develop the Android app!
Hello, I want to report an error, so basically just like the tags error that has been posted in the issues couple months ago. In android version, particularly in rule34.xxx, the app does not distinguish the artist, copyright, and character tags, thus lumping them together with general tags. I'm currently using the grabber nightly version on my phone. Please fix this issue, thanks.
Does this support chan sankaku? Because I couldn't find it in source despite it being present on your preview pic
Is there any update on the monitoring feature for Android?
I'd love to auto-pull some searches and then set my tablet's screen saver to source that folder, which would yield me an auto-updating digital picture frame with all my pics of choice. :D
That's a good idea, but there's indeed no monitoring at the moment. The big issue would be running the app in the background. Monitoring as long as the app is open/on-startup would be easier but kinda miss the point.
How would that be an issue? I have all sorts of apps that do background tasks, granted depending on your OEM you have to do some system setting fixing to facilitate this, but far cry from impossible.
SD Maid does auto tasks on a schedule, I have a web site monitor on a Samsung phone as well watching some shops and stuff detecting changes like something being in stock again very reliably, independent push services that don't hook into Google's cloud can be made to self-execute check for possible notifications, ...
It's certainly possible. Only limitation is that on some Android versions you need a constant notification, but you can minimize it and have it get out of your way. Similar to Windows' systray icons.
Hello, I want to ask, why is danbooru stuck on eternal loading in the apk? Is there some settings that I need to change or what?
Hello, I want to ask, why is danbooru stuck on eternal loading in the apk? Is there some settings that I need to change or what?
I believe it's the same Cloudflare issue as the desktop one, so it's unrelated to the Android version.
On another note, given the Android version has been out for a while, I'll just close this issue since it can use individual issues instead, which is more efficient π
About
Grabber is going mobile! π And it needs testers!
Creating this ticket for general discussion about the Android version. This version is not officially supported yet, so please do not open other issues for it, please keep everything here.
Goal of this ticket:
Download
It can be downloaded here (
Grabber_nightly.apk
): nightly. Or for the direct download link: Grabber_nightly.apkFeatures
Existing
settings.json
import / exportShort term
Medium term
Long term
Very long term
Other applications
If you know any other application of which I can take inspiration from, please do tell in the comments!
Known issues
Screenshots
FAQ
It's ugly!
Feel free to suggest improvements to the UI/UX! Until then I'm
blatantly copyingtaking inspiration from existing applications.What about iOS?
I don't have an Apple license, so even if I manage to build it it's unlikely you'll be able to install it on an iPhone. So for now, I'm concentrating on the Android version. I've tried a little with Github actions but didn't go very far, you can see the workflow file here: ios.yml. Feel free to fix it, and if you manage to generate a releasable file, comment or make a PR!
What about the desktop version?
The desktop version will always be supported, and likely to remain the main platform for most users. And while working on the mobile version will take some time that I could invest on the desktop version instead, there's one huge big that was actually the driving factor for this decision.
Currently, the desktop version is divided into two projects: the GUI (sources), and the library (sources). The separation of concerns should be clear: the library does all the "logic" while the GUI only shows stuff. However, because Grabber is almost 10 years old (early 2011), lots of old code is actually mixed in the GUI. And while the library is easy to test, the GUI today is not tested at all. I could invest in some GUI testing framework and write a bunch of scenarios, but that's a huge pain. So currently, a lot of code is simply untested in Grabber, which explains most crashes and regressions.
However, with a new mobile UI, it would force the code out of the desktop GUI (since it can't be re-used if it's not in the library code). That means that the more things are implemented in the mobile version, the more things are getting actually proper testing, and the less likely the desktop version is to bug or crash.
What about translations? Can I help?
Currently, there is English and French translations as a proof of concept. Other translations can be made using Crowdin, however, given the interface is currently very new, I don't recommend starting working on those at the moment since there might be big interface changes causing strings to be made obsolete. I'd suggest waiting for the official release, unless you're motivated to have a translation in your language ASAP!
There's already many existing applications that do the same thing!
Yes, I even listed a bunch in this post. Although most of them are good for basic things, I believe that Grabber has some useful features that are not present in those applications.
When will it be ready?
When most "vital" features are implemented and the application is stable enough, I'll include it in the releases. As for when that is exactly, it'll be ready when it's ready.