(No comment was entered for this change.)

1. ICL format is a 16 bit all Windows starting with Vista do not support it any more.
2. Yes it already exist , this is what icolib in the core does. Dll is just one of the 
method of icon distribution.
3. Windows API does support icons only, although Vista and later does support png 
encoded icons.

I am closing this request as everything you are asking for already exist in form or the 
other.

I meant ICL format is the 16 bit dll renamed, and Windows starting with Vista deprecated it. ICL file could not be read on it. 

ICL is not my main proposition;

By using ico files separately without packaging them into DLLs will simplify theming
and cross referencing between plugins.

Sure we can keep distributing them in DLLs, and have duplicates with every plugins,
but it is a pain to manually edit everything with reshack or other ressource editor.
At some point it will become an issue when size matters.

I assure you, while slimming Miranda down to make it more portable (sfx), I freed
more than 2MB simply by removing 8bit counterpart of every icons (32bit icons end up
smaller than 8bit indexed icons) and converted some (about 50) to optimized 4bit or
2bit icons.

While doing so I have seen many DLLs containing similar/identical duplicates, which I
did not bother cross-referencing within Miranda's icon customization option (too much
of a hassle to play Pelmanism with that many icons).

Moreover, I proposed png instead of ico simply because smileyadd's nova set takes
429KB in ico format but after converting them to 32bit png they take 159KB. The png
version worked fine (even transparency) after editing the paths in the msl files.

In the end, separating icons from the DLLs (including miranda32.exe) will streamline
the process of changing and sharing icons (user) and allow smaller footprint and
easier cross-referencing (developper). Using png, if possible, will allow easier
editability (photoshop, etc.).

I forgot to mention, I understand that icolib has an underlying ini-like referencing
(after exporting with dbeditor) but it defeats the purpose of slimming Miranda down
if all the icons are always repackaged within DLLs.

I can manually set folders with all the icons and manually reference them from within
Miranda's icon customization option but having the same icons within the DLLs will
only increase size.

If packaging them is necessary why not archive them since zlib comes with Miranda?

The main idea is that non-essential icons are to be separate from the DLL of
"Plugins" directory and the "miranda" executable while DLLs are not used anymore in
"Icons" directory. Doing so will simplify updating since icons will not be embedded.

I hope that my point is clearer now.

You misunderstood. In addition to 32 bit icon format that was introduced in XP there 
is png icon format, it was introduced in Vista. 

Yes file size will be smaller, when you convert png to 32 bit icons, but it takes 
long time to make it usable. Imagine opening menu, 15 icons there, it will be really 
a slow down. 

In SmileyAdd graphic format conversion (from png to ico) is used only when showing 
smileys on the contact list, in all other cases smileys are drawn on the directly 
without format conversion.

Understood ^_^

I hope that at least an easier icon replacing method may be in place and that somehow
icons don't get duplicated. Keeping it small is great.

Anyhow, Miranda is my one and only messaging client, it's the best and smallest
multi-protocol IM :D

(No comment was entered for this change.)

The other problem with png, Windows pre XP does not support it or alpha blending, so we 
cannot break compatibility. We still wan to support older OS. Maybe for Miranda 1.0 we 
will finally drop old stuff. 

What I would really like to see is to move the icons out of miranda32.exe (and the
core DLLs) into seperate icon DLLs, so you could change them easily

Making any icon libraries (either .icl or .dll) needs specialized program, a lot of
time (putting the icon in the right place, updating the whole library when I want to
change just one icon), it’s literally a pain in the ass. I myself made a lot of
icons, a whole new suite for Miranda, but I just can’t find a way to easily access
them to users so they can use them without messing with many files or even worse,
putting the icons in manually one by one. In my opinion .ini file would be the best
solution, and there still can be two directories with two different color depths. It
would still make less problems than libraries...

You can try using reshacker...

" so they can use them without messing with many files" -> splitting them into
seperate files and adding ini etc would result in even more files, not less

The advantage of a dll from the user's point of view is that it is only ONE file he
has to put in a dececated place, splitting it into pieces would rather make it more
complicated

@wishmaster51 Yes… I had on mind something more like folders, users wouldn’t have to
care about their content. When it comes to this, what about packing the big quantity
of files (icons in .png + .ini) into a zip archive? Like for example in Opera skins.
The same functionality for users (single file), while easier for the icon developers
(no special program is needed)…

How about using sprites? Small, single file, widely editable, previewable. It seems
to be the best solution for this problem.

I do not remember Windows GDI supporting sprites :).

I do not know how but, somehow, tabsrmm managed it for skins with the $glyphs section.

Skins are self drawn we are not going to self draw the whole UI and all the dialogs and 
everything else.

TabSRMM is a bloat and no way in hell we are going to make Miranda like it. If you have 
not noticed TabSRMM is not even core plugin. Our objective make the smallest IM not a prettiest one.