Crowdsourced Icon Mappings

[moertel]

I believe that Artic/Pacific is doing this with their paid service for icon requests but I firmly believe that XML mappings should be a crowdsourced centralised effort. In particular, I feel like I'm slowly going insane trying to map all HSBC bank app variants to the HSBC icon. :) Annoying for users having to waste icon requests for it, annoying for icon pack devs trying to "catch them all".

It would also significantly lower the barrier for new icon pack devs to get started because they can focus on drawing icons rather than updating XMLs. What are others' thoughts on this? Would this help you? I would strictly keep the centralised mapping to official app icons and system apps (flashlight, gallery, etc.)

[Donnnno]

Would be super helpful indeed.
I can recommend checking out Arcticons appfilter for now, I think it's the largest openly available appfilter out there:
https://github.com/Arcticons-Team/Arcticons/blob/main/newicons/appfilter.xml
We've also mapped many generic apps to generic icons:
https://docs.arcticons.com/contribute/updating-existing-apps#connect-generic-apps-to-existing-icons

And check out our open-source request dashboard here:
https://arcticons.com/requests

[Donnnno]

Wow, that's super interesting!!

[Donnnno]

Anywayys.. The example here shows much potential. Having a master appfilter to check against is very usefull.

One thing that would be helpfull with this is a way to implement all the possible strings into your appfilter without copy and pasting thousands of lines. A script (or bot?) might be something that can handle that, but then again, I don't have any experience making such a thing.

[Kaiserdragon2]

While working on a script(Arcticons-Team/Arcticons#2860), I came across some unusual ComponentInfo strings
with multiple /.
Are these valid?

ComponentInfo{com.franco.kernel/a.spl/com.franco.kernel.activities.SplashActivity}
ComponentInfo{com.google.android.videos/com.google.android.youtube.videos.EntryPointGtv/com.google.android.videos.GoogleTvEntryPoint}
ComponentInfo{com.samsung.android.app.notes/com.samsung.android.app.notes.memolist.MemoListActivitycom.samsung.android.app.notes/com.samsung.android.app.notes.memolist.MemoListActivity}
ComponentInfo{com.adguard.android/com.adguard.android.ui.SplashActivity/com.adguard.android.ui.MainActivity}

[Kaiserdragon2]

I created a Repository for the Crowdsource script. It includes a yaml to use it as a Github Action and create a pr.
https://github.com/Arcticons-Team/Crowdsource_Appfilter

[Donnnno]

Absolutely insane work!

[x9136]

Hey!

I accidentally wandered in here, but I want to put in one's two cents.

Still trying to figure out why for the sake of a rare exception (when an icon changes due to a different activity), a more frequent case was ignored (when an icon remains the same when an activity is updated). An inordinate amount of work on adding app components could have been avoided if icon packs worked in the case when you simultaneously link icons through both package names and app components.

In a way, the topic of this discussion distances us from finally avoiding unnecessary work. But as for the same icons with different package names, the topic is useful.

By the way, if you develop the topic idea a little bit, then perhaps you will come to a centralized tool for collecting icon requests, where you can simply filter icon packs for which the visitor wants to view the icon requests. This is a way to multiply the number of sources from which new app components can come.

[Donnnno]

So, something like Icon pusher, basically?
https://iconpusher.com/

[x9136]

So, something like Icon pusher, basically? iconpusher.com

This is a suitable way to collect requests, but there is no point in using the service, because there is no significant benefit or convenience for icon pack devs to send people there for requests. I will keep silent about the examples of benefits this time, because we are moving away from the topic and it will be "in theory". But thanks for the discussion, I'll probably come back to it later somewhere.

[moertel]

The difficulty lies only in the global support of the approach.

If your optimism in this regard is high enough to fuel your motivation to make it happen: Go ahead!

I just don't see why you want to stop my efforts here or why they are even related. Open a new discussion, get folks engaged to architect a new format, reach out to launcher devs to make them adopt it.

The work I'm discussing here is probably a week of scripting and testing, needs no external servers or resources, and it will improve on the status quo which currently is... nothing, at all ;)

Edit: Maybe you missed it but there's already an implementation and configuration outline here: #225 (reply in thread)

[x9136]

I don't see how my desire to discuss the topic is related to the fact that you see it as an attempt to stop your efforts. Anyway, I'm gone.

[moertel]

Because I got very hung up on this sentence:

In a way, the topic of this discussion distances us from finally avoiding unnecessary work.

Which means we already agree that we're talking about two very different approaches. You're most welcome to lead an effort for an "icon pack format 2.0", but it needs a new issue/pr/discussion.

[walrus543]

@x9136 Actually we can have different icons for the same package name. For example, an Android app which can be used as a Dialer app and a Contact app. One activity for the dialer UI and one activity for the contact UI.

[x9136]

when an icon changes due to a different activity

we can have different icons for the same package name

It's the same thing, but in different words.

This case occurs much less often than when the same icon is associated with 2-100+ app components that have the same package names. For instance, "Discover", "Textra SMS", "WhatsApp", etc. Therefore, instead of adding thousands of extra lines, as we are doing now, we could write only package names. And for exceptions, we could specify only those app components that have a different icon. This way, most activity updates would work immediately, without the need to add new app components and update icon packs.

But it won't work that way now, because it wasn't taken into account initially. You can either specify only package names, but some icons will be incorrect, or specify all app components and constantly add new ones if you find them.

P.S. Just in case
App component: com.candybar.dev/com.candybar.dev.activities.MainActivity
Package name: com.candybar.dev
Activity: com.candybar.dev.activities.MainActivity

[kshitijdeota]

I have been using Candybar since initial days and there used to be launchers that accepted essentially just the package name to identify apps. Candybar still has support for it, appmap.xml for long ago deprecated "Atom launcher or Arrow Launcher". LG and HTC phone's launcher came up with their own "theme_resources.xml" requirement until all of them disappeared from the market over time while Chinese phone launchers moved on to their own 'eco system' so did Samsung.

Appfilter.xml turned out to be accepted by all custom launchers since then, even some launchers added support for Shaders.

What I very well remember from old days is that various launchers (based on appfilter.xml, eg. Nova Launcher / ADW) used to have a universal way for identifying and theming default apps for any phone like example below, that made things quite easy for theming essential apps.

    <item component=":BROWSER" drawable="browser" />
    <item component=":CALCULATOR" drawable="calculator" />
    <item component=":CALENDAR" drawable="google_calendar" /> 
    <item component=":CAMERA" drawable="camera" />
    <item component=":CLOCK" drawable="clock" />
    <item component=":CONTACTS" drawable="contacts" />
    <item component=":EMAIL" drawable="email" />
    <item component=":GALLERY" drawable="gallery" />
    <item component=":LAUNCHER_ACTION_APP_DRAWER" drawable="app_drawer" />
    <item component=":LAUNCHER_ACTION_APP_DRAWER_NIGHT" drawable="app_drawer" />
    <item component=":PHONE" drawable="dialer" />
    <item component=":SMS" drawable="messaging" />

I have no idea if today's launchers still support this method but I do include the above in all my icon packs. If still relevant, maybe this could be implemented for other apps too. I have a very basic knowledge and understanding of how these things technically work, others here can explain possibility/feasibility better.

[moertel]

Yeah, I guess we'd all prefer a more streamlined mapping process but this would require 1) someone to come up with a (new) standard and 2) all launchers to adopt it. With Nova having only one developer left, and launchers like One UI and ColorOS having no support channel to their devs, I wouldn't even know where to start with this. So relying on crowdsourced mappings of Arcticons, Lawnicons, Delta & others seems like a reasonable step forward to at least reduce the amount of work per-developer.