GtkIconSize/GtkIconFactory [was: Re: wip/hires-icons]

[branching thread here]

On Fri, May 17, 2013 at 8:20 PM, Alexander Larsson <alexl redhat com> wrote:
This branch doesn't precisely reinvent the wheel, there's just a few API
additions to current components to have this work as seamlessly as
possible. As choosing an icon must be postponed till rendering time, the
preferred way to hold this information is GtkIconSet and GtkIconSource,
as these already do a few things we want here:

  * It may already hold multiple sources for an image
  * GtkIconSize works as a scale-independent size abstraction

This has implied making GtkIconSets more prominent, so the matching
properties have been added to GtkEntry and GtkCellRendererPixbuf.

GtkIconTheme has been regarded as a lower level file->pixbuf abstraction
and mainly a few *_for_scale() calls have been added there so
GtkIconSets can resolve rendering to the bes3t pixbuf.

Ugh. I hate GtkIconFactory. Mainly due to the GtkIconSize abstraction.
Any time i use it I have to fight that crap, because what you really
*do* want is a (possibly scaled) pixel size. In fact, GtkIconFactory has
been mostly "deprecated" due to this and all modern code use icon names
and GIcons.

Hmmm, I happen to really like the GtkIconSize abstraction (and have
found that GtkIconFactory is a nice way to get custom icons into applications).

I'm curious, from a user facing API perspective, why we would want a pixel size
instead of a nice symbolic GtkIconSize in the form of an enumeration ?

Main reason I'm asking about this, is because GtkIconSize itself seems to
be the only sensible thing to configure an icon with in Glade.

Also Glade supports GtkIconFactory which seems to be a very practical way
to introduce custom icons into an application (since any pixbuf added to the
icon factory can then be referenced by the "icon-name" property which is
already available for many widgets).

Also we don't have any support for GIcons, and I'm not sure how exactly
we should support them to be loadable in GtkBuilder script (or more importantly,
"why" we would want to support that when we already have a pretty usable
interface of "icon-name" and "icon-size" pairs already on many widgets).

My understanding of GIcon so far has been that, it's a low level abstraction
which helps widgets with implementing the user facing APIs of themed icons
and icon sizes.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]