stock icons (repost)
- From: Bill Haneman <bill haneman sun com>
- To: gtk-devel-list gnome org
- Subject: stock icons (repost)
- Date: 06 Jan 2003 17:51:37 +0000
I have _no clue_ what happenned to my original post, sorry.
Thanks for the feedback; I have tried to re-post my original query and
the proposal...
>
> =0D=0AHi,=0D=0A=0D=0A> At one point I thought there was talk of integrati=
So here it is again, I would appreciate comments since I still believe
this is something we should pursue for 2.4.
I (Bill) said:
"At one point I thought there was talk of providing more integration
bewteen desktop-icon-sets and gtk+ stock icons... I think we could
benefit significant from some kind of reworking of how icon sets are
handled (internally) in gtk+.
For instance, at the moment replacing the GTK+ stock icons in a theme is
messy for several reasons:
* you have to specify separate image files for every icon, in the RC
file;
* you keep the prevompiled default icons around in all cases (though
they _do_ of course page out of memory if not used);
* the gtk+ stock icons are likely to live somewhere other than the other
icons, when respecified;
* the only way to reliably respecify icon size is either to use _only_
rescalable/wildcarded icons in the RC file, or provide _pre-scaled_
icons for each non-wildcarded icon/nominal-size combination, further
increasing the size of RC files and themes.
I seem to recall other issues as well.
So I think that some rethinking of the icon API (possibly with judicious
use of extensions/new API), or just changes to the internal
implementation, would be a good idea. At the least, it'd be nice to
integrate the GTK+ stock icon mechanism with the desktop-icon-set
mechanism if possible."
The (slightly-mangled) reply is below.
Peraonslly I think the existing gnome-themes which provide their own
icons work OK from a directory perspective, though there's no facility
for size-matching, which would arguably improve resolution. However
some have suggested that large size icons should mostly use SVG in the
future, which would eliminate or at least reduce the quality issues with
rescaling.
Personally I am more interested in how this could be made to work with
desktop-icon-sets (such that desktop-icon-sets and gtk+ stock icons were
more coincident, and if I chose a new desktop-icon-set gtk+ would get
its stock icons from the desktop set if possible). It would also be
nice to find a way to do this with compressed iconsets rather than rely
on the filesystem to organize all of these separate icon files.
More thoughts?
-Bill
"Here is a proposal; I think the simplest way to handle this is to use
directories this way :
<gnome-base-pixmaps>/<theme>/<size>/<icon_file>
where :
<gnome-base-pixmaps> is a distinct gnome-specific pixmaps directory
(b=cause when you look at a typical /usr/share/pixmaps, you=0D=0Afind
a=0D=0A=
> mixture of icons from different origins/styles/qualities and=0D=0Aso on=
> )=0D=0A=0D=0A_ <theme> is the theme directory (with one called "default",=
> =0D=0Abecause=0D=0A it comes with gtk tarball); so to install a new icon=
> s set=0D=0Athemes you=0D=0A only have to unpack a proper <theme>.tgz;=0D=
> =0A=0D=0A_ there must be at least one <size> directory, which has the for=
> m=0D=0A <width>x<height>. Provided size(s) should match HIG standard=0D=0A=
> ones=0D=0A (48x48, 24x24...)=0D=0A=0D=0A_ <icon_file> is the .png file n=
> amed after the stock ID name=0D=0A (cut.png, paste.png)=0D=0A=0D=0ASo th=
> e basic algo for retrieving icon files should be: search=0D=0A<theme>=0D=0A=
> directory, then default one; search for the best-fit <size>=0D=0Adirector=
> y...=0D=0A=0D=0A=0D=0A=0A=0AAcc=E9dez au courrier =E9lectronique de La Po=
> ste : www.laposte.net ; =0A3615 LAPOSTENET (0,13 =80/mn) ; t=E9l : 08 92 =
> 68 13 50 (0,34=80/mn)"=0A=0A
>
>
>
> --__--__--
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
> End of gtk-devel-list Digest
--
Bill Haneman <bill haneman sun com>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]