[Graphics] Re: new gis theme and common repository

[Robert Szczepanek]

Anita Graser pisze:
> All resolutions would be? 16x16 up to 64x64?

Depending on needs. We must just keep in mind that 64x64 icons sould be
possible to scale to 16x16. So some known problems must be avoided [1].
The question is how to name SVG file when two sources will be available.
icon-name.svg [from 16 to 32px]
icon-name.svg [48 to 64]

We have 16, 22(24), 32, 48, 64. Is this OK?
Simple solution can be source file in rendered folder. We make copies of
source file but all files are on its place.
Options:
- suffix for scalable files (but how? one size, range?)
- subfolders for scalable (nonsens)

>> Tango uses in its releases:
>> 16x16/actions/address-book-new.png
>> 22x22/actions/address-book-new.png
>> 32x32/actions/address-book-new.png
>> scalable/actions/addrress-book-new.svg
> 
> I think this would be a good solution. Developers of GIS software can
> easily check out the icon sizes and file types they need.
> So we'll have one SVG file per icon. How will we organize that? If I'm
> informed correctly, you're now working with only one master SVG file per
> icon size?

Yes, but this is good one-person design.
I think SVG template should include action layers. This way will be easy
to render png and to coordinate work. Final SVG will contain only used
layers. Or maybe layer-visibility-off is enough? To check...from svg
auto-parsing point of view.
Do we have other re-usable graphical elements for template?

> In QGIS project we're now working with the wiki solution for our 64x64
> property dialog icons. [http://www.qgis.org/wiki/Icons_2.0]
> I'm fine with trac, though I lack experience with that system.

Not only you :)
As I understand. Yo need icon.
-> request for icon in trac - new ticket
-> if someone wants to draw, can become owner of the ticket
-> owner writes info to our list ... procedure ...
-> icon is ready
-> closing ticket

Or the same just with list (without trac), but then we won know what is
todo at the moment.


>>> I would prefer mailing list for discussion at the moment, but if there
>>> are arguments for wiki discussion, we can do it other way.
>>
>> I'd say we discuss here (and in chat if needed) and write down
>> conclusions on the wiki for future reference
> 
> Good. So we can now start to create our to-do list and collect ideas for
> metaphors?

Yes.
to-do at trac
metaphors at list and wiki

Robert

[1] http://developer.gnome.org/projects/gup/hig/1.0/icons.html#icon_problems