shimmerproject / elementary-xfce

Elementary icons forked from upstream, extended and maintained for Xfce
GNU General Public License v2.0
269 stars 37 forks source link

How is the list of icons that will be deleted created? #452

Closed Skif-off closed 2 weeks ago

Skif-off commented 1 month ago

I see in the changelog something like "Remove symlinks which are no longer needed", "Remove unused symlinks", "Remove unused icons" and so on. Who compiles the list of unused icons and how?

It is probably possible to automate the downloading of the source code of all packages available in the official repositories (for example, Ubuntu + Fedora), unpacking and searching for icons by name, and do this once every six months... but this sounds like my fantasy :))

P.S. Also interesting about the names of the new icons.

newhoa commented 1 month ago

There is no list kept anywhere, just the git record.

As for the process, I usually try to find a record of if an icon name was deprecated and when. Then check against git history from upstream elementary, Adwaita, Breeze, maybe a few others. Then try to do a search against the git codebases from a lot of apps and desktop environments that I have on my system (Qt, Gtk, Plasma, Gnome, Xfce, MATE, Cinnamon, etc).

You can download the releases and compare them (use Meld or FreeFileSync maybe?) or diff.

You can also maybe do something like this, comparing the release tags (use git fetch --tags to make sure you have the most recent tags, git tag --list for tag names/releases):

git diff --name-status v0.17 v0.18 | grep ^D | more

That would list all the files deleted between release 17 and 18. ^D is for deleted, ^A would be for Added, ^M for Modified, and ^R for Renamed.

You can check through the git history or the PRs (like this one or this one), I try to be pretty detailed in the logs and PRs.

Anyway, hope this helps!

Skif-off commented 1 month ago

@newhoa Thanks for your answer, I meant the criteria that are taken into account when deciding to clean.

upstream elementary, Adwaita, Breeze, maybe a few others ... Qt, Gtk, Plasma, Gnome, Xfce, MATE, Cinnamon, etc

Sounds like a tedious job, thank you for always finding the time for this :)

P.S. I love blue folders, I like elementary-xfce-darker and I don't like some modern trends, I also use Xubuntu LTS (usually the latest version), but I take some applications from third-party repositories or build them myself: I'm trying to sync the accumulated changes and I'm a little afraid of deleting the icons :)

newhoa commented 1 month ago

I meant the criteria that are taken into account when deciding to clean.

If it's in the FreeDesktop.org Icon Naming Specification, it can't be deleted. Gtk Stock Item names also won't be deleted as long as Gtk3 is around. Qt also has their names but this theme wasn't originally made for Qt so those names aren't always there, though if they are it would be nice to keep them.

Other than that, I guess it's just that I kind of notice when an icon name is old or out of place (I've been doing this a long time so it just is a kind of sense). Then just check it against the stuff above and the codebases.

Unfortunately, elementary-xfce-darker was deprecated a while back, it just defaults to normal elementary-xfce-dark now. It was causing a lot of inconsistencies in toolbar icons, and with the use of -symbolic icons in the last few Xfce releases, especially in the panel and many toolbars, it didn't seem necessary and was harder to keep maintaining.

I think instead of trying to replicate all the additions and deletions over time, it might be easier for you to use the current theme and then just grab the elementary-xfce/places and elementary-xfce-darker folders from older releases and just copy them to the latest releases installed folders.

Skif-off commented 1 month ago

Thanks for the details. Before this, for unknown reasons, viewing changes sometimes caused slight discomfort :))

it might be easier for you to use the current theme and then just grab the elementary-xfce/places and elementary-xfce-darker folders from older releases

Yes, this is a good method, it's fast and simple, but unfortunately this is not very suitable for my case: I don't update some icons, I replace some of them, also sometimes I have to add new sizes. (I'm not sure, but I think I only deleted gufw.svg myself because this application has a nicer icon.)

Skif-off commented 3 weeks ago

@newhoa if you have free time, can you help with a related question? I'm not sure I understand correctly how this all works :)

For example, we have an application that uses the icon apps/x/preferences-desktop.svg. After moving an icon to categories, will preferences-desktop.svg no longer be available to the application? Or does the exact location of the icon inside the theme folder not matter? I.e. is the directory hierarchy inside the icon theme folder just for order?

newhoa commented 3 weeks ago

FreeDesktop.org does specify which icons should be in which directories. But, I think it's pretty rare if any app/toolkit that limits only looking for a specific icon in a specific directory.

As far as I know, Gtk and Qt will both look for an icon name in any directory that is in the theme's index.theme file. But it's really up to the app how they use that information or if they do their own custom lookup.

Xfce's exo (when you right click a .desktop file and "Edit Launcher" and try to choose an icon) has its own custom lookup that looks like it looks for keywords in all icon directories in the selected theme and hicolor. When you select an icon, it writes the filename (without extension) to the .desktop file. It doesn't matter where that filename is in the theme, as long as the directory the filename is in is listed in the index.theme. If you change the icon theme, it will update the icon if the same name is found in the new theme.

Some apps may choose to add the icon as an absolute path. Then, the icon will not change if you change themes, and if you move the file, the launcher will have no file. menulibre allows you to choose an icon (like Xfce's exo) or choose a file from disk at a specific/absolute location. Snaps also seem to generally use absolute paths for icons since they bundle their icons with their snap packages.

Icons in apps (buttons, toolbars, etc), if they use Gtk and Qt, should be relative by default and be found and updated if the icon name is found anywhere in the selected theme as long as it's in a location listed in the theme's index.theme. Unless the developer decides they want absolute/hardcoded icons, which doesn't happen too often.

Hope this helps and made some sense!

Skif-off commented 2 weeks ago

@newhoa

Thanks for your answer! Yesterday I tried to understand this (GTK2/GTK3 Reference Manual, code examples and so on) and came to similar assumptions. Sometimes not being a programmer is a little inconvenient :)))

P.S. What about this issue? It seems that I have reached the necessary level of understanding, but I don’t know if these questions are of interest to anyone else? I think the right thing to do is close it.