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

[bugzilla_noreply]

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

--- Comment #73 from Maik Qualmann <[hidden email]> ---
No, the patch is not ready yet. The geolocation icon position is not yet
correct. I know why, but I want to optimize some things.

Maik

--
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 #74 from Maik Qualmann <[hidden email]> ---
Created attachment 104647
  --> https://bugs.kde.org/attachment.cgi?id=104647&action=edit
patch version 7

- visual appearance of non-grouped thumbnails is now unchanged
- geolocalization icon at the correct position

What I do not like is the background color for opened grouped thumbnails. I am
still searching for a better idea.

Maik

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

[bugzilla_noreply]

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

Maik Qualmann <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #104642|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

--- Comment #75 from [hidden email] ---
MAik,

Look also that an enum must be used here, about background color :

+        if (isSelected)
+        {
+            backgroundtype = 1;
+        }
+        else if (isGroupExpanded)
+        {
+            backgroundtype = 2;

The background color is a good idea, if there is only one group open in an
album. In case of multiple groups expanded, this become unsuitable.

I thinking about a special color label, but this will break color label feature
with grouped images.

Gilles

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 #76 from Jens <[hidden email]> ---
How about we visually (!) treat an opened group like a subalbum at the
respective position in the list of images? the master image should then also be
in the subalbum and must still be highlighted somehow but this can be done with
E. g. a thicker border frame (instead of another color).

Yes, this would require a rearrangement of all thumbnails in the album (since a
row is probably being split up) but it would be consistent.

Another idea is to reduce the opacity of opened grouped thumbnails to e. g. 50
percent  but only(!) while the mouse is not over one of the group. this does
not affect visibility while relevant, it indicates clearly what is grouped, and
it does not interfere with color schemes. Also, it creates the possibility of
correctly sorting grouped images in between non grouped ones when the group is
opened.

--
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 #77 from [hidden email] ---
Maik,

I like the "mouse over with 50% transparency" idea. What do you think about ?

Gilles

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

[Simon Frei]

The problem with putting expanded groups in their separate part is space
usage. When you expand most/all groups, you will have lots of space lost
(e.g. two images per line). This is very intrusive, in my opinion
grouping should be as seamless as possible (that's why I like the table
treeview best for that).

Another idea: Make the background colour seamless or use a frame around
all the images in an expanded group. This makes it clear which images
actually belong together, instead of just indicating that the image
belongs to a group by a uniform background. However I tried to find any
hints in the interweb about how to add design elements spanning multiple
indexes in a QListView and I couldn't come up with anything.

The 50% opacity sounds cool, but I think it has the same problem: If two
expanded groups are adjacent, it is not clear which items belong to
which group, only that all of them are in a group.

[bugzilla_noreply]

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

--- Comment #78 from Maik Qualmann <[hidden email]> ---
Git commit 2a54e446e2a9cf04d9b79360d1d12405a188a2c3 by Maik Qualmann.
Committed on 20/03/2017 at 19:49.
Pushed by mqualmann into branch 'master'.

apply visual patch for grouped images without background color function

M  +3    -1    app/items/imagedelegate.cpp
M  +22   -6    libs/widgets/itemview/ditemdelegate.cpp
M  +1    -1    libs/widgets/itemview/ditemdelegate.h
M  +31   -6    libs/widgets/itemview/itemviewimagedelegate.cpp
M  +20   -20   libs/widgets/itemview/itemviewimagedelegate.h
M  +34   -2    libs/widgets/mainview/thumbbardock.cpp
M  +2    -1    libs/widgets/mainview/thumbbardock.h

https://commits.kde.org/digikam/2a54e446e2a9cf04d9b79360d1d12405a188a2c3

--
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 #79 from Simon <[hidden email]> ---
Currently the "grouping indication" (rotated frames in background) are visible
whether the group is expanded or not. I think it should only be visible when
the group is not expanded.

--
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 #80 from Maik Qualmann <[hidden email]> ---
Git commit 5cd5b23b6ddb9eab927f1e7a68e593c138c7c538 by Maik Qualmann.
Committed on 23/03/2017 at 20:18.
Pushed by mqualmann into branch 'master'.

draw grouped border only if the group closed

M  +4    -1    app/items/imagedelegate.cpp

https://commits.kde.org/digikam/5cd5b23b6ddb9eab927f1e7a68e593c138c7c538

--
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 #81 from Jens <[hidden email]> ---
I would really like to see/review this change. Is there a chance to replace 1-2
compiled files in the appimage (libraries etc) or will you compile new
appimages anyway in a few days?
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 #82 from [hidden email] ---
I will recompile the AppImage this week end as well...

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 #83 from [hidden email] ---
Anyway, yesterday i recompiled the AppImage. It do not have teh last commit
from Maik, but all the rest is already inside. It's at usual place in GDrive
repository.

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 #84 from Jens <[hidden email]> ---
Is the transparency / opacity patch already applied to git master? See comment
76, idea 2.

--
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 #85 from [hidden email] ---
No this idea is not implemented. This can be interesting effectively...

Q: Why this bug is still open as patch was applied to git/master ? As the
original idea is implemented in current 5.6.0 version, i think this file can be
closed and another one open with the idea 2 from comment 76.

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

Jens <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|REOPENED                    |RESOLVED

--- Comment #86 from Jens <[hidden email]> ---
Agreed. Will open a new bug.

--
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
----------------------------------------------------------------------------
   Version Fixed In|                            |5.7.0

--
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 #87 from [hidden email] ---
Jens,

For a reason that i don't know, the digiKam 5.6.0 bundles and tarball still in
pending queue to be published on KDE download server. Typically it must be
published one week ago. Nothing happen, KDE admin do not process files on
queue, and digiKam is not alone in this case.

So, i published the official 5.6.0 files on GDrive repository, at least...

https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM

Gilles Caulier

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