<table><tr><td style="">markg added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D15071">View Revision</a></tr></table><br /><div><div><p>(repost from <a href="https://phabricator.kde.org/D15069" style="background-color: #e7e7e7;
border-color: #e7e7e7;
border-radius: 3px;
padding: 0 4px;
font-weight: bold;
color: black;text-decoration: none;">D15069</a>)</p>
<p>Hi Nate,</p>
<p>I'm afraid this will give inconsistent frames, at least that will be the perception of the user.<br />
The hasAlpha function on a QPixmap (probably) boils down to executing this function:</p>
<div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="text" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);">bool QX11PlatformPixmap::hasAlphaChannel() const
{
if (picture && d == 32)
return true;
if (x11_mask && d == 1)
return true;
return false;
}</pre></div>
<p>But there are quite some places in Qt where the alpha channel checks are done differently.The above would be for X11, it's likely different on wayland, etc...</p>
<p>So where is this going to be inconsistent? Well, with images that "have" an alpha channel but don't use it.<br />
This happens when saving an image. It's often a setting to keep transparency or not (it is in photoshop and gimp).<br />
Therefore you can - and will - have people that have images with an alpha channel but don't use it so they don't get a frame. While the very same image when saved differently (and in png as well) will have a frame. That's going to be a bug report from that user i guess ;)</p>
<p>Having said that, i'm much more in favor of an all-or-nothing approach. Not some logic somewhere that dictates when an image has a frame and when it doesn't.<br />
We've had frames for years so perhaps it's time to just flip the switch and see how users like it. So just flip that switch by default to no frames.</p>
<ul class="remarkup-list">
<li class="remarkup-list-item">end of previous comment.</li>
</ul>
<p>As <a href="https://phabricator.kde.org/p/ngraham/" style="
border-color: #f1f7ff;
color: #19558d;
background-color: #f1f7ff;
border: 1px solid transparent;
border-radius: 3px;
font-weight: bold;
padding: 0 4px;">@ngraham</a> figured out, Qt apparently does some more in depth transparency checking. I wonder if it does a pixel-by-pixel test, that would be expensive.<br />
Anyhow, i'd just say - to be consistent - to flip the switch. No frames at all anywhere. It looks just weird to me to have folders where some images have frames and some don't.<br />
For users it will be weird as well, they might even consider it a bug and report it.</p>
<p>It would be a whole different story if the frames were part of a larger area (so including the filename), kinda like <a href="https://s3.envato.com/files/31319902/screenshot1.jpg" class="remarkup-link" target="_blank" rel="noreferrer">this</a>. But it isn't. It's merely directly around the image.<br />
It probably (assumption) was a way to imitate Finder (of macOS) and the old "Windows Live Photo Gallery" specially the later one has a nearly 1-on-1 matching with the frame Dolphin draws.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R241 KIO</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D15071">https://phabricator.kde.org/D15071</a></div></div><br /><div><strong>To: </strong>ngraham, Frameworks, Dolphin, VDG, broulik, cfeck<br /><strong>Cc: </strong>markg, abetts, bruns, kde-frameworks-devel, michaelh, ngraham<br /></div>