integrate my appfilter data and icon repo ( conrad-heimbold/android-icon-pack-metadata-helper )

[conrad-heimbold]

Hi @dkanada and @ikocevski

I made a script to parse all the data from https://gitlab.com/fdroid/fdroiddata/tree/master/metadata and download all the necessary data for as much apps on fdroid as possible.

My repo contains the PACKAGE_NAME and the MAIN_ACTIVITY_NAME (in the appfilter file under /xml) and ICON_FILE for 1711 apps on F-Droid.

Could you help me improve the script?

Thanks in advance!

[ghost]

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!

[conrad-heimbold]

@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.

[ghost]

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.

[dkanada]

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

[dkanada]

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

[conrad-heimbold]

@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

[conrad-heimbold]

@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.

[ghost]

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.

[dkanada]

@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.

[ghost]

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

[dkanada]

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.

[dkanada]

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

[ghost]

do you know where the project originally started? No idea, i suppose the link you provide above is the most probable

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. I fully agree with you. At the moment I cannot figure how to implement this, really it would be an amazing feature and could prevent us from doing the same job in several repos specially if it is a sort of automated proccess. I would love to help in whatever was in my hand, but I am afraid I do not have the necessary knowledge to contribute so much with coding. ;(

Why would the new Android O icons cause an issue with your icons? Dont know how adaptative icons will affect to our icon packs, but every app could have 4 different shappes (round, squircular, rounded square or teardrop) Maybe we have to introduce some changes to de code... I guess we should wait and see what happens.

El 18 de agosto de 2017 20:15:11 CEST, dkanada notifications@github.com escribió:

link for reference

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/dkanada/ICEcons/issues/67#issuecomment-323424495

[ghost]

What about working with a submodule and using a script to build the appfilter to use?. Note we need to use the appfilter1 from fdroid (by conrad-heimbold) and some other lines for the default apps and eventually other floss apps not hosted in fdroid

https://github.com/blog/2104-working-with-submodules

[ghost]

More info about adaptive icons https://medium.com/google-developers/implementing-adaptive-icons-1e4d1795470e

https://developer.android.com/preview/features/adaptive-icons.html

[dkanada]

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.

[dkanada]

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.

[conrad-heimbold]

@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...).

[dkanada]

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.

[ghost]

@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.

[conrad-heimbold]

@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 ;)

[ghost]

@conrad-heimbold @dkanada Any updates on this?

[baitmooth]

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.