After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 678087 - gtk_entry_set_icon_from_pixbuf() crops big pixbufs instead of resizing them
gtk_entry_set_icon_from_pixbuf() crops big pixbufs instead of resizing them
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkEntry
3.4.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2012-06-14 10:53 UTC by Carlos Garnacho
Modified: 2012-07-13 15:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (2.90 KB, patch)
2012-06-14 10:53 UTC, Carlos Garnacho
needs-work Details | Review
patch v2, GtkIconHelper API addition (3.46 KB, patch)
2012-07-13 14:00 UTC, Carlos Garnacho
committed Details | Review
use iconhelper api in entries (1.33 KB, patch)
2012-07-13 14:01 UTC, Carlos Garnacho
committed Details | Review
use iconhelper api in statusicon (2.29 KB, patch)
2012-07-13 14:01 UTC, Carlos Garnacho
committed Details | Review

Description Carlos Garnacho 2012-06-14 10:53:19 UTC
Created attachment 216401 [details] [review]
patch

If a big pixbuf (bigger than 16x16 usually) is used as an entry icon, the pixbuf is used as-is, and hence shows up cropped as the entry doesn't resize vertically to fit icons.

I'm attaching a patch to have GtkEntry/GtkIconHelper downscale those pixbufs so they fit. The other, uglier option is actually changing the entry height
Comment 1 André Klapper 2012-06-26 12:31:12 UTC
Comment on attachment 216401 [details] [review]
patch

[Patch => setting "patch" flag and correct mimetype]
Comment 2 Cosimo Cecchi 2012-07-12 19:05:04 UTC
Review of attachment 216401 [details] [review]:

Sounds good to me in theory, but we should make sure no other widget gets an unwanted scaling behavior.
The part I'm worried about is that GtkImage documentation doesn't seem to imply its pixel-size and icon-size properties should work when a GdkPixbuf was set on it, and this patch would change that; the same is also true for at least GtkCellRendererPixbuf (for the stock-size property).
You could either ensure this by checking for storage_type != pixbuf in each of the callers, or by having a force_resize flag or similar on the icon helper, not sure what's best.

::: gtk/gtkiconhelper.c
@@ +291,3 @@
+      self->priv->icon_size != GTK_ICON_SIZE_INVALID)
+    {
+

Can you move these at the top of the function to make it consistent with the other similar ensure_* helpers?
Comment 3 Carlos Garnacho 2012-07-12 19:52:28 UTC
(In reply to comment #2)
> Review of attachment 216401 [details] [review]:
> 
> Sounds good to me in theory, but we should make sure no other widget gets an
> unwanted scaling behavior.

Right, this would also play odd with GtkStatusIcon where it does the rescaling itself

> The part I'm worried about is that GtkImage documentation doesn't seem to imply
> its pixel-size and icon-size properties should work when a GdkPixbuf was set on
> it, and this patch would change that; the same is also true for at least
> GtkCellRendererPixbuf (for the stock-size property).
> You could either ensure this by checking for storage_type != pixbuf in each of
> the callers, or by having a force_resize flag or similar on the icon helper,
> not sure what's best.

How about a gboolean force_resize argument on _new()? it's at least GtkEntry and GtkStatusIcon which would benefit from this.

> 
> ::: gtk/gtkiconhelper.c
> @@ +291,3 @@
> +      self->priv->icon_size != GTK_ICON_SIZE_INVALID)
> +    {
> +
> 
> Can you move these at the top of the function to make it consistent with the
> other similar ensure_* helpers?

The fallback part of the function still needs to be hit though, right?

+  if (!self->priv->rendered_pixbuf)
+    self->priv->rendered_pixbuf = g_object_ref (self->priv->orig_pixbuf);
Comment 4 Cosimo Cecchi 2012-07-12 21:20:56 UTC
(In reply to comment #3)

> How about a gboolean force_resize argument on _new()? it's at least GtkEntry
> and GtkStatusIcon which would benefit from this.

On second thought maybe what we really need for this is simply a flag that determines whether pixbufs should be scaled as well, defaulting to FALSE.

_gtk_icon_helper_set/get_force_scale_pixbuf()

All the other storage type cases shouldn't modify their behavior is this flag is TRUE...GtkStatusIcon could then use it to force a pixel size and avoid doing the scaling itself.

> > ::: gtk/gtkiconhelper.c
> > @@ +291,3 @@
> > +      self->priv->icon_size != GTK_ICON_SIZE_INVALID)
> > +    {
> > +
> > 
> > Can you move these at the top of the function to make it consistent with the
> > other similar ensure_* helpers?
> 
> The fallback part of the function still needs to be hit though, right?

Sorry, git-bz made it hard to understand what I was referring to here...I was just asking to move the gint width, height variable declarations at the top of the function :)
Comment 5 Carlos Garnacho 2012-07-13 14:00:30 UTC
Created attachment 218726 [details] [review]
patch v2, GtkIconHelper API addition
Comment 6 Carlos Garnacho 2012-07-13 14:01:04 UTC
Created attachment 218727 [details] [review]
use iconhelper api in entries
Comment 7 Carlos Garnacho 2012-07-13 14:01:32 UTC
Created attachment 218728 [details] [review]
use iconhelper api in statusicon
Comment 8 Cosimo Cecchi 2012-07-13 14:25:11 UTC
Review of attachment 218726 [details] [review]:

Looks good, except for the following comment

::: gtk/gtkiconhelper.c
@@ +608,3 @@
+                                         gboolean       force_scale)
+{
+}

Should probably check if self->priv->force_scale != force_scale here, and call invalidate() if it is.
Comment 9 Cosimo Cecchi 2012-07-13 14:25:25 UTC
Review of attachment 218727 [details] [review]:

Sure
Comment 10 Cosimo Cecchi 2012-07-13 14:25:36 UTC
Review of attachment 218728 [details] [review]:

Looks good
Comment 11 Carlos Garnacho 2012-07-13 14:59:29 UTC
I've applied the suggested modification and committed all 3 patches, thanks!