Bug 3017 - Privacy emblem positioning is broken
Summary: Privacy emblem positioning is broken
Status: RESOLVED INVALID
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: UI/Message View (show other bugs)
Version: 3.9.2
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2013-10-17 11:52 UTC by Ian Nartowicz
Modified: 2013-10-18 17:24 UTC (History)
0 users

See Also:


Attachments
Emblems in default theme (10.75 KB, image/png)
2013-10-17 14:47 UTC, Ian Nartowicz
no flags Details
Emblems in Everaldo Kids theme (13.79 KB, image/png)
2013-10-17 14:48 UTC, Ian Nartowicz
no flags Details
Emblems in KDE4ish theme (15.81 KB, image/png)
2013-10-17 14:49 UTC, Ian Nartowicz
no flags Details
My understanding of the correct positioning (8.14 KB, image/png)
2013-10-17 16:43 UTC, Ian Nartowicz
no flags Details

Description Ian Nartowicz 2013-10-17 11:52:08 UTC
The privacy emblem (encrypted, signed, etc). is intended to be displayed with its bottom right corner 6 pixels to the right and 3 pixels below the bottom right corner of the underlying mime type icon.  Thus there is a small overlap of the bottom right corner of the mime icon.  This used to work, certainly in the 2.* series.

Now the emblem is positioned with its top left corner 6 pixels to the right and 3 pixels below the top left corner of the mime icon.  Hence it sites squarely over that icon and hides much of it.  This has been happening since at least 3.8.2 and probably earlier.

The bug is in stock_pixmap_widget_with_overlay in mimeview.c attempting to calculate the height and width of the two icons using gtk_widget_get_requisition, but getting the height and width of the emblem from the mime type requisition.  So all the offset calculations cancel out just leaving the 3/6 border pixels.
Comment 1 Paul 2013-10-17 12:00:34 UTC
I've never seen any change in it. Maybe screenshots would help you explain the problem that you perceive.
Comment 2 Ian Nartowicz 2013-10-17 14:47:14 UTC
Created attachment 1301 [details]
Emblems in default theme
Comment 3 Ian Nartowicz 2013-10-17 14:47:42 UTC
I've attached a screenshot of the default theme, but it is not very informative because the emblem and mime type icon are approximately the same size, so it doesn't much matter which corner the offset is calculated from.  With the small encrypted padlock icon it is more obvious but that never appears for me (see bug 3016).  Even so I don't think this is the desired effect.

So I've also attached a screenshot with the Everaldo kids theme which uses larger mime type icons.  Here the emblem is clearly not overlapping the bottom right corner, but offset slightly from the top left corner and therefore slap in the middle of the mime type icon.

Lastly, I've attached a screenshot with the KDE4ish theme which uses a small padlock icon as the emblem for signed mime types.  This appears almost exactly centered in the mime type icon instead of overlapping the bottom right corner.  You can see how it used to (is/was intended to) look many years ago at this link:
https://commons.wikimedia.org/wiki/File:ClawsMail-rs.png
Comment 4 Ian Nartowicz 2013-10-17 14:48:40 UTC
Created attachment 1302 [details]
Emblems in Everaldo Kids theme
Comment 5 Ian Nartowicz 2013-10-17 14:49:24 UTC
Created attachment 1303 [details]
Emblems in KDE4ish theme
Comment 6 Ian Nartowicz 2013-10-17 16:42:21 UTC
One further attachment.  This is how I believe the emblem is supposed to be positioned, nestled in the bottom right corner just filling the (hard-coded) 6 pixel right border and 3 pixel bottom border around the mime type icon.  I faked this up with my own theme by using transparent filler on the emblem icon.
Comment 7 Ian Nartowicz 2013-10-17 16:43:19 UTC
Created attachment 1304 [details]
My understanding of the correct positioning
Comment 8 Colin Leroy 2013-10-17 17:12:46 UTC
No, what you see is what's meant to be!

It's supposed to start 6px from the left, 3px from the top :)
Comment 9 Ian Nartowicz 2013-10-18 16:34:16 UTC
Please!  Can you keep a straight face when you say that?  Is passing a flag called BOTTOM_RIGHT to a function that calculates the emblem position as the difference of the widths (or heights) of the two icons plus twice the border width (or height) really trying to offset from top left?  Just because it gets it wrong and you have got used to the result doesn't mean it is what was intended.

Still, I think I'd rather this doesn't change.  The current behaviour is predictable across all recent versions and I can make my theme work with it.

Line 658 in stock_pixmap.c if you're interested, a whole function for calculating overlaid icon offsets in any direction.  If you give it the right icon size data :)
Comment 10 Colin Leroy 2013-10-18 16:53:39 UTC
Hi,

Rest assured I keep a really really straight face, as this is me who ported this function to GTK+2.

OVERLAY_BOTTOM_RIGHT means we want the overlayed pixmap towards the bottom right of the original one. Borders border_x and border_y have nothing to do with offsets, but with borders.

see function do_pix_draw().
Comment 11 Ian Nartowicz 2013-10-18 17:24:40 UTC
That isn't what the code does though.

For example, the algorithm (in do_pix_draw) for positioning "right" is the width of the base icon minus the width of the overlay icon plus twice the border.  If you want to describe this as positioning towards the right, then it is positioning towards the right by the width of the sensitive area (base icon plus two borders) minus the width of the overlay icon.  Any sensible person would call that positioning at the right side of the area, but call it what you will.

To visualise easily, take an extreme case with a 100px base icon, a 1px overlay icon, and a 10px border.  The origin (left side of the overlay icon) becomes 119px.  The icon is crammed against the edge of the right border.  Only when the two icons are approximately the same size does the algorithm reduce to overlaying towards the right by the border width.

End result, the emblem is not positioned where this algorithm intends, apparently because the wrong height and width data is passed in.  Try it with a tiny emblem and a huge base icon and it is immediately obvious that something is wrong.  The emblem is positioned near the left when the algorithm intends it to be positioned near the right.  Maybe you've convinced yourself that's what you want, but it isn't what the code was written to do.  To position as you describe does not require the height and widths of the two icons, only the offset amount, which is the width of the border.

Note You need to log in before you can comment on or make changes to this bug.