Re: [QGIS-Developer] SVG icons in QGIS

[Tim Sutton]

Hi

Just to add to the discussion, see also the work we have been doing here:

https://plugins.qgis.org/styles/

I was rather hoping we could move over from shipping icons and styles with
QGIS (beyond the current set, which as Nyall says we cannot change for fear
of breaking things for pretty much everyone) and move to a situation where
we use the above site as a backend with search and install tools on the
QGIS desktop to find and install these resources. It takes an opposite
approach to the resources plugin, which as Richard mentions, addresses the
complex use case but bypasses humble users who just want to grab an
ambulance icon or whatever.

We already made an API for the styles repo above and my plan was to write a
QEP and hopefully crowd fund the QGIS desktop side bits. We would integrate
it into the settings -> style manager ui.

Also a side note: I think. we initially tested having the SVGs in a single
directory (back in the mists of time) but it was terribly slow in parsing
the directory.

Regards

Tim

On Mon, Jul 27, 2020 at 2:55 PM Jonathan Moules <
jonathan-li...@lightpear.com> wrote:

> Hi Richard,
>
> Thanks for the clarification. No rudeness parsed. :-) Apologies, I should
> be clearer.
>
> One of QGIS' biggest weaknesses IMHO is usability; a lot of progress has
> been made in this area, but it's an area that still needs work. The SVG
> icons are one such area, and while the Resources Plugin may technically
> provide a potential solution to this problem (i.e. just port over the
> Font-Awesome SVGs into the plugin), it:
>
> a) doesn't solve any of the issues I raised
>
> b) makes some of them worse. Now even more duplicate SVGs! The red cross
> one adds yet another cross for example, on top of the 5 identical ones
> already in the core, (and there's the simple marker too of course..)). And
> that's literally the first random one I picked.
>
> c) introduces new issues. i.e.: unhelpful metadata "This collection
> contains SVGs by GIS LAB" (sorry for picking on you, not the only ones
> ;-) ).
>
>
> > Please try Faunalia's 'Distance Measurement Styles'. One click and it
> will be available for you.
>
> Impressive. The Resources Plugin seems to me better suited to solving a
> different problem, though if I may provide some feedback: It took me a good
> minute or two to figure out how to access these styles once I'd downloaded
> them. (Found a bug too, but I'll open an issue for that :-) ).
>
>
> > But as Saber proposes: please create a QEP so there can be some
> centralized discussion.
>
> Is it the way to go? The blurb for QEPs says: "Generally smaller features
> do not require a QEP unless they can have large knock on effect." - looking
> at them, most of them are large chunks of dev work, and the rest are for
> project admin. Conversely, this is a couple tiny dev features (though I am
> making assumptions about the QGIS dev base... ;-) ), and a small chunk of
> admin work.
>
> Further thought (and an issue with QEPs in general): QEPs as Issues (which
> are Pull-based) are not very visible compared to the list (which is
> push-based). As in I'd expect barely anyone outside of project devs are
> likely to ever go trawling through the QEP issue tracker (i.e. I never
> have), whereas everyone on the list will get emails even if the chose not
> to read them.
>
> I mean it's easy enough to do; mostly just copy/past my previous email.
> But I see it reducing the audience for the conversation and not adding
> anything.
>
> Cheers,
>
> Jonathan
>
>
> On 2020-07-27 14:03, Richard Duivenvoorde wrote:
>
> Hi Jonathan,
>
> I do not want to sound rude, but I think you really underestimate the 
> possibilities and complexity of the icons and QGIS styling and styling 
> resources in general.
>
> About the 'Resource Sharing Plugin':
> - styling (of points) is never only about the little icon. styling and 
> symbols are complex beasts. If you google the plugins QEP, you will see that 
> it (also) started of as a 'simple todo' but ended up in current form
> - did you have a look: because there are a LOT of styling resources already: 
> simple ones (like mine with actually only some icons), but others giving you 
> the capabilities to show all dimension labels and arrows of your geometries, 
> and again others very specific for a certain working area: oil&gas icons, Red 
> Cross-map icons etc etc
>
> I'd be OK with cleaning up, but a good thing on the Resource Plugin is that 
> it fetches a (online, be it on github or on you webserver!) set of styling 
> resources: symbols, styles, icons, colors, whatever is possible. Please try 
> Faunalia's 'Distance Measurement Styles'. One click and it will be available 
> for you.
>
> About metadata and searching: cool, would also be nice if that could work for 
> Resources. Isn't there some kind of SVG-standard for this?
>
> About all in one directory: fine, or at least for the ones QGIS gives you 
> upon install (the 'App' folder). But I also like the way the Resource plug

Re: [QGIS-Developer] SVG icons in QGIS

[jrmorreale_ml]

Hi,

I'm digging this up as it doesn't seems that QGIS shows to the user the 
possibility to have user-defined tags and how to create them.  It means that 
most users are missing it.

To give more exposure to this feature, it would be great to ask the user if the 
SVG should be edited to add all the tags.

regards,
jean-roc
 
Le Mardi, Juillet 28, 2020 09:16 CEST, Raymond Nijssen  
a écrit: 
 
> 
> 
> 
> On 28-07-2020 02:44, Nyall Dawson wrote:
> > Oh, also they'd need to be "parameterised", so that users can set the
> > fill/stroke color, opacity and stroke width from within QGIS.
> 
> I've made some quick and dirty scripts in the past to add these tags to 
> sets of svg symbols. If needed I can help with it.
> 
> https://github.com/IFRCGo/IFRC-Icons/blob/master/OCHA_Icons_2018/scripts/convert_to_qgis.py
> 
> Raymond
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] SVG icons in QGIS

[Andreas Neumann]

And in the SVG param primer, you can see examples of adjustable text in
 elements (e.g. buttons, icons, etc.): 

https://www.w3.org/TR/SVGParamPrimer/#Examples 


Given that we already have the param mechanism in QGIS, it would fell
natural to extend it to text as well. 


And - if we really want it - I think there is a fair chance to get
Inkscape to implement SVG params as well. They also implemented some SVG
extensions that unfortunately didn't make it into the browser, because
the browser companies blocked them during the standardization process. 


It is one of the advantages of XML (and SVG in that respect), that you
can extend with your own extensions. 

Andreas 


On 2020-07-28 10:46, Andreas Neumann wrote:

Hi Régis, 

In general - you are right - but the problem with standards it that they are often ignored. Browser developer companies (like Google) basically ignore 80% of the W3C standards and just implement what they want. I was involved with SVG standardization a decade ago  - and I have to say - it was a big disappointment to see what the big companies did with standards - even if it were their own employees who worked on the standards documents. 

The SVG param specification is in "working draft" stage - it is from W3C, not an invention by QGIS - but in my opinion, it is much easier to use than the i18n section that you quote. And I don't think it is implemented in any browser or authoring system (like Inkscape, Illustrator, etc.) 

See https://www.w3.org/TR/SVGParam/#AdaptTextToUse 

Adapt text in an icon or button is exactly a use case in the SVG param specification (working draft). 

Andreas 

On 2020-07-28 10:15, Régis Haubourg wrote: 

Hi,  
I think we should better follow the standard for internationalizing instead of progressively making a proprietary format.  
See https://www.w3.org/TR/SVGTiny12/i18n.html 
Cheers! 

Le mar. 28 juil. 2020 à 09:57, Andreas Neumann  a écrit : 

Hi all, 

I am only loosely following this discussion. 

But about the internationalization: couldn't we use the same param - mechanism we already have for fill-color, stroke-color, opacity, etc. and extend it to the content of  elements? 

That would solve internationalization and would also be usefuly for dynamic text in icons anyway - there might be some use cases for this even without internationalization. 

Just an idea, 

Andreas 

On 2020-07-28 02:39, Nyall Dawson wrote: 
On Mon, 27 Jul 2020 at 21:57, Jonathan Moules
 wrote: 
Hi List,


The more I look at the current SVG icons, the more I'm thinking it
really needs some TLC (Tender Loving Care). As far as I can tell, icons
are categorised by the directory they're in, so if you want an icon to
appear in two categories, you put the icon in there twice... and so
that's just what has happened! I suspect the current set has simply
accreted over time. 
For reference: I'm totally in agreement that we need to improve the

DEFAULT set of svg files, and that the resource sharing plugin isn't
the best solution here. It's a great solution for some use cases, but
we need to improve the out-of-the-box experience in this regard and
that means extending the default set.

My thoughts:
* Move the svg's into a single directory. (Though would break any
current projects symbology using them I guess?) 
Yes -- we CAN'T do this. What we've got now has to stay, in its

current structure, and without renaming.

* Use a metadata file to categorise them, so you get a list of
categories as now and a single symbol can be in multiple categories. 
We could potentially add tags to the svg files themselves to add this

information.

* Add a search feature so the user can quickly find "museum" without
having to guess where it has been categorised. 
Big +1 to this. Especially if we also add search by tag support!


* Clean up the current symbols by removing duplicates. 
Again, we can't do this without risking breaking people's existing

projects (which is off-limits!)

* Add the font-awesome symbols (per my thread on the User List) to fill
in the gaps and flesh out the collection. As a bonus, it comes with
metadata for categories and search terms (YAML files).

* bonus - metadata is internationalised so "museo" (IT), "muzeu" (RO),
etc would also work for finding that museum.

Thoughts? 
Sounds good to me! To clarify -- are you volunteering to lead this effort?


Nyall

Cheers,
Jonathan

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://l

Re: [QGIS-Developer] SVG icons in QGIS

[Andreas Neumann]

Hi Régis, 


In general - you are right - but the problem with standards it that they
are often ignored. Browser developer companies (like Google) basically
ignore 80% of the W3C standards and just implement what they want. I was
involved with SVG standardization a decade ago  - and I have to say - it
was a big disappointment to see what the big companies did with
standards - even if it were their own employees who worked on the
standards documents. 


The SVG param specification is in "working draft" stage - it is from
W3C, not an invention by QGIS - but in my opinion, it is much easier to
use than the i18n section that you quote. And I don't think it is
implemented in any browser or authoring system (like Inkscape,
Illustrator, etc.) 

See https://www.w3.org/TR/SVGParam/#AdaptTextToUse 


Adapt text in an icon or button is exactly a use case in the SVG param
specification (working draft). 

Andreas 


On 2020-07-28 10:15, Régis Haubourg wrote:

Hi,  
I think we should better follow the standard for internationalizing instead of progressively making a proprietary format.  
See https://www.w3.org/TR/SVGTiny12/i18n.html 
Cheers! 

Le mar. 28 juil. 2020 à 09:57, Andreas Neumann  a écrit : 

Hi all, 

I am only loosely following this discussion. 

But about the internationalization: couldn't we use the same param - mechanism we already have for fill-color, stroke-color, opacity, etc. and extend it to the content of  elements? 

That would solve internationalization and would also be usefuly for dynamic text in icons anyway - there might be some use cases for this even without internationalization. 

Just an idea, 

Andreas 

On 2020-07-28 02:39, Nyall Dawson wrote: 
On Mon, 27 Jul 2020 at 21:57, Jonathan Moules
 wrote: 
Hi List,


The more I look at the current SVG icons, the more I'm thinking it
really needs some TLC (Tender Loving Care). As far as I can tell, icons
are categorised by the directory they're in, so if you want an icon to
appear in two categories, you put the icon in there twice... and so
that's just what has happened! I suspect the current set has simply
accreted over time. 
For reference: I'm totally in agreement that we need to improve the

DEFAULT set of svg files, and that the resource sharing plugin isn't
the best solution here. It's a great solution for some use cases, but
we need to improve the out-of-the-box experience in this regard and
that means extending the default set.

My thoughts:
* Move the svg's into a single directory. (Though would break any
current projects symbology using them I guess?) 
Yes -- we CAN'T do this. What we've got now has to stay, in its

current structure, and without renaming.

* Use a metadata file to categorise them, so you get a list of
categories as now and a single symbol can be in multiple categories. 
We could potentially add tags to the svg files themselves to add this

information.

* Add a search feature so the user can quickly find "museum" without
having to guess where it has been categorised. 
Big +1 to this. Especially if we also add search by tag support!


* Clean up the current symbols by removing duplicates. 
Again, we can't do this without risking breaking people's existing

projects (which is off-limits!)

* Add the font-awesome symbols (per my thread on the User List) to fill
in the gaps and flesh out the collection. As a bonus, it comes with
metadata for categories and search terms (YAML files).

* bonus - metadata is internationalised so "museo" (IT), "muzeu" (RO),
etc would also work for finding that museum.

Thoughts? 
Sounds good to me! To clarify -- are you volunteering to lead this effort?


Nyall

Cheers,
Jonathan

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] SVG icons in QGIS

[Régis Haubourg]

Hi,
I think we should better follow the standard for internationalizing instead
of progressively making a proprietary format.
See https://www.w3.org/TR/SVGTiny12/i18n.html
Cheers!

Le mar. 28 juil. 2020 à 09:57, Andreas Neumann  a
écrit :

> Hi all,
>
> I am only loosely following this discussion.
>
> But about the internationalization: couldn't we use the same param -
> mechanism we already have for fill-color, stroke-color, opacity, etc. and
> extend it to the content of  elements?
>
> That would solve internationalization and would also be usefuly for
> dynamic text in icons anyway - there might be some use cases for this even
> without internationalization.
>
> Just an idea,
>
> Andreas
>
> On 2020-07-28 02:39, Nyall Dawson wrote:
>
> On Mon, 27 Jul 2020 at 21:57, Jonathan Moules
>  wrote:
>
>
> Hi List,
>
> The more I look at the current SVG icons, the more I'm thinking it
> really needs some TLC (Tender Loving Care). As far as I can tell, icons
> are categorised by the directory they're in, so if you want an icon to
> appear in two categories, you put the icon in there twice... and so
> that's just what has happened! I suspect the current set has simply
> accreted over time.
>
>
> For reference: I'm totally in agreement that we need to improve the
> DEFAULT set of svg files, and that the resource sharing plugin isn't
> the best solution here. It's a great solution for some use cases, but
> we need to improve the out-of-the-box experience in this regard and
> that means extending the default set.
>
> My thoughts:
> * Move the svg's into a single directory. (Though would break any
> current projects symbology using them I guess?)
>
>
> Yes -- we CAN'T do this. What we've got now has to stay, in its
> current structure, and without renaming.
>
> * Use a metadata file to categorise them, so you get a list of
> categories as now and a single symbol can be in multiple categories.
>
>
> We could potentially add tags to the svg files themselves to add this
> information.
>
> * Add a search feature so the user can quickly find "museum" without
> having to guess where it has been categorised.
>
>
> Big +1 to this. Especially if we also add search by tag support!
>
> * Clean up the current symbols by removing duplicates.
>
>
> Again, we can't do this without risking breaking people's existing
> projects (which is off-limits!)
>
> * Add the font-awesome symbols (per my thread on the User List) to fill
> in the gaps and flesh out the collection. As a bonus, it comes with
> metadata for categories and search terms (YAML files).
>
> * bonus - metadata is internationalised so "museo" (IT), "muzeu" (RO),
> etc would also work for finding that museum.
>
> Thoughts?
>
>
> Sounds good to me! To clarify -- are you volunteering to lead this effort?
>
> Nyall
>
>
> Cheers,
> Jonathan
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] SVG icons in QGIS

[Andreas Neumann]

Hi all, 

I am only loosely following this discussion. 


But about the internationalization: couldn't we use the same param -
mechanism we already have for fill-color, stroke-color, opacity, etc.
and extend it to the content of  elements? 


That would solve internationalization and would also be usefuly for
dynamic text in icons anyway - there might be some use cases for this
even without internationalization. 

Just an idea, 

Andreas 


On 2020-07-28 02:39, Nyall Dawson wrote:


On Mon, 27 Jul 2020 at 21:57, Jonathan Moules
 wrote: 


Hi List,

The more I look at the current SVG icons, the more I'm thinking it
really needs some TLC (Tender Loving Care). As far as I can tell, icons
are categorised by the directory they're in, so if you want an icon to
appear in two categories, you put the icon in there twice... and so
that's just what has happened! I suspect the current set has simply
accreted over time.


For reference: I'm totally in agreement that we need to improve the
DEFAULT set of svg files, and that the resource sharing plugin isn't
the best solution here. It's a great solution for some use cases, but
we need to improve the out-of-the-box experience in this regard and
that means extending the default set.


My thoughts:
* Move the svg's into a single directory. (Though would break any
current projects symbology using them I guess?)


Yes -- we CAN'T do this. What we've got now has to stay, in its
current structure, and without renaming.


* Use a metadata file to categorise them, so you get a list of
categories as now and a single symbol can be in multiple categories.


We could potentially add tags to the svg files themselves to add this
information.


* Add a search feature so the user can quickly find "museum" without
having to guess where it has been categorised.


Big +1 to this. Especially if we also add search by tag support!


* Clean up the current symbols by removing duplicates.


Again, we can't do this without risking breaking people's existing
projects (which is off-limits!)


* Add the font-awesome symbols (per my thread on the User List) to fill
in the gaps and flesh out the collection. As a bonus, it comes with
metadata for categories and search terms (YAML files).

* bonus - metadata is internationalised so "museo" (IT), "muzeu" (RO),
etc would also work for finding that museum.

Thoughts?


Sounds good to me! To clarify -- are you volunteering to lead this effort?

Nyall


Cheers,
Jonathan

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] SVG icons in QGIS

[Raymond Nijssen]

On 28-07-2020 02:44, Nyall Dawson wrote:

Oh, also they'd need to be "parameterised", so that users can set the
fill/stroke color, opacity and stroke width from within QGIS.


I've made some quick and dirty scripts in the past to add these tags to 
sets of svg symbols. If needed I can help with it.


https://github.com/IFRCGo/IFRC-Icons/blob/master/OCHA_Icons_2018/scripts/convert_to_qgis.py

Raymond
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] SVG icons in QGIS

[Nyall Dawson]

On Tue, 28 Jul 2020 at 10:39, Nyall Dawson  wrote:
>
> On Mon, 27 Jul 2020 at 21:57, Jonathan Moules
>  wrote:
> >
> > Hi List,
> >
> > The more I look at the current SVG icons, the more I'm thinking it
> > really needs some TLC (Tender Loving Care). As far as I can tell, icons
> > are categorised by the directory they're in, so if you want an icon to
> > appear in two categories, you put the icon in there twice... and so
> > that's just what has happened! I suspect the current set has simply
> > accreted over time.
>
> For reference: I'm totally in agreement that we need to improve the
> DEFAULT set of svg files, and that the resource sharing plugin isn't
> the best solution here. It's a great solution for some use cases, but
> we need to improve the out-of-the-box experience in this regard and
> that means extending the default set.
>
> > My thoughts:
> > * Move the svg's into a single directory. (Though would break any
> > current projects symbology using them I guess?)
>
> Yes -- we CAN'T do this. What we've got now has to stay, in its
> current structure, and without renaming.
>
> > * Use a metadata file to categorise them, so you get a list of
> > categories as now and a single symbol can be in multiple categories.
>
> We could potentially add tags to the svg files themselves to add this
> information.
>
> > * Add a search feature so the user can quickly find "museum" without
> > having to guess where it has been categorised.
>
> Big +1 to this. Especially if we also add search by tag support!
>
> > * Clean up the current symbols by removing duplicates.
>
> Again, we can't do this without risking breaking people's existing
> projects (which is off-limits!)
>
> > * Add the font-awesome symbols (per my thread on the User List) to fill
> > in the gaps and flesh out the collection. As a bonus, it comes with
> > metadata for categories and search terms (YAML files).
> >
> > * bonus - metadata is internationalised so "museo" (IT), "muzeu" (RO),
> > etc would also work for finding that museum.
> >
> > Thoughts?

Oh, also they'd need to be "parameterised", so that users can set the
fill/stroke color, opacity and stroke width from within QGIS.



>
> Sounds good to me! To clarify -- are you volunteering to lead this effort?
>
> Nyall
>
> >
> > Cheers,
> > Jonathan
> >
> >
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] SVG icons in QGIS

[Nyall Dawson]

On Mon, 27 Jul 2020 at 21:57, Jonathan Moules
 wrote:
>
> Hi List,
>
> The more I look at the current SVG icons, the more I'm thinking it
> really needs some TLC (Tender Loving Care). As far as I can tell, icons
> are categorised by the directory they're in, so if you want an icon to
> appear in two categories, you put the icon in there twice... and so
> that's just what has happened! I suspect the current set has simply
> accreted over time.

For reference: I'm totally in agreement that we need to improve the
DEFAULT set of svg files, and that the resource sharing plugin isn't
the best solution here. It's a great solution for some use cases, but
we need to improve the out-of-the-box experience in this regard and
that means extending the default set.

> My thoughts:
> * Move the svg's into a single directory. (Though would break any
> current projects symbology using them I guess?)

Yes -- we CAN'T do this. What we've got now has to stay, in its
current structure, and without renaming.

> * Use a metadata file to categorise them, so you get a list of
> categories as now and a single symbol can be in multiple categories.

We could potentially add tags to the svg files themselves to add this
information.

> * Add a search feature so the user can quickly find "museum" without
> having to guess where it has been categorised.

Big +1 to this. Especially if we also add search by tag support!

> * Clean up the current symbols by removing duplicates.

Again, we can't do this without risking breaking people's existing
projects (which is off-limits!)

> * Add the font-awesome symbols (per my thread on the User List) to fill
> in the gaps and flesh out the collection. As a bonus, it comes with
> metadata for categories and search terms (YAML files).
>
> * bonus - metadata is internationalised so "museo" (IT), "muzeu" (RO),
> etc would also work for finding that museum.
>
> Thoughts?

Sounds good to me! To clarify -- are you volunteering to lead this effort?

Nyall

>
> Cheers,
> Jonathan
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] SVG icons in QGIS

[Jonathan Moules]

Hi Richard,

Thanks for the clarification. No rudeness parsed. :-) Apologies, I 
should be clearer.


One of QGIS' biggest weaknesses IMHO is usability; a lot of progress has 
been made in this area, but it's an area that still needs work. The SVG 
icons are one such area, and while the Resources Plugin may technically 
provide a potential solution to this problem (i.e. just port over the 
Font-Awesome SVGs into the plugin), it:


a) doesn't solve any of the issues I raised

b) makes some of them worse. Now even more duplicate SVGs! The red cross 
one adds yet another cross for example, on top of the 5 identical ones 
already in the core, (and there's the simple marker too of course..)). 
And that's literally the first random one I picked.


c) introduces new issues. i.e.: unhelpful metadata "This collection 
contains SVGs by GIS LAB" (sorry for picking on you, not the only ones 
;-) ).



> Please try Faunalia's 'Distance Measurement Styles'. One click and it 
will be available for you.


Impressive. The Resources Plugin seems to me better suited to solving a 
different problem, though if I may provide some feedback: It took me a 
good minute or two to figure out how to access these styles once I'd 
downloaded them. (Found a bug too, but I'll open an issue for that :-) ).



> But as Saber proposes: please create a QEP so there can be some 
centralized discussion.


Is it the way to go? The blurb for QEPs says: "Generally smaller 
features do not require a QEP unless they can have large knock on 
effect." - looking at them, most of them are large chunks of dev work, 
and the rest are for project admin. Conversely, this is a couple tiny 
dev features (though I am making assumptions about the QGIS dev base... 
;-) ), and a small chunk of admin work.


Further thought (and an issue with QEPs in general): QEPs as Issues 
(which are Pull-based) are not very visible compared to the list (which 
is push-based). As in I'd expect barely anyone outside of project devs 
are likely to ever go trawling through the QEP issue tracker (i.e. I 
never have), whereas everyone on the list will get emails even if the 
chose not to read them.


I mean it's easy enough to do; mostly just copy/past my previous email. 
But I see it reducing the audience for the conversation and not adding 
anything.


Cheers,

Jonathan


On 2020-07-27 14:03, Richard Duivenvoorde wrote:

Hi Jonathan,

I do not want to sound rude, but I think you really underestimate the 
possibilities and complexity of the icons and QGIS styling and styling 
resources in general.

About the 'Resource Sharing Plugin':
- styling (of points) is never only about the little icon. styling and symbols 
are complex beasts. If you google the plugins QEP, you will see that it (also) 
started of as a 'simple todo' but ended up in current form
- did you have a look: because there are a LOT of styling resources already: simple 
ones (like mine with actually only some icons), but others giving you the 
capabilities to show all dimension labels and arrows of your geometries, and again 
others very specific for a certain working area: oil&gas icons, Red Cross-map 
icons etc etc

I'd be OK with cleaning up, but a good thing on the Resource Plugin is that it 
fetches a (online, be it on github or on you webserver!) set of styling 
resources: symbols, styles, icons, colors, whatever is possible. Please try 
Faunalia's 'Distance Measurement Styles'. One click and it will be available 
for you.

About metadata and searching: cool, would also be nice if that could work for 
Resources. Isn't there some kind of SVG-standard for this?

About all in one directory: fine, or at least for the ones QGIS gives you upon 
install (the 'App' folder). But I also like the way the Resource plugin orders 
them in folders (see screenshot).

But as Saber proposes: please create a QEP so there can be some centralized 
discussion.

Regards,

Richard Duivenvoorde



On 7/27/20 1:42 PM, Jonathan Moules wrote:

Hi List,

The more I look at the current SVG icons, the more I'm thinking it really needs 
some TLC (Tender Loving Care). As far as I can tell, icons are categorised by 
the directory they're in, so if you want an icon to appear in two categories, 
you put the icon in there twice... and so that's just what has happened! I 
suspect the current set has simply accreted over time.

Examples of weirdnesses:
* The "food" and "entertainment" categories are basically identical, but have 
different icons for the same thing.
* There are at least 7 near-identical aeroplane icons(!)
* There's cycle parking and cycle locking, but no cycle? No car (that's under "gpsicons") 
but two taxis? Oh, and 5 (five!) aeroplanes to choose from, and multiple types of train. And that's 
just "transport".
* "Shopping" has a hammer and a pawprint in it... well, I mean, you can buy 
those things sure, but that seems like a rather odd place to put them.
* "landmark" seems to basically be a subset of "religion", with a museum and a 

Re: [QGIS-Developer] SVG icons in QGIS

[Richard Duivenvoorde]

Hi Jonathan,

I do not want to sound rude, but I think you really underestimate the 
possibilities and complexity of the icons and QGIS styling and styling 
resources in general.

About the 'Resource Sharing Plugin':
- styling (of points) is never only about the little icon. styling and symbols 
are complex beasts. If you google the plugins QEP, you will see that it (also) 
started of as a 'simple todo' but ended up in current form
- did you have a look: because there are a LOT of styling resources already: 
simple ones (like mine with actually only some icons), but others giving you 
the capabilities to show all dimension labels and arrows of your geometries, 
and again others very specific for a certain working area: oil&gas icons, Red 
Cross-map icons etc etc

I'd be OK with cleaning up, but a good thing on the Resource Plugin is that it 
fetches a (online, be it on github or on you webserver!) set of styling 
resources: symbols, styles, icons, colors, whatever is possible. Please try 
Faunalia's 'Distance Measurement Styles'. One click and it will be available 
for you.

About metadata and searching: cool, would also be nice if that could work for 
Resources. Isn't there some kind of SVG-standard for this?

About all in one directory: fine, or at least for the ones QGIS gives you upon 
install (the 'App' folder). But I also like the way the Resource plugin orders 
them in folders (see screenshot).

But as Saber proposes: please create a QEP so there can be some centralized 
discussion.

Regards,

Richard Duivenvoorde



On 7/27/20 1:42 PM, Jonathan Moules wrote:
> Hi List,
> 
> The more I look at the current SVG icons, the more I'm thinking it really 
> needs some TLC (Tender Loving Care). As far as I can tell, icons are 
> categorised by the directory they're in, so if you want an icon to appear in 
> two categories, you put the icon in there twice... and so that's just what 
> has happened! I suspect the current set has simply accreted over time.
> 
> Examples of weirdnesses:
> * The "food" and "entertainment" categories are basically identical, but have 
> different icons for the same thing.
> * There are at least 7 near-identical aeroplane icons(!)
> * There's cycle parking and cycle locking, but no cycle? No car (that's under 
> "gpsicons") but two taxis? Oh, and 5 (five!) aeroplanes to choose from, and 
> multiple types of train. And that's just "transport".
> * "Shopping" has a hammer and a pawprint in it... well, I mean, you can buy 
> those things sure, but that seems like a rather odd place to put them.
> * "landmark" seems to basically be a subset of "religion", with a museum and 
> a weird icon for a "school" thrown in for good measure.
> 
> I'm sure there are many more.
> 
> Given the importance of a good symbol library for cartography, this seems 
> like a fairly significant issue, but fortunately it's pretty "easy" to fix 
> (compared to writing a data processing algorithm anyway ;-) ).
> 
> My thoughts:
> * Move the svg's into a single directory. (Though would break any current 
> projects symbology using them I guess?)
> * Use a metadata file to categorise them, so you get a list of categories as 
> now and a single symbol can be in multiple categories.
> * Add a search feature so the user can quickly find "museum" without having 
> to guess where it has been categorised.
> * Clean up the current symbols by removing duplicates.
> * Add the font-awesome symbols (per my thread on the User List) to fill in 
> the gaps and flesh out the collection. As a bonus, it comes with metadata for 
> categories and search terms (YAML files).
> 
> * bonus - metadata is internationalised so "museo" (IT), "muzeu" (RO), etc 
> would also work for finding that museum.
> 
> Thoughts?
> 
> Cheers,
> Jonathan
> 
> 
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] SVG icons in QGIS

[Saber Razmjooei]

Hi Jonathan,

If you'd like to work on it and make it happen, probably the best place
to start is opening an issue in the QGIS Enhancement Proposal:
https://github.com/qgis/QGIS-Enhancement-Proposals/issues

And post the link to the dev list, so that all the ideas will be collected
there and give you a clear path forward.

Kind regards
Saber

On Mon, 27 Jul 2020 at 12:57, Jonathan Moules 
wrote:

> Hi List,
>
> The more I look at the current SVG icons, the more I'm thinking it
> really needs some TLC (Tender Loving Care). As far as I can tell, icons
> are categorised by the directory they're in, so if you want an icon to
> appear in two categories, you put the icon in there twice... and so
> that's just what has happened! I suspect the current set has simply
> accreted over time.
>
> Examples of weirdnesses:
> * The "food" and "entertainment" categories are basically identical, but
> have different icons for the same thing.
> * There are at least 7 near-identical aeroplane icons(!)
> * There's cycle parking and cycle locking, but no cycle? No car (that's
> under "gpsicons") but two taxis? Oh, and 5 (five!) aeroplanes to choose
> from, and multiple types of train. And that's just "transport".
> * "Shopping" has a hammer and a pawprint in it... well, I mean, you can
> buy those things sure, but that seems like a rather odd place to put them.
> * "landmark" seems to basically be a subset of "religion", with a museum
> and a weird icon for a "school" thrown in for good measure.
>
> I'm sure there are many more.
>
> Given the importance of a good symbol library for cartography, this
> seems like a fairly significant issue, but fortunately it's pretty
> "easy" to fix (compared to writing a data processing algorithm anyway ;-)
> ).
>
> My thoughts:
> * Move the svg's into a single directory. (Though would break any
> current projects symbology using them I guess?)
> * Use a metadata file to categorise them, so you get a list of
> categories as now and a single symbol can be in multiple categories.
> * Add a search feature so the user can quickly find "museum" without
> having to guess where it has been categorised.
> * Clean up the current symbols by removing duplicates.
> * Add the font-awesome symbols (per my thread on the User List) to fill
> in the gaps and flesh out the collection. As a bonus, it comes with
> metadata for categories and search terms (YAML files).
>
> * bonus - metadata is internationalised so "museo" (IT), "muzeu" (RO),
> etc would also work for finding that museum.
>
> Thoughts?
>
> Cheers,
> Jonathan
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer



-- 
Saber Razmjooei
www.lutraconsulting.co.uk
+44 (0)7568 129733
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] SVG icons in QGIS

[Jonathan Moules]

Hi List,

The more I look at the current SVG icons, the more I'm thinking it 
really needs some TLC (Tender Loving Care). As far as I can tell, icons 
are categorised by the directory they're in, so if you want an icon to 
appear in two categories, you put the icon in there twice... and so 
that's just what has happened! I suspect the current set has simply 
accreted over time.


Examples of weirdnesses:
* The "food" and "entertainment" categories are basically identical, but 
have different icons for the same thing.

* There are at least 7 near-identical aeroplane icons(!)
* There's cycle parking and cycle locking, but no cycle? No car (that's 
under "gpsicons") but two taxis? Oh, and 5 (five!) aeroplanes to choose 
from, and multiple types of train. And that's just "transport".
* "Shopping" has a hammer and a pawprint in it... well, I mean, you can 
buy those things sure, but that seems like a rather odd place to put them.
* "landmark" seems to basically be a subset of "religion", with a museum 
and a weird icon for a "school" thrown in for good measure.


I'm sure there are many more.

Given the importance of a good symbol library for cartography, this 
seems like a fairly significant issue, but fortunately it's pretty 
"easy" to fix (compared to writing a data processing algorithm anyway ;-) ).


My thoughts:
* Move the svg's into a single directory. (Though would break any 
current projects symbology using them I guess?)
* Use a metadata file to categorise them, so you get a list of 
categories as now and a single symbol can be in multiple categories.
* Add a search feature so the user can quickly find "museum" without 
having to guess where it has been categorised.

* Clean up the current symbols by removing duplicates.
* Add the font-awesome symbols (per my thread on the User List) to fill 
in the gaps and flesh out the collection. As a bonus, it comes with 
metadata for categories and search terms (YAML files).


* bonus - metadata is internationalised so "museo" (IT), "muzeu" (RO), 
etc would also work for finding that museum.


Thoughts?

Cheers,
Jonathan


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer