<div dir="ltr">Hi !<div><br></div><div style>So I've been working a little bit about that "deprecated folder" idea.</div>It's not ready yet, but I have some questions since I'm not familiar at all with QgsProjectFileTransform nor with how SVG search paths work.<div>
<br><div style><a href="https://github.com/olivierdalang/Quantum-GIS/tree/SvgLibraryRetroCompatibility">https://github.com/olivierdalang/Quantum-GIS/tree/SvgLibraryRetroCompatibility</a></div><div style><br></div><div style>
<b>Here's what it does :</b></div><div style><br></div><div style>1. Installation</div><div style>It creates a new "svg_deprecated" folder containing all original 1.8's symbols (alongside the normal "svg" folder, right in the installation root)</div>
<div style><br></div><div style>2. Project file conversion</div><div style>In the QgsProjectFileTransform::transform1800to1900() method, it updates the svg paths.<br></div><div style>- if the path starts with a "/" (which seems to correspond to the svg folder path), it prepends "QGIS_PREFIX_PATH/svg_deprecated"</div>
<div style>- if not, it does nothing (since it's an absolute path)</div><div style><br></div><div style><br></div><div style><b>Questions :</b></div><div style><br></div><div style>A. Is it always right that a path starting with a "/" is a file inside the QGIS's svg folder ? (I never used SVGs search paths, if such a thing exists in 1.8)</div>
<div style>B. Is it okay to refer to the deprecated folder using an absolute path ( starting with QGIS_PREFIX_PATH ) ? I tried to prepend "/../svg_deprecated" instead, but with no success... (using absolute path has the major disadvantage of making the project file unportable). Any idea ? </div>
<div style>C. The file paths for SVGs in the print composer are absolute... So they still link to the 1.8 installation's svg folder. This works, but only until the user uninstalls 1.8... Is that OK ?</div><div style>
D. Are there other places where SVGs from the library can appear in QGIS 1.8's projects ? (I've thought of SvgMarker, SVGFill and as images in the print composer)</div>
<div style><br></div><div style>(E: is it better to already open a pull request for this kind of questions, even if the branch is not ready to merge ?)</div><div style><br></div><div style><br></div><div style>Thanks !</div>
<div style><br></div><div style><br></div><div style><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/15 Larry Shaffer <span dir="ltr"><<a href="mailto:larrys@dakotacarto.com" target="_blank">larrys@dakotacarto.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<br><br><div><div class="gmail_extra"><div class="im">On Wed, May 15, 2013 at 11:26 AM, John C. Tull <span dir="ltr"><<a href="mailto:jctull@gmail.com" target="_blank">jctull@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
<br>
On May 7, 2013, at 1:42 AM, Duarte Carreira <<a href="mailto:DCarreira@edia.pt" target="_blank">DCarreira@edia.pt</a>> wrote:<br>
<br>
> If we can get hold of the old symbology lib than that's fine by me. But please don't make us and others rebuild their entire organization's cartography just because you don't like the symbols.<br>
><br>
> Thanks,<br>
> Duarte<br>
<br>
An option to get the old symbols should suffice, right? Instructions on what needs to be done with these symbols for each platform might also be helpful.<br></blockquote><div><br></div></div><div>Well, even though I agree with the new changes, it will be a harsh situation for those who have used the deprecated ones in their projects. And, kind of rude (from the users standpoint) to force the change and require a manual rebuild of existing projects.<br>
<br></div><div>There are still some issues regarding the new symbol setup:<br><br></div><div>1) IMO, the deprecation of many symbols is fine, if they are moved to a 'deprecated' folder. Such a folder may or may not be part of the SVG search paths, but still in source and installed. Then, just like when you move or restructure a web site, create some path rewrite rules that will auto-update a <2.0 project and rewrite the deprecated SVG paths to the deprecated SVGs folder.<br>
<br></div><div>This could remove the deprecated SVGs from the selector interface, but not break existing projects. When user goes to work with the symbol, the correct path is visible, but they can only select new-style SVGs for which to update the symbol, unless they specifically browse to the deprecated folder and link to a deprecated one again.<br>
<br></div><div>I think such an approach will keep good karma with the user community.<br></div><div><br></div><div>2) Many of the new symbols are white as default. This is probably so they work well on top of a colored background when layered. However, this makes them very difficult to preview (especially on Mac). Either the widget view needs to have a medium gray background, or the default color for those SVGs should be gray (or maybe black, but gray would work better). This assumes that all those SVGs have color parameters that can just be changed later.<br>
<br></div><div>3) The new SVG backgrounds for labels do not yet support such 'layered' symbols. Currently only a single SVG can be used. There needs to be a decent selection of background SVGs for labels (e.g. road shields) that do not require layering. Layering backgrounds may not be a good fit for labeling in the future either, since single SVGs with drop shadows already slow labeling down.<br>
<br></div><div>Regards,<br><br></div><div>Larry<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
> -----Mensagem original-----<br>
> De: Tim Sutton [mailto:<a href="mailto:lists@linfiniti.com" target="_blank">lists@linfiniti.com</a>]<br>
> Enviada: segunda-feira, 6 de Maio de 2013 21:56<br>
> Para: Olivier Dalang<br>
> Cc: Nathan Woodrow; qgis-developer; Giovanni Manghi; Duarte Carreira<br>
> Assunto: Re: [Qgis-developer] many SVG symbols disappeared<br>
><br>
> Hi<br>
><br>
> On Mon, May 6, 2013 at 2:31 PM, Olivier Dalang <<a href="mailto:olivier.dalang@gmail.com" target="_blank">olivier.dalang@gmail.com</a>> wrote:<br>
>> I was asking that question on this thread :<br>
>><br>
>> <a href="http://osgeo-org.1560.x6.nabble.com/Ideas-on-the-SVG-symbols-library-t" target="_blank">http://osgeo-org.1560.x6.nabble.com/Ideas-on-the-SVG-symbols-library-t</a><br>
>> d5040508.html#a5046486<br>
>><br>
>> Maybe I didn't emphasize enough on the deletion of symbols...<br>
>><br>
>> IMO, the most elegant solution is to keep only the good-looking<br>
>> symbols so we provide a simple and consistent library, and then to<br>
>> provide a link on the website to download the unmodified 1.8 symbol<br>
>> library in case one needs to keep full backwards compatibility (it's<br>
>> quite easy to install : you just have to replace the SVG folder in your installation folder).<br>
>><br>
>> The whole pull request already breaks backwards compatibility with all<br>
>> other symbols, since by removing their background, the may become<br>
>> unreadable on most of the maps...<br>
>><br>
>> So if the priority is the keep old projects looking the same rather<br>
>> than having a clean and consistent library, the best is not to change<br>
>> the svg library at all.<br>
>><br>
>> (just as an illustration, do you really think it's pertinent to keep<br>
>> this in the library ? :<br>
>> <a href="https://www.dropbox.com/s/jj9e852r08w5ysp/north-arrow_10_with_map_laye" target="_blank">https://www.dropbox.com/s/jj9e852r08w5ysp/north-arrow_10_with_map_laye</a><br>
>> rs.png<br>
>> )<br>
>><br>
<br>
I use that symbol all the time! /sarcasm<br>
<br>
> Yeah that ain't pretty...<br>
><br>
> Personally I like Oliver's patch and I think we should clean up house for 2.0. Keeping compatibility is useful but most of my project files from 1.8 are already broken to some degree and I would prefer we do all the big changes in 2.0 and then become more conservative in subsequent 2.x releases.<br>
><br>
<br>
+1<br>
<br></div></div><div class="im">
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">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>
</div></blockquote></div><br></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>