Created attachment 54 [details] PulseView not displaying .svg icons While comparing the linux and windows (the experimental installer from 2.1.) versions, the Windows version doesn't show icons based on svg - e.g. the probes or run/stop icons in the toolbar. The png icons are all ok, see screenshot attached. The thread at: http://stackoverflow.com/questions/4318990/svg-icons-not-showing-up-in-qt-release-build-in-windows indicates, this is a "release version only" problem with missing or not found qsvg4.dll, which seems to be expected in a folder "imageformats" below the application folder, or maybe by tweaking a qt-conf file. I've tried to fix this with copying some of the qsvg4.dll I had on my machine into such a newly created imageformats folder, but without success - probably because I don't have the right assembly version. If you could provide me with the right qsvg4.dll assembly version, I may try to check if that solves the problem already (so that hopefully only a minor NSIS script problem).
I've looked into this a bit, but it requires a bit more investigation than I thought. One thing that seems to be required is that we need to use/link QtSvg in addition to the currently used QtCore and QtGui. That, in turn, requires QtXml. So far, that's no problem, we can use a simple patch like this: -find_package(Qt4 REQUIRED) +find_package(Qt4 COMPONENTS QtCore QtGui QtSvg QtXml REQUIRED) However, a quick test shows that that alone is not enough. Apparently we also need to link/include libqsvgicon (a Qt iconengine) for this to work, needs some evaluation/testing on how to properly do that.
Would it be preferable to flatten the SVGs to PNG during the Build? We would need to deal with some icon scaling issues - but in reality there is no such thing as a truly scalable icon even if it is stored as a vector image. At small sizes shapes have to be adjusted to be aligned to a pixel grid to prevent a blurry appearance. Perhaps doing this would reduce the size of the binary.
Scaling of icons in general doesn't work well :-) If the icon is small (16*16) and has little detail so you can recognize it, it won't look good as a large icon. If an icon is large and has more detail, it won't look good as a small icon. For example, if a 16*16 icon is needed, scaling a nice detailed svg shows it's natural limits. Of course that problem depends on the icon content. So before we get into the hassle of this qtsvg thing, we might consider converting to nice looking png using inkscape, which usually provides better looking output anyway, and put (a set of different sized of?) them into git. BTW: At an installer size of roughly 30MB I don't think we should care about a few small icons here.
Right... this has been in my mind for a while. I had this very problem when I did the Tango icons for Wine: http://airwebreathe.org.uk/w/doku.php?id=wine_icons On some platforms: MacOS, the icon size is larger. I'm not sure what Qt does with different screen DPIs, but I suspect we need to have some support for multiple icon image sizes. The solution we had then was a master SVG containing several images with an invisible rectangle to show the boundaries: http://source.winehq.org/git/wine.git/blob_plain/HEAD:/dlls/user32/resources/oic_winlogo.svg. A perl script would then render the area of each of the rectangles and integrate them together into an ico file. I'm not sure if we need something so elaborate for PV, but building PNGs from SVG in the build is highly desirable.
@uwe: To be honest, I don't want to go deeper into that cross compiling QT thing. I just have no interest in that domain. I've googled around and didn't found real helpful resources in that area anyway. Looking at the windows digikam installation, I fear that using .ico files will lead us to the exact same problem. There's a qico4.dll under plugins\imageformats, indicating .ico files won't be displayed on Windows as well. I may be wrong here and I haven't tried it. A quick hack would be: Putting a set of png icons converted from svg with inkscape maybe to 22*22 (just like the existing .png icons) and put them into git. And in the code: #ifdef _WIN32 QIcon(":/icons/abc.png") #else QIcon(":/icons/abc.svg) #endif I know this is an ugly hack, but I don't see a clean solution here anywhere soon.
No hacks. That's not how we roll. We do things properly or not at all. The two possible solutions are: * Integrating qtsvg for windows users. * Adding SVG->PNG conversion via RSVG in the build.
or c) Do a proper native Windows build, to use the way others are working with QT on Windows. I'm sorry to say, but this Windows QT cross compiling is an ugly hack already! Doing the build properly, we wouldn't have this problem here at all. Therefore I don't buy your: "No hacks. That's not how we roll. We do things properly or not at all." - in this situation.
The QtSvg fix is likely both the easiest and most elegant solution for this. It does work exactly like that on Linux and Mac OS X, after all. It's just that we need a small fix for this on Windows. I'll have a closer look at how to solve this tomorrow or so. I have to disagree with a cross-compile script for Windows builds being a hack, though. I've personally spent many, many days and nights messing around with native builds on Windows (via native MinGW), and while it's certainly doable if enough time is put into it, it was a rather painful experience. For me personally, using a cross-build setup with MinGW + MXE is a lot more convenient, and it works very well. So well that I stopped bothering with native builds completely, actually. All official Windows builds for sigrok projects that we'll provide will be generated by sigrok-cross-mingw. That said, there is no problem doing both native and cross-builds if you're inclined to work on resurrecting native builds. My old instructions are at http://sigrok.org/wiki/Windows/Building, but they are quite outdated by now and you'll probably face a lot of non-trivial issues if you try to build all of the sigrok subprojects that way. I think Martin Ling did a native build recently and wanted to update the instructions a bit (he solved one of the painful things, getting glib built), though I think that only included sigrok-cli. For PulseView you'd also need to get Qt and Boost working, which may be non-trivial. If you do want to go ahead though, check/update the sigrok-cli.nsi.in and pulseview.nsi files (those were used back then for native builds; these days we only use sigrok-cli_cross.nsi.in and pulseview_cross.nsi). Cheers, Uwe.
@Uwe: I've added the last part of Comment 8 to http://sigrok.org/wiki/Windows/Building#Native_build, because that might be interesting for other potential Windows developers. BTW: If a native Windows developer mentions a proper native Windows build, mingw is usually out of the game ;-)
This is fixed in 11a04e2a8ed47ed159b68cbe6f56aedd388e445f. All SVG icons appear to be shown correctly now.