integrate my appfilter data and icon repo ( conrad-heimbold/android-icon-pack-metadata-helper ) about frost HOT 23 OPEN

Hey, I have to say, I'm impressed. You've done an awesome job here. Having this repo is a gem amongst F-Droid themers and I hope many more will get motivated to start their own icon pack or just use this data for their existing one.

Now that I've said that, you're asking for help on it but I know nothing about scripting/programming ATM. If I make a pull request sometime with direct changes to the appfilter will you accept it?

Thank you and congrats!

from frost.

@ikocevski

For tracking future changes in activity names, it's better if we only collect the following data for every app on f-droid:

• what's the git/svn/hg/bzr repo name?
• where can I find the AndroidManifest.xml file inside the git/svn/hg/bzr repo (e.g. under app/src/main or only src/main or just under root (/)?)

I don't want to directly modify the appfilter.xml file anymore; the script should do everything just based on the metadata file from F-Droid.

The metadata files from F-Droid (see https://gitlab.com/fdroid/fdroiddata/tree/master/metadata ) seem to be quite out-of-date or un-ordered; that would be a better place to improve.

from frost.

Alright, so the GitLab repo is sort of a dependency for your script, I think you should add this question's answer to your readme file so that people don't get confused why you didn't accept their request. And now I'll have to make a GitLab account, well, OK.

from frost.

I definitely want to polish this script to avoid manual changes to the appfilter in the future, I will check it out tonight.

from frost.

@conrad-heimbold do you mind if I make the script a bit more readable with spacing and such?

from frost.

@dkanada
No, I don't mind

My script is really ugly and dirty, I know...

I actually already tried some bash prettifier, but it didn't work out somehow

from frost.

@dkanada

I started rewriting the whole script.
Now it should be much more readable.

It's not finished yet, but you can now probably understand how it should work and help me.

from frost.

Wow!
I've always wanted to have an appfilter collected from fdroid. Awesome! This would eliminate manual intervention on the appfilter. I would love to link it to my Ameixa repo, although probably needs a huge amount of work renaming icons.
The only thing that can throw me back is the possibility that with Android-O the appearance of the icons will be more homogeneous with the adaptive icons.

I am aware of the changes you are making about this script.

from frost.

@xphnx your icon pack uses the same code as paper and ICEcons, do you know where the project originally started? I have always wondered. Also, I have been contemplating for a while now how we can streamline modifications to icon packs for F-Droid since so many of them are using the same code and appfilter, do you have any opinion on such a project? It would be nice to separate the code from the icons and then create an organization to contain all the repos so that one update to the code or appfilter would automatically propagate to included icon packs. Why would the new Android O icons cause an issue with your icons? They look quite nice by the way.

from frost.

@dkanada When will you push an update? After closing this issue?

from frost.

I can add a new release today, this issue will have to wait since I will have to remove some icons from the pack and also add separate lists for "default" and "custom" icons. No clue how I will integrate those with the fdroid appfilter yet.

from frost.

Here is a useful link on launcher support, I might want to make some changes in the future.

from frost.

from frost.

from frost.

from frost.

I also thought using a submodule might work, just trying to think of a way to gracefully separate out all the sections. Adaptive seem like a great addition to Android, I think they are handled within the apps themselves though so we don't have to worry about them.

from frost.

We could move the /app directory into a separate repository and use it as a submodule. @conrad-heimbold your repo could also be a submodule, it will eventually need to contain drawable.xml and iconpack.xml as well, I use a script for that in /other that you can use as a reference. I think we will need to add a step in the build process to move all the custom icons and other values to the code submodule for this to work though.

from frost.

@xphnx @dkanada

What do you think, should I include all the original icons as well in my repo or should I make a separate repo (embedded as sub-module) for that?
The reason is: all these png icons would need a lot of size (100MB or more), and you probably usually only need the metadata, not the icons.

(Fun fact: these original icons would become a sub-sub-module then...).

from frost.

I would leave them in the repo for now, most people downloading your appfilter will also benefit from the icons, we can always remove them if it becomes too large.

from frost.

@conrad-heimbold I am thinking about using your appfilter, just some questions. Are you going to get it updated? how often it will be updated? The apps not includen in F-droid needs another lines... this could be stored in your side or imust be in the icon pack repos?

At this moment I will just copy and paste it manually untill I have an idea of managing submodules properly.

from frost.

@xphnx :

I am working on android-icon-pack-metadata-helper.

At the moment, I am still thinking about the right solution for lots of problems with android-icon-pack-metadata-helper. These solutions are still rudimentary and not online yet.

Problem number 1: Should I download the complete remote repo (only one request in github web api) or should I list remote repo content (at least 5 requests in github web api)? Downloading all the fdroid app sources will probably take around 1 TB of space. Github is unfortunately rate-limited with 60 requests / 15min; so downloading the complete src should even be faster.

Problem number 2: how to store the appfilter metadata?
I think the best solution would be to separate the appfilter metadata by app - every app gets its own appfilter metadata file. This way, you can "include" some apps or not.

Stay tuned ;)

from frost.

@conrad-heimbold @dkanada
Any updates on this?

from frost.

Since I'm running out of pull requests I'd like to know how this works.
I cloned conrad-heimbolds repo, initialized the subrepo and now I'm stuck, which file to feed to the script in bin/.
Would be nice if someone could point me into the right direction.

from frost.