wbar is broken if /apps/scm_name/share/pixmaps/scm_name.png is a link

[AbNoRMiS]

if install a scm in which /apps/scm_name/share/pixmaps/scm_name.png is a link to real png
and then uninstall this scm, then scm icon stays in the wbar and record about it stays in /usr/local/tce.icons
if after this install or uninstall another scm then the wbar dies and attempt to restart his leads to error

tc@box:~$ wbar &
tc@box:~$ Using /home/tc/.wbar config file.
 -> Image not found. Maybe using a relative path?

[1]+  Done                       wbar
tc@box:~$

wbar starts if installing this ill-fated scm again but then will show the second icon  and so on
it was in tcl 4.3 and also is in tcl 4.4rc1

[roberts]

It would be helpful to specifically name them so that they can become "self contained".

[Jason W]

There are no scm's that intentionally contain a pixmaps/*.png file that is a link to something outside the same extension, to do so would not even make sense and if any exist it is an oversight in the process of using a set of tcz's to make and scm and will be corrected.

The only links purposefully made to anything outside of an extension is the /usr/local/lib/mozilla/plugins/flashplugin.so that is referenced by the flash.scm created by getFlash11.scm.    As well as the share/locale directory of a few that have many megabytes of locale data that exists in a separate scm to save bandwidth and space.   I think those are logical uses of a symlink to something existing outside of an scm and there is no harm done when those targets don't exist.  But as always I am open to other approaches.

[AbNoRMiS]

link to icon inside the same scm
something like
/apps/scm_name/share/pixmaps/scm_name.png -> /apps/scm_name/share/icons/hicolor/48x48/apps/application_name.png

[roberts]

When most work as expected and a few do not. Then that would suggest to adjust the few that don't.
Besides the minimal size increase compared to the overall size increase of an scm is trivial.
tczs are not removal so their structure should not become the model for one that is intended to be removal.

[Jason W]

This morning was the first knowledge I had that a .png file existing as a link to an icon in the same extension was an issue, and they will be fixed at my first opportunity which is tonight.  Upstream apps are often known to use symlinks in their default make install for the same file needing to exist in 2 different places, perhaps that is where one or some instances came from as I normally copy when needing to add an icon.   Or perhaps the icon somewhere in the /apps/extension/share/icons/ directory was used, where they are symlinked icons as well and is often pointed to by XFullIconPath.  But since it is now a known issue, the pixmaps/*.png entries will be double checked to exist as a real file. 

[Jason W]

After testing all existing scms, I found the lone offender that used a symlink for a .png - opera-11.scm.  It is now fixed. 

[AbNoRMiS]

sorry, end up i don't understand
it will be fixed in the scripts that manage scms?
or when creating your scm will need to monitor and correct this point?

[Jason W]

When creating an scm, make sure that the "/apps/extension/pixmaps/extension.png"  is a real file and not a symlink to a file, as indicated by the initial claim of error.  Which extension showed this error anyway?

[AbNoRMiS]

i asked because i ran into this problem when creating scm

[Jason W]

Ok, thanks for the info, as since it affects the loading/unloading it is helpful to know.

And I am glad someone else is also interested in making scm's.