<div dir="ltr">Hi!<div><br></div><div style>Fully </div><div style>+1</div><div style>for every points ..</div><div style><br></div><div style>Notice: I personally don't like to split up things - like creating a new repository .. but in this case it seems reasonable to me .. </div>
<div style>Shouldn't it be possible with git to link the graphics repository into the correct place in source code? Any git professionals here?</div><div style><br></div><div style>kind regards</div><div style>Werner</div>
<div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 23, 2013 at 1:10 AM, Larry Shaffer <span dir="ltr"><<a href="mailto:larrys@dakotacarto.com" target="_blank">larrys@dakotacarto.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi,<br><br></div>I am bringing this discussion back up, because some of us think it's important to address before the upcoming 2.0 release.<br>
<br></div>Here are my recommendations (in workflow order):<br>
<br></div><div>1) Create a new graphics repository at <a href="http://github.com" target="_blank">github.com</a>, e.g. named 'qgis-graphics'.<br><br>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 <a href="http://osgeo.org" target="_blank">osgeo.org</a> [0], but specific to QGIS. It should <br>

<br></div><div>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'.<br>

</div><div><br></div>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. <div>

<div><div><div><br></div><div>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.<br>

<br></div><div>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.<br>

<br></div><div>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.<br>

<br></div><div>Considerations:<br><br>* Maybe look into some funding for someone, like Robert, to work on 1) thru 4).<br><br>* 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).<br>

</div><div><br>[0] <a href="http://trac.osgeo.org/osgeo/browser/graphics" target="_blank">http://trac.osgeo.org/osgeo/browser/graphics</a><br>[1] <a href="https://github.com/qgis/Quantum-GIS/pull/398/files" target="_blank">https://github.com/qgis/Quantum-GIS/pull/398/files</a><br>

[2] <a href="http://robert.szczepanek.pl/icons.php" target="_blank">http://robert.szczepanek.pl/icons.php</a><br>[3] <a href="http://osgeo-org.1560.n6.nabble.com/SVG-Icons-instead-of-PNGs-td4991647.html" target="_blank">http://osgeo-org.1560.n6.nabble.com/SVG-Icons-instead-of-PNGs-td4991647.html</a><br>

[4] <a href="http://osgeo-org.1560.n6.nabble.com/Cast-your-vote-Default-icon-theme-for-QGIS-2-0-td4987107.html" target="_blank">http://osgeo-org.1560.n6.nabble.com/Cast-your-vote-Default-icon-theme-for-QGIS-2-0-td4987107.html</a><br>




<br></div><div>See also: <a href="http://hub.qgis.org/wiki/quantum-gis/Icons_20" target="_blank">http://hub.qgis.org/wiki/quantum-gis/Icons_20</a><br></div><div><br clear="all"><div class="gmail_extra"><div class="im"><div>
Regards,<br></div><div><br>Larry Shaffer<br>
Dakota Cartography<br>Black Hills, South Dakota</div>
<br><br></div><div><div class="h5"><div class="gmail_quote">On Mon, Jul 30, 2012 at 5:30 PM, Robert Szczepanek <span dir="ltr"><<a href="mailto:robert@szczepanek.pl" target="_blank">robert@szczepanek.pl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Hi,<br>
<br>
On 29.07.2012 00:06, Larry Shaffer wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In my own experimentation with Qt icon scaling, I have found scripting<br>
ImageMagick or Photoshop to do the up/down-scaling, with or without a<br>
bit of sharpening applied afterword, to produce better quality icons<br>
than the Qt scaling. It may be good enough quality to preclude<br>
re-creating your icons for the other sizes.<br>
</blockquote>
<br>
If the results are better, it can be simple solution.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Another option is to design icons with fewer details and higher<br>
contrast so that they still look OK when scaled (see MSSQL icon in<br>
Giovanni's QGIS example). I believe this would also address the issue<br>
of some icon groups looking too busy due to too much detail, example:<br>
the 'Add * Layer' icons of your set.<br>
</blockquote>
<br>
This is only matter of decision and use of simpler version, without "layer" sign. With bigger raster/vector/WMS/etc.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Having multiple size sets for icons means some naming conventions and<br>
coding to switch between the sets; whereas now, the code simply asks<br>
Qt to handle the scaling by setting a toolbar's icon size in one call<br>
(as an example). Another good reason to go with icons that can cope<br>
with Qt's scaling: no code changes.<br>
</blockquote>
<br>
Different folders could be solution if Qt's scaling won't work?<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Switching between size sets also means any third party icons (e.g.<br>
plugins), that don't provide multiple icon versions, will have their<br>
icons scaled. This would end up with users seeing different quality<br>
between core and plugin toolbars, though I don't know how much this<br>
can be avoided regardless of scaling issues.<br>
</blockquote>
<br>
This is very important argument in favour of one SVG file.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So, my vote here for your icon set would be to go with only the 24x24<br>
size, reduce the complexity of the most complex icons, increase<br>
overall contrast where needed, and add any 2.5 effects to make them<br>
pop a bit more (but not if such an effect causes the blurry scaling<br>
problem or poor quality to occur).<br>
</blockquote>
<br>
Agree.<span><font color="#888888"><br>
Robert<br>
</font></span></blockquote></div><br></div></div></div></div></div></div></div></div>
<br>_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
<br></blockquote></div><br></div>