Missing SVG icon on Nokia e65

[ahlmans]

Hi!

We have an application that works fine on most S60 3rd Ed phones. However, on the Nokia E65 no icon is displayed either in the menu or in the app statusbar. The title of the app is shown in the menu, and the app can be started from the shortcut but no icon is displayed.

Also, the app usually sends itself to the background when not in use. Normally you see a small icon in the top right corner of the shortcut to signal that the app is running. This is not shown either on the E65, although the app is running fine in the background.

Ideas?

[stenlik]

Hi,

I have the same problem when I have compiled the icon with 3rd FP1 and the I have used it on the 3rd MR device as the mif format changed (it is not plain text pn FP1)and it is not backward compatible. I had also similar problems with svg saved in the Inkscape, but never with the Adobe Illustrator.

BR
STeN

[ahlmans]

Thanks!

That was it! I recompiled it using the 3rd Ed. MR SDK and it worked.

[nadav_smilansky]

Thanks!

That was it! I recompiled it using the 3rd Ed. MR SDK and it worked.

Unbelievable! This makes the 3rd FP1 SDK useless for anybody who wants to use MIF files. This is so basic, that it is almost hard to believe it was overlooked by those who were releasing the new SDK.

[wizard_hu_]

Your ignorance is the unbelievable one... E65 is an S60 3rd noFP device. You should always use compatible SDK-s.
And by the way, it is documented in the Wiki, and also discussed on the DiBo several times that the new mifconv.exe is able to produce old-style, uncompressed .mif files if you use the /X switch.

[nadav_smilansky]

Your ignorance is the unbelievable one... E65 is an S60 3rd noFP device. You should always use compatible SDK-s.
And by the way, it is documented in the Wiki, and also discussed on the DiBo several times that the new mifconv.exe is able to produce old-style, uncompressed .mif files if you use the /X switch.

Well, I admit an ignorance on my part on this issue, but I think this ignorance is completely understandable. It is unrealistic to expect developers to read all the articles in Wiki before they start programming.

A reasonable programmer would simply download Carbide C++, and then download the latest SDK. Such a reasonable programmer would get into hardships.

In my humble opinion, there should be a single SDK, which addresses all S60 phones. It makes no sense to me that a programmer needs to choose between producing several revisions of the software for different phones, or alternatively use an older SDK version, which may or may not support new features, and may or may not have all the latest bug fixes. Moreover, if different revision of the software are produced for noFP, FP1, FP2, etc., it requires multiple SymibanSign cycles and fees, and also forces the user to choose the correct package to download.

Anyway, as I said, my opinion is indeed humble.

Thanks for the "/X" hint,
Nadav

[ltomuta]

Indeed, I don't see a problem as long as the SDKs are used correctly and no forward compatibility is assumed.

[nadav_smilansky]

Indeed, I don't see a problem as long as the SDKs are used correctly and no forward compatibility is assumed.

Not sure what you are recommending. I can see 3 options:

1. Create a different package for each FP.
2. Use only the noFP SDK, and avoid using any FP1 and FP2 features.
3. Use the FP2 SDK, but make the icon.mk file use the /X for mifconv.exe, as mentioned by wizard_hu_.

The first option is very undesirable because of the reasons I've mentioned below(it is a SymbianSign nightmare, and also an headache for the users who need to download).
Second and third options are also undesirable, because they create larger packages (uncompressed MIF files).
The second option also makes one worry about bugs that may have been fixed in FP1 but not in noFP SDK.

What would be your recommendation?

[ltomuta]

The simple answer is [2] as the lack of .mif compression is likely compensated by SIS file's compression (have't run test but sounds reasonable to me).

I wrote a larger answer about this but I've changed my mind about posting it here, it will be a blog post soon :)

[nadav_smilansky]

The simple answer is [2] as the lack of .mif compression is likely compensated by SIS file's compression (have't run test but sounds reasonable to me).

I wrote a larger answer about this but I've changed my mind about posting it here, it will be a blog post soon :)

Since I've been using FP1 SDK all the time, I've decided to use option 3, after verifying that indeed the sis file does not get much larger that way.

Things are now working for me in both FP1 and noFP.

Perhaps I'll change it to #2, as you suggest.

BTW - which blog?

Thanks,
Nadav

[ltomuta]

This one: http://blogs.forum.nokia.com/blog/lu...rum-nokia-blog :)

[wizard_hu_]

The second option also makes one worry about bugs that may have been fixed in FP1 but not in noFP SDK.

Remember that what you actually use from the SDK are stub libraries for the .dll-s on the device, so the bugfixes are not that obvious:
- if you can happily run your code on the FP2 "fixed" emulator, it will still die on a noFP device containing buggy .dll-s
- if the code happens to die on the 3rd MR emulator, the code may run flawlessly on a new device containing the fixed .dll-s
Both directions indicate that in case of you need an API which has been substantially changed over time, you can not do the development with single SDK pick, either it be the oldest or the newest one.

[nadav_smilansky]

Remember that what you actually use from the SDK are stub libraries for the .dll-s on the device, so the bugfixes are not that obvious:
- if you can happily run your code on the FP2 "fixed" emulator, it will still die on a noFP device containing buggy .dll-s
- if the code happens to die on the 3rd MR emulator, the code may run flawlessly on a new device containing the fixed .dll-s
Both directions indicate that in case of you need an API which has been substantially changed over time, you can not do the development with single SDK pick, either it be the oldest or the newest one.

Exactly for those reasons, I almost never use the emulator.

I write the code, and then test it on noFP, FP1, and in the future on FP2 and 5th Ed. It is rare that a problem occurs, and if it does, I try to solve it locally.

So far it was completely OK for me, and since the other alternative is too costly and also confusing to users who want to download, I think I'd better stick to it for the time being.

Thanks,
Nadav