[Qgis-developer] Cast your vote: Default icon theme for QGIS 2.0

[Matthias Kuhn]

Hi,

On 01/24/2013 08:18 AM, Tim Sutton wrote:
> Hi
>
> On Wed, Jan 23, 2013 at 2:10 AM, Larry Shaffer <larrys at dakotacarto.com> wrote:
>> Hi,
>>
>> I am bringing this discussion back up, because some of us think it's
>> important to address before the upcoming 2.0 release.
>>
>> Here are my recommendations (in workflow order):
>>
>> 1) Create a new graphics repository at github.com, e.g. named
>> 'qgis-graphics'.
>>
>> It is important that a single repository exist where designers/developers
>> can find and work on SVG originals/components for creating new, or updating
>> existing, icons and graphics, without mucking about in the actual QGIS
>> source repository. This allows commit access to be specifically granted to
>> designers, etc. without granting access to the source code repo. This could
>> be similar to the one at osgeo.org [0], but specific to QGIS. It should
>>
>> This allows pull requests, like from olivierdalang [1], to also include the
>> base working documents (SVG) in a separate pull request to the graphics
>> repo, for use in future icon compositions, without having to store the
>> graphics source files in the source code repository (which could increase
>> download size significantly). IMO, the only graphics files in the source
>> code repo should be those that get installed with 'make install'.
>>
>> 2) Condense current icons/pixmaps used in QGIS from all themes into just the
>> default theme, with preference to vote-preferred GIS theme. Move the
>> discarded icons and themes to the graphics repo, for later reference.
>>
>> 3) Copy any relevant SVG/pixmap sources from OSGeo repo [0] and Robert
>> Szczepanek's source icon work (that may not be in current source code repo)
>> [2] to new qgis-graphics repository.
>>
>> 4) Try to convert ALL new default theme icons to SVG, which may mean
>> recreating many as vector art since the embedded-raster-in-SVG method
>> doesn't seem to work well now (causes ugly upscaling) [3]. It should be
>> possible to fix that issue in code, allowing for use of pixmaps-inside-SVG,
>> until they are converted to vector-based SVGs.
>>
>> 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.
>>
>> Considerations:
>>
>> * Maybe look into some funding for someone, like Robert, to work on 1) thru
>> 4).
>>
>> * It is also a good project for asking help from non-coding users who may
>> want to get involved as contributors. This would be after 1).
>>
>> [0] http://trac.osgeo.org/osgeo/browser/graphics
>> [1] https://github.com/qgis/Quantum-GIS/pull/398/files
>> [2] http://robert.szczepanek.pl/icons.php
>> [3]
>> http://osgeo-org.1560.n6.nabble.com/SVG-Icons-instead-of-PNGs-td4991647.html
>> [4]
>> http://osgeo-org.1560.n6.nabble.com/Cast-your-vote-Default-icon-theme-for-QGIS-2-0-td4987107.html
>>
>> See also: http://hub.qgis.org/wiki/quantum-gis/Icons_20
>>
> +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?
>
> It would be nice to have a little script in the repo that creates a
> thumbnail gallery of all the icons.
>
> 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).
>
> Regards
>
> Tim


+1 as well.

Concerning the naming scheme, OSGeo Graphics [1] state on their page 
that they follow the freedesktop standard [2]. Wouldn't it be nice to 
keep these things in line?
This would be hyphens instead of CamelCase but it looks like noun-verb 
as well ( Things like document-save etc., your examples: vector-edit.svg 
and vector-stop-edit.svg).

Regards,
Matthias

[1]: http://wiki.osgeo.org/wiki/OSGeo_Graphics 
<http://wiki.osgeo.org/wiki/OSGeo_Graphics>
[2]: 
http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
>
>
>> Regards,
>>
>> Larry Shaffer
>> Dakota Cartography
>> Black Hills, South Dakota
>>
>>
>> On Mon, Jul 30, 2012 at 5:30 PM, Robert Szczepanek <robert at szczepanek.pl>
>> wrote:
>>> Hi,
>>>
>>> On 29.07.2012 00:06, Larry Shaffer wrote:
>>>> In my own experimentation with Qt icon scaling, I have found scripting
>>>> ImageMagick or Photoshop to do the up/down-scaling, with or without a
>>>> bit of sharpening applied afterword, to produce better quality icons
>>>> than the Qt scaling. It may be good enough quality to preclude
>>>> re-creating your icons for the other sizes.
>>>
>>> If the results are better, it can be simple solution.
>>>
>>>> Another option is to design icons with fewer details and higher
>>>> contrast so that they still look OK when scaled (see MSSQL icon in
>>>> Giovanni's QGIS example). I believe this would also address the issue
>>>> of some icon groups looking too busy due to too much detail, example:
>>>> the 'Add * Layer' icons of your set.
>>>
>>> This is only matter of decision and use of simpler version, without
>>> "layer" sign. With bigger raster/vector/WMS/etc.
>>>
>>>> Having multiple size sets for icons means some naming conventions and
>>>> coding to switch between the sets; whereas now, the code simply asks
>>>> Qt to handle the scaling by setting a toolbar's icon size in one call
>>>> (as an example). Another good reason to go with icons that can cope
>>>> with Qt's scaling: no code changes.
>>>
>>> Different folders could be solution if Qt's scaling won't work?
>>>
>>>> Switching between size sets also means any third party icons (e.g.
>>>> plugins), that don't provide multiple icon versions, will have their
>>>> icons scaled. This would end up with users seeing different quality
>>>> between core and plugin toolbars, though I don't know how much this
>>>> can be avoided regardless of scaling issues.
>>>
>>> This is very important argument in favour of one SVG file.
>>>
>>>> So, my vote here for your icon set would be to go with only the 24x24
>>>> size, reduce the complexity of the most complex icons, increase
>>>> overall contrast where needed, and add any 2.5 effects to make them
>>>> pop a bit more (but not if such an effect causes the blurry scaling
>>>> problem or poor quality to occur).
>>>
>>> Agree.
>>> Robert
>>
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
> --
> Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
> ==============================================
> Please do not email me off-list with technical
> support questions. Using the lists will gain
> more exposure for your issues and the knowledge
> surrounding your issue will be shared with all.
>
> Visit http://linfiniti.com to find out about:
>   * QGIS programming and support services
>   * Mapserver and PostGIS based hosting plans
>   * FOSS Consulting Services
> Skype: timlinux
> Irc: timlinux on #qgis at freenode.net
> ==============================================
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer