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

[Werner Macho]

Hi!

Fully
+1
for every points ..

Notice: I personally don't like to split up things - like creating a new
repository .. but in this case it seems reasonable to me ..
Shouldn't it be possible with git to link the graphics repository into the
correct place in source code? Any git professionals here?

kind regards
Werner



On Wed, Jan 23, 2013 at 1: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
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130123/7d96e9ab/attachment.html>