[Belle Refresh] Where the follow icon is stored?

[Symbian55]

In series60skin.mif? Which major id and minor id has it?

greets

[Symbian55]

Can nobody help me?

[wizard_hu_]

If you ask it as a Symbian C++ programmer, while I do not know how the major-minor numbers of skin elements relate to it, the .mif file itself has a single, linear index number, starting with 16384 for historical reasons. So you can create some application getting/displaying all icons from a .mif file (AknIconUtils::CreateIconL/C). Even numbers (16384, 16386, ...) identify the icon content, odd numbers (16385, 16387, ...) are the masks.
If you ask it as a theme/skin developer, I have no idea about those ID-s, but I can move this discussion to the Themes/UI board.
Remember that it is end-of-the-year period practically everywhere, and also it is Christmas in the Christian-tradition part of the world, so this is a reason why there are not many things happening on these boards now.

[Symbian55]

Thank you for your answer.
I ask it as theme/skin developer. Yes, please move the thread to Themes/UI board. Thank you very much!

Is in the mif only the inear index number saved? Or also other information?

[wizard_hu_]

I ask it as theme/skin developer. Yes, please move the thread to Themes/UI board.

Yes, of course, the question is moved now, its link remains the same.

[wizard_hu_]

Is in the mif only the inear index number saved? Or also other information?

It is not saved, it is a physical index, just with a 16384 shift.
Originally there were .mbm (=multi bitmap) files for storing icons. They were created from multiple .bmp files (normal, Windows-style bitmap files). For convenience reasons, the converter tool created an identifier for each icon, consisting of the .mbm file name and the actual icon file name. Like EMbmHelloworldBall would be an identifier inside HelloWorld.mbm, pointing at the sub-file/bitmap which was created from Ball.bmp. These identifiers were just named numbers, starting from 0 (if you also happen to code besides creating themes, 0-based indexing in the computer world is certainly familiar to you already).
However after a time Symbian introduced .mif (=multi image file) files for storing scalable icons, created from .svg-s. This is where some compatibility tricks were introduced: Symbian wanted to make the transition smooth, so the new tool creates the same names for identifiers, like EMbmHelloworldBall for HelloWorld.mif containing Ball.svg, just these identifiers start from 16384. The other trick is that the API loading icons selects the actual file based on the identifier passed. If it is smaller than 16384, whatever the filename was, it will pick the .mbm version. If it is something larger, AknIconUtils pick the .mif file.
This minor magic results in the convenience that if you previously had HelloWorld.mbm, containing Ball.bmp as its first bitmap (so EMbmHelloworldBall happened to be 0) and decided to update the application with a scalable ball, Ball.svg packed into HelloWorld.mif, you could simply re-compile your existing application after generating the new icon file, and you were done. While the application itself still contained a reference to HelloWorld.mbm, after re-compiling the application EMbmHelloworldBall happened to be 16384, causing the API to load the ball from HelloWorld.mif. And it happened automatically, without modifying a single line in the actual application (just think about how many applications are present built-in in a mobile phone).
Also, this transition could happen gradually, at any time. So some of the icons could be updated, using new, scalable format, and the others could be still loaded from the old file.
So this is the magic. While I like this trick, it is a pure technical detail, and unfortunately it does not help you with finding out major-minor skin identifiers, they are completely different things.