Hi, > On Thu, Jan 24, 2013 at 12:18 AM, Tim Sutton <li...@linfiniti.com> wrote: > > Hi >> >> On Wed, Jan 23, 2013 at 2:10 AM, Larry Shaffer <lar...@dakotacarto.com> wrote:
8<------------------------------------------------ >> 5) Clean up source code to work with only .svg icon files. But, do not >> remove any code for theme choice, so that designers can still work on new >> themes without having to replace the existing default one. 8<------------------------------------------------ > +1 from me on all these points too. To be clear, you are suggesting to > ship with only one theme, but leave theme support in place? Yes. For three reasons: * As previously noted, this will allow future icon designers to try out new themes without much effort and be able to switch back-forth between themes to see differences (like now). * Have central functions for fixing some issues (e.g. embedded rasters in SVG), providing the source file in a variety of formats (QIcon, QPixmap, QImage), and for abstracting away the need for an extension. Example: QgsApplication::getThemeIcon( "vector-edit" ) This would return a QIcon, but built off of a SVG source, if one exists, if not use a PNG. There should be no need to define the extension in the parameter. This will help during the move from PNG to SVG, as once a SVG file becomes available, it is automatically used. I also suggest adding the following function: QImage QgsApplication::getThemeImage( const QString theName ) * Allows to build some form of caching (if necessary) Currently the QgsApplication::getTheme... functions query the filesystem, but many of the icons are already in images.qrc (essentially a cache). Those functions could look in the Qt resource first. Also, as part of the build, and source install, there could be a script (e.g. scripts/update-themes.sh) that parses the themes directory and auto-generates a <mytheme>-theme.qrc. Useful in QtDesigner, then later by the built app. Keeping the filesystem calls would still allow for manual adding of new themes by a designer. [0] https://github.com/qgis/Quantum-GIS/blob/master/src/core/qgsapplication.cpp#L347 >> It would be nice to have a little script in the repo that creates a >> thumbnail gallery of all the icons. +1 for this. Such a script could automatically push gallery updates to the github pages orphaned branch (gh-pages) via a repo hook. >> Also it might be nice to clean up the names a little - perhaps come up >> with a NounVerb.svg approach e.g. VectorEdit.svg VectorStopEdit.svg >> so that non programmers can make sense of our naming scheme (yes I >> know the current scheme is mainly my doing :-P). +1 from me. Best to have the names not associated with any Qt concepts, like 'Action'. Lastly, other items that could be in the qgis-graphics repo: * Historical imagery, i.e. all of the past splash screens, screen shots of past QGIS versions, etc. * All versions of the QGIS app icon, and any current working concepts for it. * SVG Symbols. While github should not be used as a CDN, a duplicate repo (@ hub.qgis.org?) could be used as a backend to serve SVG symbols directly to QGIS installs. Example: QGIS ships with basic set of SVG symbols. User clicks a 'Download more symbols' button and a web view of the generated image gallery of the qgis-graphics repo symbol section pops up, where the user can browse the symbols (same as gh-pages) and click on download links for groups of symbols (auto-zip archived), or individual symbols. Those links would actually point to the mirrored qgis-graphics repo somewhere on QGIS project servers. The links are processed by a QGIS slot that downloads them and installs in the user's default symbol location. Other users can send pull requests against that symbol section of the qgis-graphics github repo to have their designed symbols 'automatically' included in the browse-able symbols. Sorry for the long post. Regards, Larry
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer