[digikam] [Bug 361047] New: Wishlist: make grouped images more prominently visible [MOCKUP]

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

--- Comment #55 from Jens <[hidden email]> ---
Any news here? Anything I can do to help? Thanks!

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

--- Comment #56 from [hidden email] ---
Jens,

Nothing for the moment. It still in my TODO list.

If you want to take a look in the patch, in fact the main implementation is
already done, but the visual rendering need to be rewritten.

In fact i need a good idea. A mockup will be welcome. Perhaps also a search
about solutions from other proprietary application can be a good inspiration

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

Wolfgang Scheffner <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #57 from Wolfgang Scheffner <[hidden email]> ---
I think the mockup Jens provided in the first place is quite good, but just the
color thing. Of course the rotated frames are a nice gimmick but the colors
will do, maybe with just a thicker frame for the group leader; better than
fumbling endless with the rotation.
And if it really has to be a frame which indicates something "behind" the gruop
leader and the rotation is the problem: why not just something like the icon
under the thumbnail, stacked in a diagonal way?

Wolfgang

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

--- Comment #58 from Jens <[hidden email]> ---
I think modifying the thumbnail is essential here, otherwise it's not obvious
that this is actually a group. An additional icon or *only* the background will
not do.

But if the thumbnail size cannot be changed or causes other headaches, how
about a folded-corner effect like this one here?:
http://www.freepik.com/free-vector/folded-corner_835380.htm

The corner should not cover half the thumbnail of course, but it must be
clearly visible and obvious in all thumbnail sizes (and the corner might even
contain the number of grouped images). I would be willing to trade my original
"rotated image frame stack" idea for this one. and it might be easier to
implement because the thumbnail size doesn't change.

Bonus points if the folded page corner actually displays the lower right bit of
the *second* grouped image, maybe brightened up a little to differentiate it
from the main thumbnail. :-)

What do you think?

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

--- Comment #59 from Wolfgang Scheffner <[hidden email]> ---
Quite nice, that one!
What I was talking about is not an additional icon but a stacked frame *like*
the icon. Might be easier than a rotated frame.

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

--- Comment #60 from Jens <[hidden email]> ---
My originally suggested "rotated" frame can well be precomputed and just added
around the image as a border. I wasn't implying the frame should be recomputed
on every image (although this was the level of polish that iPhoto received from
Apple ... ;) )

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #98630|0                           |1
        is obsolete|                            |

--- Comment #61 from [hidden email] ---
Created attachment 104161
  --> https://bugs.kde.org/attachment.cgi?id=104161&action=edit
patch version 4 updated with current implementation from git/master

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #99002|0                           |1
        is obsolete|                            |

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Usability                   |AlbumsView-Group

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

--- Comment #62 from [hidden email] ---
Jens,

I updated the patch to be compilable with current implementation from
git/Master. I don't introduce the SVG idea.

The result is not too bad. There are some problems with icons overlays, as
geolocation and grouped indicator.

I like the isdea to apply a background color of all grouped items when this one
is expanded. This color case of use need to be tested when more than one group
is present in same album and when there are expanded.


The grouped thumb frame work as expected, even if large thumbnails size is
selected in setup dialog.

Activating also all thumbnails info, as rating, tags, comments, file name,
date, etc, sound like not broken, as with previous version 1 or 2 of the patch.

I'm not happy with the patch where some hardcoded enum are used as well. The
code also depends of color theme used for icon view, and it's hardcoded.

I don't yet tested the CPU use when an album has a large amount of grouped
items. Typically, the grouped thumb frame must be cached in memory. This must
be fast, but i want to be sure that non time latency is not introduced by the
code.

Ti resume : the patch need to be adjust, polished and tested again and again.

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

--- Comment #63 from Jens <[hidden email]> ---
Gilles,
that sounds great!
Can you create an appimage? I'll help you test it.
Jens

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

--- Comment #64 from [hidden email] ---
Hi Jens,

Not for the moment. I'm not at home without all my VM. Please weait next week.

We need also to fix some problem with icon overlays before. As well it's not
suitbale if some thumbnails options are disabed.

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

Simon <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #104161|0                           |1
        is obsolete|                            |
                 CC|                            |[hidden email]

--- Comment #65 from Simon <[hidden email]> ---
Created attachment 104371
  --> https://bugs.kde.org/attachment.cgi?id=104371&action=edit
patch version 5 updated with current implementation from git/master

I didn't change anything on the patch, just resolved merge issues with current
master (48988b3570740a9c76dd84c147ab2e3f49fd969c).

This looks pretty good and I could not "feel" any performance impact, but I
didn't measure in any way.
It would be better if the background indication for expanded groups would span
the gap between the individual icons to make it clearer which belong together,
but I guess that's pretty hard to do. Also a frame over all images of one group
would be good.
I don't like using color for this, as there is already the color label. I think
having two meaning for colors would be confusing. Just having one "color"
(shade) is IMO clear and elegant.

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

--- Comment #66 from [hidden email] ---
Hi Simon,

I agree that no performance issue is visible with grouped frame pixmap. The
cache is well used...

But look well in patch :

     if (!d->ratingRect.isNull())
     {
-        drawRating(p, index, d->ratingRect, info.rating(), isSelected);
+        int backgroundtype = 0;
+        if(isSelected)
+        {
+            backgroundtype = 1;
+        }
+        else if(isGroupExpanded)
+        {
+            backgroundtype = 2;
+        }
+
+        drawRating(p, index, d->ratingRect, info.rating(), backgroundtype);
     }

Why this kind of code for rating widget ? Why hard coded values in source code
?

As i said previously, there is also a layout problem with icon-view item
contents. Go to Setup dialog, and turn on HiDPI compatible thumbnail size
(<=512 px).

Now, turn on all icon-view item properties to be visible, and play with
thumbnails size slider from status bar. Look the result, for ex, with GPS
location indicator. The layout is broken...

Gilles

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #104371|0                           |1
        is obsolete|                            |

--- Comment #67 from [hidden email] ---
Created attachment 104642
  --> https://bugs.kde.org/attachment.cgi?id=104642&action=edit
patch version 6 updated with current implementation from git/master

New version of patch to compile against current git/master.

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

--- Comment #68 from [hidden email] ---
Simon,

The patch version 6 work well. We near to finalize it.

Maik,

Please test with all icon view options enabled. Change thumbnails size and look
if all items info still displayed as expected.

Gilles

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

--- Comment #69 from [hidden email] ---
Maik,

Outside the current patch, the git/master implementation has a problem with GPS
icon overlay. It do not follow the thumbnail size as other icon overlay
(rotate, selection, etc).

This problem do not exist with 4.x release. It think this have been introduced
with breeze icons patch in source code while 5.2/5.3 releases.

Look my screenshot for details:

https://www.flickr.com/photos/digikam/33396428281/

Can you reproduce ?

Gilles

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

--- Comment #70 from [hidden email] ---
Maik,

Same problem with patch applied. The position of GPS icon overlay is a little
bit different too...

https://www.flickr.com/photos/digikam/33396556291

Gilles

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

--- Comment #71 from Maik Qualmann <[hidden email]> ---
Git commit b425579e132fd21cb3be963bea50e5ab30678316 by Maik Qualmann.
Committed on 19/03/2017 at 09:46.
Pushed by mqualmann into branch 'master'.

fix small size from the globe icon

M  +2    -2    libs/widgets/itemview/itemviewimagedelegate.cpp
M  +2    -2    showfoto/thumbbar/itemviewshowfotodelegate.cpp
M  +2    -2    utilities/importui/items/itemviewimportdelegate.cpp

https://commits.kde.org/digikam/b425579e132fd21cb3be963bea50e5ab30678316

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361047

--- Comment #72 from [hidden email] ---
Simon, Maik,

If this patch do not introduce dysfunctions for you, it can be applied to
git/master and proposed to end users as testing through pre-release bundles.

Gilles

--
You are receiving this mail because:
You are the assignee for the bug.