[Qgis-user] Iconset from Google

[Paolo Cavallini]

https://github.com/google/material-design-icons/releases/tag/1.0.0

agreed. why not adding them to our standard ìcon set?
all the best.

[Andreas Neumann]

Hi,

I'd be against adding a lot of SVGs to the standard installation. Too
many files slow down QGIS. People should selectively install only the
icons they really need.

Didn't we have a project of a common icon repository where users could
contribute/checkout tagged icons, specific to certain needs (e.g.
geology icons, landmarks, geomorphology icons, etc.)? What happened to
this project? This would make much more sense rather than delivering
hundreds/thousands of icons by default where users only need 5-10 % of
the shipped icons.

Andreas

Post by Paolo Cavallini

https://github.com/google/material-design-icons/releases/tag/1.0.0

agreed. why not adding them to our standard ìcon set?
all the best.

[Paolo Cavallini]

I'd be against adding a lot of SVGs to the standard installation. Too many files slow
down QGIS. People should selectively install only the icons they really need.
Didn't we have a project of a common icon repository where users could
contribute/checkout tagged icons, specific to certain needs (e.g. geology icons,
landmarks, geomorphology icons, etc.)? What happened to this project? This would make
much more sense rather than delivering hundreds/thousands of icons by default where
users only need 5-10 % of the shipped icons.

Agreed fully. Unfortunately the project is still unfinished. IMHO (I know, I'm
repeating myself) it would be important to have it in production.
As a side not, I think we should also do something to speed up the loading of many
symbols: as QGIS is being picked up for serious work, it is rather normal for users
to build up huge collections of symbols.
All the best.

[Martin Dobias]

Hi Paolo

Post by Paolo Cavallini

I'd be against adding a lot of SVGs to the standard installation. Too many files slow
down QGIS. People should selectively install only the icons they really need.
Didn't we have a project of a common icon repository where users could
contribute/checkout tagged icons, specific to certain needs (e.g. geology icons,
landmarks, geomorphology icons, etc.)? What happened to this project? This would make
much more sense rather than delivering hundreds/thousands of icons by default where
users only need 5-10 % of the shipped icons.

Agreed fully. Unfortunately the project is still unfinished. IMHO (I know, I'm
repeating myself) it would be important to have it in production.
As a side not, I think we should also do something to speed up the loading of many
symbols: as QGIS is being picked up for serious work, it is rather normal for users
to build up huge collections of symbols.

I remember that Arun's summer of code project (2012 I think) was meant
to improve the situation. Are there still problems with slow loading
of symbols? Or are we talking just about loading of SVGs? (that should
have been improved too)

Cheers
Martin

[kimaidou]

Hi,

I think we could use the same feature as in processing for sharing scripts
and models. It is based on a git repository, and works quite well. It would
be sraitforward for devs to add icons, and users would be able to choose
which icon set they want to download and then upgrade.

Regards
Michael

Post by Martin Dobias
Hi Paolo

Post by Paolo Cavallini

Post by Andreas Neumann
I'd be against adding a lot of SVGs to the standard installation. Too

many files slow

Post by Paolo Cavallini

Post by Andreas Neumann
down QGIS. People should selectively install only the icons they really

need.

Post by Paolo Cavallini

Post by Andreas Neumann
Didn't we have a project of a common icon repository where users could
contribute/checkout tagged icons, specific to certain needs (e.g.

geology icons,

Post by Paolo Cavallini

Post by Andreas Neumann
landmarks, geomorphology icons, etc.)? What happened to this project?

This would make

Post by Paolo Cavallini

Post by Andreas Neumann
much more sense rather than delivering hundreds/thousands of icons by

default where

Post by Paolo Cavallini

Post by Andreas Neumann
users only need 5-10 % of the shipped icons.

Agreed fully. Unfortunately the project is still unfinished. IMHO (I

know, I'm

Post by Paolo Cavallini
repeating myself) it would be important to have it in production.
As a side not, I think we should also do something to speed up the

loading of many

Post by Paolo Cavallini
symbols: as QGIS is being picked up for serious work, it is rather

normal for users

Post by Paolo Cavallini
to build up huge collections of symbols.

I remember that Arun's summer of code project (2012 I think) was meant
to improve the situation. Are there still problems with slow loading
of symbols? Or are we talking just about loading of SVGs? (that should
have been improved too)
Cheers
Martin
_______________________________________________
Qgis-developer mailing list
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Paolo Cavallini]

Hi,
I think we could use the same feature as in processing for sharing scripts and
models. It is based on a git repository, and works quite well. It would be
sraitforward for devs to add icons, and users would be able to choose which icon set
they want to download and then upgrade.

Hi Michael,
sounds interesting, as it avoids entirely the complexity of a web-based application,
and could be implemented soon, with minimal effort. This holds true for symbols and
styles as well.
Any comment? Any taker?
All the best.

[Alexander Bruy]

But we already have core implementation for this (I know, it is not merged
and also require server-side app). Maybe we should compare this two ways
and decide which one offers more functionality and will be more usable for
large symbol collections.

If I'm not wrong, core functionality offers tags, groups and some other nice
features. As reasult one can create complex search criteria. In other hand
solution available in Processing is very simple (AFAIK it was developed as
temporary solution until core functionality is not merged).

Just my 2c.

Post by Paolo Cavallini

Hi,
I think we could use the same feature as in processing for sharing scripts and
models. It is based on a git repository, and works quite well. It would be
sraitforward for devs to add icons, and users would be able to choose which icon set
they want to download and then upgrade.

Hi Michael,
sounds interesting, as it avoids entirely the complexity of a web-based application,
and could be implemented soon, with minimal effort. This holds true for symbols and
styles as well.
Any comment? Any taker?
All the best.
--
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
_______________________________________________
Qgis-developer mailing list
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Alessandro Pasotti]

Post by Paolo Cavallini

Hi,
I think we could use the same feature as in processing for sharing scripts and
models. It is based on a git repository, and works quite well. It would be
sraitforward for devs to add icons, and users would be able to choose which icon set
they want to download and then upgrade.

Hi Michael,
sounds interesting, as it avoids entirely the complexity of a web-based application,
and could be implemented soon, with minimal effort. This holds true for symbols and
styles as well.
Any comment? Any taker?
All the best.

Hi,

this topic has been addressed several times during the last few years,
the current situation is that a Django app skeleton for a symbology
and styles is already available from a GSOC work at
https://github.com/qgis/QGIS-Django/tree/gsoc_remote/qgis-app/symbols.

Unfortunately, after having examined the code during the HF in Wien we
decided that it was not production ready, and we have no time and
resources to improve the code. A rough estimate of the time required
to improve/complete the app and test/deploy it is 7 working days (for
the symbology application only).

But this would be only part of the development since we still would
require (in any case) the QGIS desktop integration part.

That said, I'm not against using a github based solution, even if I
don't generally like the idea that we depend more and more on external
sources.

An argument in favour of the Django app is that it would probably
allow for a tighter integration with the website, exactly like the
plugin website does.

I don't know anything about the amount of time/resource needed to
complete the github-based solutions though.

[Alexander Bruy]

I remember Nathan said that desktop part is in good shape and can be easily
merged. But maybe with latest API breaks situation changed.

Post by Alessandro Pasotti

Post by Paolo Cavallini

Hi,
I think we could use the same feature as in processing for sharing scripts and
models. It is based on a git repository, and works quite well. It would be
sraitforward for devs to add icons, and users would be able to choose which icon set
they want to download and then upgrade.

Hi Michael,
sounds interesting, as it avoids entirely the complexity of a web-based application,
and could be implemented soon, with minimal effort. This holds true for symbols and
styles as well.
Any comment? Any taker?
All the best.

Hi,
this topic has been addressed several times during the last few years,
the current situation is that a Django app skeleton for a symbology
and styles is already available from a GSOC work at
https://github.com/qgis/QGIS-Django/tree/gsoc_remote/qgis-app/symbols.
Unfortunately, after having examined the code during the HF in Wien we
decided that it was not production ready, and we have no time and
resources to improve the code. A rough estimate of the time required
to improve/complete the app and test/deploy it is 7 working days (for
the symbology application only).
But this would be only part of the development since we still would
require (in any case) the QGIS desktop integration part.
That said, I'm not against using a github based solution, even if I
don't generally like the idea that we depend more and more on external
sources.
An argument in favour of the Django app is that it would probably
allow for a tighter integration with the website, exactly like the
plugin website does.
I don't know anything about the amount of time/resource needed to
complete the github-based solutions though.
--
Alessandro Pasotti
w3: www.itopen.it
_______________________________________________
Qgis-developer mailing list
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Paolo Cavallini]

Post by Alexander Bruy
I remember Nathan said that desktop part is in good shape and can be easily
merged. But maybe with latest API breaks situation changed.

IMVHO we need this function a lot, and we need to be realistic: of course a fully
integrated solution, entirely under our control is by far preferable, but if nobody i
going to implement it anytime soon, a temporary solution would be good, in order to
start building our symbol collection, that can be migrated to the Great Final
Solution when ready.
All the best.