Good day @PulkoMandy,
Thanks for the explanation here. It’s clear now. I wrote that down so I won’t forget! 
You have already told me on IRC that I should use addattr for the folders so since then I do that, the test was just a test to see if there was any difference there using both methods, and because my experience with Icon-O-Matic and icons on Haiku has been somewhat… mmmm… different?:
1- I first used Icon-O-Matic and save the file as NameOfIcon
2- Then I thought that Icon-O-Matic’s default filetype was HVIF, so I started saving icons as NameOfIcon.hvif
3- Then I decided to create an icon for LibreOffice, so I did, and I saved it as LibreOffice.hvif, directly from Icon-O-Matic, no export
4- When uploading to Haikuports, I think was @humdinger who told me that Icon-O-Matic files are IOM, to save them as HVIF I should export them
5- Then I started to name Icon-O-Matic files as NameOfIcon.iom. HVIF exports as NameOfIcon.hvif. RDEF exports as NameOfIcon.rdef.
6- And rename all icons done before, from NameOfIcon.hvif to NameOfIcon.iom
I certainly won’t forget about all these, though I think Haiku needs better documentation, or at least easier and inviting for newbies like myself 
Thanks and regards,
RR
2 Likes
To be fair, the IOM page of the Userguide does explain the different Save/Export options.
2 Likes
Good day @humdinger,
That’s why the switch. If not, I would get to Haiku now and then and forget about that stuff again and again… and again… and again… aaaaand agaaaaaaain…
Regards,
RR
Good day,
Finally, little by little… The already made icons are available as IOM (Icon-O-Matic) files for anyone to play around with (more will be added as soon as I make them and if I don’t break anything with Git):
Also doing some cleaning and arranging everything… hopefully something good will come out of this.
Regards,
RR
4 Likes
@leavengood - I realize that this is an old thread and comment, and I don’t want to start another war on the package management, but I do wish there was some work around to change a packaged app’s icon.
This is the only thing I could think of:
What I was able to do was to copy the executable out to a non-packaged folder and change the icon of the non-packaged executable using file-types and save it, and then launch from there, (also have to “identify” the copied (non-packaged) executable if I want it to work nicely when launching from my HiQDock).
1 Like
Sorry I missed this back in February. I have actually been thinking about Haiku app icons lately and I agree it would be nice to be able to change icons for applications without major hacks. Even without package management it is painful to have to change the icon by changing the resources in the app or changing the app icon within the icon attribute in BFS, because it would have to be re-done whenever an app is updated (I’ve also experienced this pain when changing the icon on applications in macOS.)
The easiest solution I can think of is just some sort of indirection. Deskbar asks the roster for icons (and probably similar for other apps like HiQDock), which I assume just loads the application files to get the icon. But if roster is (generally) the “source of truth” for app icons there could be some way to override the icon. In the end this would likely mean some files or settings somewhere under ~/config/settings but it could be exposed more nicely in the GUI somewhere, like Tracker or the FileTypes preferences.
Would it be possible for apps to have two icons in the resources, one for clear schemes and another for dark schemes? In this case in appearances app you could have a checkbox “Use dark icons” that would tell app server to use the second icon and so change them all at once. It would help to keep consistency and would avoid to have numerous incomplete set of icons.
2 Likes
It is possible for apps to include light and dark variants of their icons in their resources. The Tracker GetIcon methods and and AppFileInfo etc. would have to be reworked to support a dark variant.
1 Like
It seems to me you could draw a white outline around the icons in dark mode and it would solve most of the issue.
2 Likes
Oh, those darkened icons are ugly.
1 Like
Personally I think my icon theme back in ZETA was pretty slick 
5 Likes
Please don’t change the basic way icons work. You can use this for any file. Do you want to add a config option for every path.? that is just likr an overlayfs in a file then.
Honestly copying icons is not that hard. The gui of “file info” could provide an easier way here perhaps but adding stuff similar to the .desktop indirection mess for such a niche usecase seems incredibly overkill.
Especially as you can just (with bfs!) querry for each file that has an icon or mime signature and replace it programmaticaly with software to change the icon “Theme” if you want that
I think the /only/ change required is that icons that use a dark element to convey information, like the network icon, need a white outline around that.
Other than that the Icons on Haiku already work perfectly on dark mode Haiku, especially since they are already bright and colorfull to begin with.
But I don’t understand how I can change the icon for a read-only package executable (without copying that executable over to the non-packaged folder)? even programmatically (if the file with resource is read-only)?
Leavengood specified without package management above, which is what I responded to.
Even with package management it would be easier to have a proper overlay for specific extended attributes.
1 Like
I was trying to simplify things a bit and make an argument that app icons are difficult to manage even without package management, but of course package management makes it much worse and even more complicated.
The reality is we have packages. It seems much more complicated to propose a solution that reaches into packages to rewrite them and their app contents just to change app icons. This would also have to be redone every time a package is updated. Whereas the icon “redirection” or overlay solution would persist across package updates.
I can agree with that, but I suppose we need to define what a “proper overlay” is. The main reason I can get behind this a bit is that it could also solve the bug with Tracker folder properties not persisting in the read only folders exposed by the package system. Otherwise I think it falls into the usual “someday” perfect solution that we tend to go for in Haiku, and that maybe sometimes we should consider whether perfect is the enemy of the good. Possibly a first step on this would be to implement an app icon specific version and then iterate.
1 Like
One solution would be to make sure that files with different xattrs in packages can overlay cleanly.
That way we can add a programatically generated packaged for your icons which activates last and overwrites the xattrs in question, but without the overhead of a full rw xattrs overlay.
In any case, yes sometimes perfect can be the enemy, but making this work with more indirection would massively take away from the ease of understanding and simplicitly the system has now here, It is so much easier to use then the .desktop files on linux and I think we should definetely stick with it.
… Although we should probably still define a proper ELF section for app ressources : )
The idea of packages overwriting attributes sounds nice, though I don’t know the current technical limitations which make that not work at the moment (plus maybe there are performance implications?)
But the usability would be awesome, people would just install an icon package to change icons. And undoing an icon change would be a trivial package uninstall. This would just need a tool to help build those packages but that is just on the icon packager side. But that tool would be nice to allow users to make their own icon packs too.
So you are definitely convincing me to find a better way which fits in with what Haiku already has. If and when I start looking at this I will start with this idea and see what are the current issues with attribute overlay from multiple packages.
Also I agree the .desktop file thing is not nice and typical of the bad hacks needed on Linux.
5 Likes
I opened a ticket about having a way to fetch icons from a “theme” years ago:
#10887 (Public API to get a “default icon” (for example for standard toolbar icons)) – Haiku
While not related to application icons necessarily, this would mean that all toolbar and “action” icons, of which we have not a few, could all be standardized in one place. Changing app icons would be another problem entirely, but this would at least reduce the duplication and allow for changing of action icons.
1 Like
See my comment on that ticket. It’s quite verbose but means we could use color fonts to hold the glyphs so we wouldn’t need to reinvent the entire wheel.
Edit:
This relates to another proposal I gave and circled back to in another thread about a Haiku-specific font format.
