Icon zooming for GUI

[Daniel S. Matthews]

I was looking at all the changes and new functions and realized that I
need to find some time to do a lot of new icons, however we seem to be
hitting a complexity limit that is undermining to purpose of having
icons, particularly when dealing with variants of a function (e.g.
file export/import). One obvious fix is to have larger icons, where
the scale is set in user preferences, or we could have the icons zoom
larger on roll-over. Another is to have have a single file I/O object
that then has access to the different plugins so that you select it's
I/O type from a dynamic list, this would then be reflected in the
instance's name. You could allow a lot of other plugins to be grouped
in the same way, e.g. transform, mesh modifier etc. The above methods
are not mutually exclusive either.

Any other ideas about how to deal with the issue?

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Daniel S. Matthews wrote:

> I was looking at all the changes and new functions and realized that I
> need to find some time to do a lot of new icons, however we seem to be
> hitting a complexity limit that is undermining to purpose of having
> icons, particularly when dealing with variants of a function (e.g.
> file export/import). One obvious fix is to have larger icons, where
> the scale is set in user preferences, or we could have the icons zoom
> larger on roll-over. Another is to have have a single file I/O object
> that then has access to the different plugins so that you select it's
> I/O type from a dynamic list, this would then be reflected in the
> instance's name. You could allow a lot of other plugins to be grouped
> in the same way, e.g. transform, mesh modifier etc. The above methods
> are not mutually exclusive either.
>
> Any other ideas about how to deal with the issue?
>  

This is technically doable by users today, using Gtk theming - not sure
if there are any good tools for it though ...

For the most part, I think sticking to categories of icons is fine,
since - as Joe often points out - users eventually opt for more screen
real-estate anyway.  For example, I can't see trying to create a
separate icon for each type of painter - a single general "painter" icon
seems fine to me.

Cheers,
Tim

--
Timothy M. Shead, K-3D founder
http://www.k-3d.org



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development