AROS Icon Alias

miker1264 · 1060

miker1264

  • Legendary Member
  • *****
    • Posts: 1827
    • Karma: +84/-6
on: February 17, 2021, 01:15:04 AM
I've been experimenting with a concept that Kalamatee had suggested a couple of weeks ago to see if it was possible.

Icon Alias uses an IconList to display alternate icons. I'll explain.

But first I have to answer a question...

... Icon Alias and Icon Library do a Magic Trick. ...
Out of interest, basically you patch iconlibrary functions to point them at your functions when aliasing is active (and call default original functions when not) and then instead of loading the actual diskobject, you replace that with the 'aliased' icon ?

In Icon Library a few things happen. An external program or Icon Prefs sends a message to Icon Library that ALIAS is turned on. Icon Library sets BOOL ALIAS = TRUE. The Prefs Program loads a linked list "IconList" in the Library Base.

When Icon Library processes icons in a given drawer it does it one at a time. In the Library code it is simply CONST_STRPTR name. So if(ALIAS == TRUE) we compare name to the IconList. If we find a match we substitute the alternate icon name which is the full path to the icon. Icon Library then processes the new icon and copies the attributes from the original icon such as StackSize, IconType, Default Tool, Tooltypes, etc. It behaves like a real icon because it is a real icon. But if we use Icon Prefs to turn Icon Alias off and restart AROS then the list is ignored and icons stored on disk load and display normally.

The only issues with using Icon Alias is when copying, moving, deleting or renaming alternate icons because then they are no longer on the IconList and their "invisibility cloak" disappears and the original icon displays instead. Icon Information however displays the icon correctly since only the images have changed.

One possible way to address the modification issues just mentioned is to have an external program, maybe the same small app in c: that actually loads the list, sets up a messageport to listen for changes for icons. Then it adjusts the IconList also.

This is experimental but substituting names and copying icon attributes works beautifully in Icon Library thus far.  :)
« Last Edit: February 17, 2021, 01:18:24 AM by miker1264 »



Amiwell

  • Legendary Member
  • *****
    • Posts: 2616
    • Karma: +35/-4
  • Peace
Reply #1 on: February 17, 2021, 08:49:28 AM
good miker :)



magorium

  • Legendary Member
  • *****
    • Posts: 632
    • Karma: +62/-0
  • Convicted non contributor
Reply #2 on: February 17, 2021, 01:03:21 PM
Thank you for taking this to another thread miker

Quote
In Icon Library a few things happen. An external program or Icon Prefs sends a message to Icon Library that ALIAS is turned on. Icon Library sets BOOL ALIAS = TRUE. The Prefs Program loads a linked list "IconList" in the Library Base.
Ah ok, so you've added support for that in AROS system internals as well. Very nice approach.

Quote
When Icon Library processes icons in a given drawer it does it one at a time. In the Library code it is simply CONST_STRPTR name. So if(ALIAS == TRUE) we compare name to the IconList. If we find a match we substitute the alternate icon name which is the full path to the icon.
That is indeed a similar approach, as i had in mind.

The only doubt i had is over using the full path-name.

Thinking out loud that basically that means that, provided that something like that would be implemented, that you could add a end-user way of 'aliasing' the icons by mapping them to something like a file that one one side has the original icon (diskobject) name and on the other side the (diskobject) name of the aliased icon.

That way you could 'flip' the icon-theme with simply changing the name of the mapfile (or in case that would be implemented more profoundly) or by a special preference file that takes care for that.

Very nice indeed. Kudo's

Quote
Icon Library then processes the new icon and copies the attributes from the original icon such as StackSize, IconType, Default Tool, Tooltypes, etc. It behaves like a real icon because it is a real icon. But if we use Icon Prefs to turn Icon Alias off and restart AROS then the list is ignored and icons stored on disk load and display normally.
When i was thinking about this i probably over-thought it a little by taking this a step further by obtaining those values and storing them into a (central) database/prefsfile so that there is one location (for the end-user) to modify those values to be able to apply them to whatever icon you 'aliased'.

That way you could also 'export' a newly crafted icon-set, for systems that do not wish to make use of the aliasing at all.

Quote
The only issues with using Icon Alias is when copying, moving, deleting or renaming alternate icons because then they are no longer on the IconList and their "invisibility cloak" disappears and the original icon displays instead. Icon Information however displays the icon correctly since only the images have changed.
I have thought of that as well, and imagined it would probably be 'easiest to implement' yet another icon-format that supports aliasing by providing a special icon or tooltype that indicate the icon supports aliasing and internally add support for that and act accordingly so that 3th party applications do not have to take care of that.

That is where my theoretical approach more or less ended (except for the topic of icon-caching), simply because of the "yet another icon format" as we are already flooded with those.

Quote
One possible way to address the modification issues just mentioned is to have an external program, maybe the same small app in c: that actually loads the list, sets up a messageport to listen for changes for icons. Then it adjusts the IconList also.
Hmz, i have to think about that a little longer before i am able to judge that correctly. At least it is something i have not thought of myself, so that makes it interesting to begin with :)

Quote
This is experimental but substituting names and copying icon attributes works beautifully in Icon Library thus far.
In basics it is an relatively easy feature to implement, and is able to give much joy.

Personally i am not a huge fan of changing the looks of my AROS desktop (or Amiga desktop for that matter) that often as i prefer to have it as static a possible (so that i now where to look for) but it is for sure a pretty nice feature to have to be able to change the icon-set with the proverbial 'flip of a button'.

I can see the beauty in your approach in that the mapping as i envisioned could be taken care of when the aliased icons are loaded in the list and that it takes care of  caching as well.

Thank you very much for the extensive explanation. It is always nice to be able to push topics back-n-forth to be able to check your own sanity from time to time  ;D
« Last Edit: February 17, 2021, 01:09:42 PM by magorium »



miker1264

  • Legendary Member
  • *****
    • Posts: 1827
    • Karma: +84/-6
Reply #3 on: February 17, 2021, 01:32:16 PM
magorium

I like the idea of using a tooltype to indicate it supports aliasing.

I also like the idea of Icon Caching in Icon Library of drawers we already opened. Again maybe using a linked list?