[QGIS-Developer] SVG icons in QGIS

Sun Mar 28 17:02:35 PDT 2021

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-lists at 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 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 listQGIS-Developer at 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 at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
------------------------------------------------------------------------------------------

Tim Sutton
Visit http://kartoza.com to find out about open source:
 * Desktop GIS programming services
 * Geospatial web development
* GIS Training
* Consulting Services
Tim is a member of the QGIS Project Steering Committee
-------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20210329/6cd60cf8/attachment-0001.html>