Icon Library Icon Alias

[miker1264]

At some point I would like to further develop Icon Alias inside Icon Library. It uses an IconsList for an Alternate Icon Set to replace icon images "on-the-fly" as they are being displayed.

This concept was originally devised by Kalamatee but he never really pursued it. It was just a concept.

However I made a proof of concept test and it actually works!

So I would have to work out the logistics of how to make it work in an AROS-friendly way. It will probably involve a "switch" like an on/off switch in Wanderer Prefs. Icon Alias on or off. If it's turned on the Prefs must point to an Alternate IconsList text file. A better place for the checkbox and text box would be in "Icons Prefs" if we don't already have it we can easily make new prefs.

Icons Prefs would allow selecting from several installed icon sets that would be displayed in a listview. That makes it easy.

At startup Icon Library looks at Wanderer Prefs to read the values. If it's turned on it reads the text file and converts to an internal dos list to compare icon names while displaying icons.

If the name is on the list the alternate images will be displayed.

That would be really cool if it works correctly. It's complicated.

[deadwood]

On first sight my suggestion would be not to couple icon.library with Wanderer, so this configuration should be something that icon.library "owns". Wanderer Prefs might "also" create it, but I don't think icon library should be reading Wanderer preferences files.

[miker1264]

On first sight my suggestion would be not to couple icon.library with Wanderer, so this configuration should be something that icon.library "owns". Wanderer Prefs might "also" create it, but I don't think icon library should be reading Wanderer preferences files.

That is a good point. Maybe a separate Icons Prefs that is set up just for Icon Library so it would be independent of Wanderer.

I'm not entirely sure how to set up a dos list either but there is much research to do. It's completely experimental. It may be overly complicated and maybe it won't work as planned.

Here is attached my proposed framework for Icon Alias. Instead of Dos List it may be Exec List. I'm not familiar with that.

Does is seem possible?

[miker1264]

After doing some research I have decided to abandon Icon Alias inside Icon Library in favor of direct icon replacement using a similar approach with "Icon Alias List Processing".

I'll be working on my "ReplaceIcons" Application instead. 

[magorium]

Hello miker1264,

"Replaceicons" application ? As in a standalone application that literally replaces the icons on disk ?

I have given this icon aliasing some thought in the past, and in theory (as in i do not have a proof of concept) it should be possible to write something similar like a commodity that patches the necessary icon library entrypoints to intercept those that are required for filtering out the icons you would like to replace.

E.g. you could have an icon theme editor that allows for creation of a 'replacement' list and the commodity that is able to load/compare the current loaded icon with your themed list and replace the corresponding icon (name/path) accordingly. If the icon does not belong to a theme it can then call the original icon library function as normal.

Basically a lookup and replace icon location/name.

Just 2 cents.

[miker1264]

Hello miker1264,

"Replaceicons" application ? As in a standalone application that literally replaces the icons on disk ?

I have given this icon aliasing some thought in the past, and in theory (as in i do not have a proof of concept) it should be possible to write something similar like a commodity that patches the necessary icon library entrypoints to intercept those that are required for filtering out the icons you would like to replace.

E.g. you could have an icon theme editor that allows for creation of a 'replacement' list and the commodity that is able to load/compare the current loaded icon with your themed list and replace the corresponding icon (name/path) accordingly. If the icon does not belong to a theme it can then call the original icon library function as normal.

Basically a lookup and replace icon location/name.

Just 2 cents.

That's basically how I had thought about doing it using an alternate icon list. I explained the complete process in a text file. It's in a previous post "Icon Alias Components.txt" attachment.

The proof of concept is already done. If we can build an Exec List for Icon Library to use then it should work. But it requires a lot of effort to build the list with nodes and node names that correspond to icon basenames (icon filename without .info).

Notice the "green icon" for the Utilities Drawer. That's Icon Alias. I suppose I may pursue both methods, Replace Icons/Icon Alias. But building an Exec List is an overly complicated approach.

[magorium]

thx for the info miker.

I must be going blind or the board does not give any notion of an attachment when not being logged in.

Your text document describes pretty much how i would approach it. except for ....

I have a fairly stupid question: why a dos/exec list ? Can't it be a single or double linked list in pure c (or whatever, perhaps even a sqlite db) ? (i understand the latter is not very speed friendly). Is it a OS/library requirement ?

[miker1264]

thx for the info miker.

I must be going blind or the board does not give any notion of an attachment when not being logged in.

Your text document describes pretty much how i would approach it. except for ....

I have a fairly stupid question: why a dos/exec list ? Can't it be a single or double linked list in pure c (or whatever, perhaps even a sqlite db) ? (i understand the latter is not very speed friendly). Is it a OS/library requirement ?

The List will need to be traversed for each icon being displayed. The Exec List uses nodes with node names. Using the Find command the list either returns a value or NULL if not found. So it must be a fast process. As I understand Exec Lists are fast.

It shouldn't matter what kind of list Icon Library uses. It must be loaded into Icon Library such that all modules can read the list. The module "geticontaglist" must access the list to compare.

[magorium]

The List will need to be traversed for each icon being displayed.

I got that part 

The Exec List uses nodes with node names. Using the Find command the list either returns a value or NULL if not found. So it must be a fast process. As I understand Exec Lists are fast.

It is actually a pretty dumb traversal + strcmp, as dictated by RKRM, see also https://github.com/deadw00d/AROS/blob/master/rom/exec/findname.c

btw there is another overhead with exec lists (as dictated by rkrm):

No arbitration is done for access to the list!   If multiple tasks access the same list, an arbitration mechanism such as SignalSemaphores must be used.

It shouldn't matter what kind of list Icon Library uses. It must be loaded into Icon Library such that all modules can read the list. The module "geticontaglist" must access the list to compare.

I think I would probably opt for something like a hashed list.

When i initially started thinking on this subject i had imagined to use a (icon diskobject) checksum but that would probably slow things down too much.

[miker1264]

We only need for the List to return TRUE or FALSE whether there is a Match or No Match. We are only comparing the basenames.

We already have the icon basename together with the iconpath we can reconstruct the full path to the alternate icon file to be displayed in the window.

I assume the Exec List will need to be declared in Icon Library Init and it needs to be stored in the Library Base so it can be accessed by all the modules. The List "has a tail and a head. It can be empty but never full" according to the documentation.

I'm not sure how to use a semaphore but it seems an Exec List will require that. That seems like advanced programming to me.

[magorium]

Just sparring a little here. Hopefully it triggers some thoughts (for the positive).

We only need for the List to return TRUE or FALSE whether there is a Match or No Match. We are only comparing the basenames.

Have you though about the fact that different icons residing in different directories can have the same base name ? It does not necessarily means the icons are the same. A good example of that is the directory name (which has a directory icon) and the executable name inside that directory that 9 out of 10 times has exactly the same name as the name of the directory. Or are you creating a list/nodes based on directory names ?

We already have the icon basename together with the iconpath we can reconstruct the full path to the alternate icon file to be displayed in the window.

so far so good 

I assume the Exec List will need to be declared in Icon Library Init and it needs to be stored in the Library Base so it can be accessed by all the modules. The List "has a tail and a head. It can be empty but never full" according to the documentation.

I do not see the need to make the list a part of icon library or icon library having to take care of that list. The list is uniform for all instances of icon library. If there isn't any icon library running anymore then well... the functions you patched to run your code won't be called either 

I'm not sure how to use a semaphore but it seems an Exec List will require that. That seems like advanced programming to me.

If you wish to make sure that some resource can't be accessed/modified at the same time then a forbid/permit pair will do.

But that is/can be a bit crude 

For more about semaphores see http://amigadev.elowar.com/read/ADCD_2.1/Libraries_Manual_guide/node02F5.html (make sure to click the browse button multiple times to read the full documentation about semaphores) and here a very small example http://amigadev.elowar.com/read/ADCD_2.1/Libraries_Manual_guide/node058D.html

[miker1264]

RKRM sample buildlist.c gives examples of lists with named nodes. That's a good place to start.

Thanks for the information about semaphores. It seems I would only need a semaphore while adding names to the List. Then it can be released. If the List is only static (after items have been added) then we don't need a semaphore to read the List items.

We are only comparing basenames. Icon Library only displays one window at a time. So we are only matching the name of the current icon which can represent a file or a drawer. The name it compares has no .info extension. So drawers are same as files.

As for the alternate icon name there only needs to be one name for each icon. It's only a list of basenames. So if we are comparing "multiview" in Utilities then it finds the basename "multiview" in the alternate icons list. So it displays that icon. If we then move to Storage directory and there is another "multiview" icon being stored there it still finds the "multiview" icon in the alternate icons list and it only displays that icon. So it doesn't matter which directory the current icon is located in. There will only be one corresponding alternate icon in the list. So I see what you mean about drawers and files with same name.

If, for example, we have a directory called "Dopus" that has a custom icon (not def_icon) and inside the directory we have another "Dopus" icon that is for the executable file itself there's no problem. They can be different icons. We will have two Lists. One for Drawers and one for Files. Or find a way to store and compare the complete filenames. If we use two Lists one for drawers and one for files we will need to test if the current icon is a drawer or a file. That's simple enough just look at the diskobject to get the icon type. WBDRAWER or PROJECT.

[magorium]

RKRM sample buildlist.c gives examples of lists with named nodes. That's a good place to start.

Sorry i could have mentioned that 

Thanks for the information about semaphores. It seems I would only need a semaphore while adding names to the List. Then it can be released. If the List is only static (after items have been added) then we don't need a semaphore to read the List items.

You're welcome. However, do not keep the reading bit too light. You do not know who is reading/writing into the list at what exact time. So you cannot read the list if it is being written to. Well, you could but that could lead to missing names. Unless you cache the replacement base names that is only checked against.

e.g. up til now i was assuming you wouls create the replacement list based on what icon library tries to read and compare it to your list of alternating/replacement  icons. I hope that did made any sense.

We are only comparing basenames. Icon Library only displays one window at a time. So we are only matching the name of the current icon which can represent a file or a drawer. The name it compares has no .info extension. So drawers are same as files.

Ok, the use of a single basename is a design decision that can be respected. However, icon library displaying one window at a time is a) not icon libraries doing and b) see prefs/wanderer/tab generic/method = classic/use

Thereby, if you have multiple disks, each disk has it's own wanderer window.

As for the alternate icon name there only needs to be one name for each icon. It's only a list of basenames. So if we are comparing "multiview" in Utilities then it finds the basename "multiview" in the alternate icons list. So it displays that icon. If we then move to Storage directory and there is another "multiview" icon being stored there it still finds the "multiview" icon in the alternate icons list and it only displays that icon. So it doesn't matter which directory the current icon is located in. There will only be one corresponding alternate icon in the list. So I see what you mean about drawers and files with same name.

Thanks for your input and as i said earlier, it is a design decision i can respect (e..g not including every icon/program on the disk).

[miker1264]

I am only using the basenames for a quick comparison. But you are correct that I must deal with drawers and files with the same basename. I believe I have a way to do that.

We only need the basename in the Alternate Icons List for comparison with the current basename. It can handle drawers and files. We use the function FindType to get the icon type. If WBDRAWER we add "Drawers/" to the icon path. If PROJECT we add "Files/" to icon path when we build the full path to the icons.

The real alternate icon files will be arranged in two subdirectories - Drawers and Files. If the real icon exists in that location it will be used. Else the original icon displays instead.

So first we must find a matching basename. Then the drawer icon or file icon must exist on disk before it can be displayed.

If the icon alias comparison fails the original icon will display.