Bug 363602 - Symlinked SVG files fails to load under Windows
Summary: Symlinked SVG files fails to load under Windows
Status: RESOLVED FIXED
Alias: None
Product: Breeze
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Plasma Development Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-27 20:39 UTC by Jasem Mutlaq
Modified: 2016-09-21 19:07 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jasem Mutlaq 2016-05-27 20:39:42 UTC
SVG files that link to other SVG files failed to load under Windows. Using emerge qt, emerge frameworks, and then emerge KStars. When I ran KStars, I got this:

2016-05-27T23:24:56.064 - WARN - Cannot read file 'C:/Program Files/KStars Desktop Planetarium/share/icons/breeze/actions/22/view-history.svg', because: Start tag expected. (line 1)
2016-05-27T23:24:56.067 - WARN - Cannot read file 'C:/Program Files/KStars Desktop Planetarium/share/icons/breeze/actions/22/view-history.svg', because: Start tag expected. (line 1)
2016-05-27T23:24:56.083 - WARN - Cannot read file 'C:/Program Files/KStars Desktop Planetarium/share/icons/breeze/actions/22/kstars_stars.svg', because: Start tag expected. (line 1)
2016-05-27T23:24:56.085 - WARN - Cannot read file 'C:/Program Files/KStars Desktop Planetarium/share/icons/breeze/actions/22/kstars_stars.svg', because: Start tag expected. (line 1)
2016-05-27T23:24:56.085 - WARN - Cannot read file 'C:/Program Files/KStars Desktop Planetarium/share/icons/breeze/actions/22/kstars_planets.svg', because: Start tag expected. (line 1)
2016-05-27T23:24:56.085 - WARN - Cannot read file 'C:/Program Files/KStars Desktop Planetarium/share/icons/breeze/actions/22/kstars_planets.svg', because: Start tag expected. (line 1)
2016-05-27T23:24:56.100 - WARN - Cannot read file 'C:/Program Files/KStars Desktop Planetarium/share/icons/breeze/actions/22/kstars_constellationart.svg', because: Start tag expected. (line 1)
2016-05-27T23:24:56.100 - WARN - Cannot read file 'C:/Program Files/KStars Desktop Planetarium/share/icons/breeze/actions/22/kstars_constellationart.svg', because: Start tag expected. (line 1)

All these files include the SVG file which has the actual code but under Windows it fails to load them due to the missing start tag.

Reproducible: Always

Steps to Reproduce:
1. Run applications that uses aliased SVG icons
2.
3.

Actual Results:  
Icons fail to load

Expected Results:  
Icons should load
Comment 1 Martin Klapetek 2016-05-28 03:16:34 UTC
(changing the title cause "aliased" in graphics means something very very different :)
Comment 2 andreas 2016-05-28 22:13:11 UTC
the best thing would be to use the linked icons cause kstars_stars mean it is a specific icon but when it is linked than you don't need a specific icon you can choose the origin one which would be better if someone use another icon set than breeze (oxygen) cause there the kstars_stars icon isn't available but draw-star would be available.
Comment 3 Jasem Mutlaq 2016-05-29 05:38:44 UTC
draw-star would be available when KStars is running under a non KDE environment and using a different theme. It's always good to fallback to the icons shipped by KStars.

At any rate, this bug affects ANY icon that is symlinked like view-history above. So view-history will not load on Windows due to this problem.

Why is symlinked SVG loading on Windows broken while it works OK on Linux?
Comment 4 Jasem Mutlaq 2016-05-29 07:44:43 UTC
Correction above: would NOT be avaiable
Comment 5 Dan Leinir Turthra Jensen 2016-06-03 10:48:03 UTC
(In reply to Jasem Mutlaq from comment #3)
> Why is symlinked SVG loading on Windows broken while it works OK on Linux?

While i can't suggest a fix, i can describe exactly why it doesn't work: Git does not support symlinks on windows, and the result is that if you clone out a git repository on Windows which has symlinks, the symlinks will be created as real files containing the name of the file they were supposed to link to as text.

There has been a suggestion that this can be used to generate copies of the symlink files (which will make the repository larger, but result in a functional system with icons shown), but it's not something that's been actively worked on.
Comment 6 Jasem Mutlaq 2016-09-21 19:07:42 UTC
This seems to have been fixed