I had this approach (I think from patience deck) but haven’t been able to get it to run in the sdk
for size in 86 108 128 172
do
mkdir -p %{buildroot}%{_datadir}/icons/hicolor/${size}x${size}/apps/
rsvg-convert --width=$size --height=$size --output \
%{buildroot}%{_datadir}/icons/hicolor/${size}x${size}/apps/%{name}.png \
/harbour-allthenews.svg
done
any tips?
Maybe rsvg-convert is not installed ? If so, add BuildRequires: librsvg-tools in your spec file.
Depending where this is executed, the / in front of harbour-allthenews.svg looks a bit suspicious also…
Had that, but something is wrong with my paths.:
+ for size in 86 108 128 172
+ mkdir -p /home/deploy/installroot/usr/share/icons/hicolor/86x86/apps/
+ rsvg-convert --width=86 --height=86 --output /home/deploy/installroot/usr/share/icons/hicolor/86x86/apps/harbour-allthenews.png harbour-allthenews.svg
Error reading SVG:Error opening file harbour-allthenews.svg: No such file or directory
I guess this code is run fro, the spec file. Where is located harbour-allthenews.svg with respect to the directory of your project ?
It’s in the root of the project. Just checked and that’s how it’s set up in patience deck. But patience deck is not built in the qt sdk, but using sfdk directly. Still getting my head around it.
Is there a cd run in your spec file before the rsvg conversion ? Is the code in a public repo ?
Ah, I missed the Qt SDK part… It’s indeed building ok with mb2 (or sfdk). Maybe declare the harbour-allthenews.svg as an extra in the .pro file so it is known by Qt and sent to the building target ? I only guessing here…
I think the SDK might be using shadow builds, whereas sfdk only optionally does that…
So you might need something along these lines Fix shadow builds · attah/harbour-seaprint-share-plugin@92add8d · GitHub
(translations would work in sfdk, but not sdk iirc)
$$PWD/ ah, duh. I feel slow today. But that’s just cause I was wading through qtbase hunting color tables.
All my incantations failed until:
rsvg-convert --width=86 --height=86 --output /home/deploy/installroot/usr/share/icons/hicolor/86x86/apps/harbour-allthenews.png .sfdk/src/harbour-allthenews.svg
There is also sailfish-svg2png which I guess is the “official” way to do it.
But IIRC it doesn’t do app icons, rather system ones.
I had tried that route. I’m just stumbling on getting a var to rpmbuild. I have a bunch of extra build steps in other projects, but those are not rpmbuild but rather make or the like, individual commands. The link that attah sent is also, I believe for individual commands and not rpm build.
If that is in the %install phase that is fine, but really should use rpm macros %buildroot and %datadir for the output location.
sailfus-svg2ong is supposed to be called from .pro/qmake, so in the %build phase.
sorry, it’s the INPUT file that’s not being found building in the sdk. It works using sfdk ‘manually’.
The command
rsvg-convert --width=$size --height=$size --output \
%{buildroot}%{_datadir}/icons/hicolor/${size}x${size}/apps/%{name}.png \
harbour-allthenews.svg
done
is using the right macros, but the input file, at the end isn’t found. I also tried (cribbed from storeman installer):
%define hicolor_icons_dir %{_datadir}/icons/hicolor
for s in 86 108 128 172
do
prof=${s}x${s}
install -d %{buildroot}%{hicolor_icons_dir}/$prof/apps
sailfish_svg2png -s 1 1 1 1 1 1 $s . %{buildroot}%{hicolor_icons_dir}/$prof/apps
done
The problem remains that from the SDK the INPUT file can’t be found (in storeman installer case, it’s in the root, as in allthenews, also).
It doesn’t really matter, since the SVG doesn’t change that often. I was just curious if I could make it work, as @attah suggested, with shadow builds in the SDK. I can get it to work from the cli (I was building patience-deck in @tomin’s way which is straight sfdk).
I had tried in build phase as well. I think I need a lecture from @olf ! I’m going through the build manuals in the QT context, but that’s going to take weeks 
Sorry for not getting it.
Two things come to mind: specify the original as a SourceX: and using $SOURCEX which will have the full path, or possibly the %builddir or %sourcedir macros.
… which never really worked, as I found out lately: It seems to have generated all icons in 256x256 (the pixel size provided by the SVG’s metadata), as rpmlint reported.
Mentaljam suggested calling sailfish_svg2png in a different manner, but I decided to drop this conversion, create an icon directory, export the SVG manually (with Inkscape or at the command line, e.g., with rsvg-convert from the librsvg-tools package) in the four needed resolutions and deploy them per cp. I.e., the classic route, simple and fail-safe.
P.S.: Here is a version of Mentaljam’s suggestion without BASHisms (array) and precomputed fractional values, including further reasoning, why not to utilise this approach.
Note that his original version and my adaption are untested in “real life”, i.e., in an RPMs %install section.
Still I would be interested to know if anybody succeeds in using sailfish_svg2png in an RPM spec file, because there are a few mentions of this from the past (SFOS 1.1.x times).
Note, that one should check if the four deployed icon PNGs really have the correct sizes: 86x86, 108x108, 128x128 and 172x172.
So I use it as (I think) “intended” from qmake within the .pro file, where there is AFAIK no configuration about sizes necessary. qmake takes care about the source location and installing. BUT that generates theme icon pngs at /usr/share/themes, not application icons (/usr/share/icons):
Note that svg2png expects the svgs to be in the folder ./icons/svgs relative to where its called from.
In a .spec file I use it here, but all is done manually, quite similar to the calls in storeman-installer.spec, and I use SourceX: and %{SOURCEX} for the path to the original:
I think the reason is that commands in rpm spec file aren’t supported by shadow builds which SDK IDE uses. It should fail the same way when using shadow builds with sfdk (sfdk build <source directory>).
This issue could be fixed by moving the commands from spec to qmake targets so that they would be run by make instead. It should be possible but at least I’ve found qmake a bit difficult to work with.