Bug 160193 - Thumbnail labels too long/redundant/cut off
Summary: Thumbnail labels too long/redundant/cut off
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Thumbs-Image (show other bugs)
Version: 0.9.3
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-01 03:10 UTC by bcr
Modified: 2016-07-15 21:03 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 5.1.0
Sentry Crash Report:


Attachments
aii.diff (726 bytes, text/x-diff)
2008-04-03 20:13 UTC, Mikolaj Machowski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bcr 2008-04-01 03:10:35 UTC
Version:            (using KDE 3.5.9)
Installed from:    Ubuntu Packages
OS:                Linux

The current thumbnail display uses labels that are too verbose and redundant.

If I give you a number string:  (423) 897-1234  you could probably guess that I'm referring to a North American phone number by its formatting alone. If used on a business card I really don't need to park a label in front of it, people 'get it', it would be a waste of space.  (unless I add a fax #)

By the same token there is no need to include labels on the date values below each image in the Digikam thumbnail view:

 created: 2007-08-12
 modified: 2007-08-12

Why? Most images in most people systems are not modified, making the second value redundant. Just because some upstream metadata system might have parked a value that matches the created date in the modified field doesn't mean digiKam should perpetuate the mistake... if the dates are the same the image isn't 'modified' in the expected sense.

With the addition of the label the windowing system will crop the date text on the left with an ellipsis (...) rendering it unreadable. If the 'created:' label was left off this would greatly reduce the effect.

Suggested approach:

Compare the two dates; if they are the same or the modified value == null then just print out the created date on its own. If the modified date != null && modified date != create date then print it out as:

  2007-08-12
mod: 2008-01-13

Not only does it ease the clutter but it also makes it easier for the user to spot the modified ones.
Comment 1 Mikolaj Machowski 2008-04-03 20:13:31 UTC
I agree only partially.

Yes labels are too long. But they are shown on explicit request of the
user (Settings -> Albums -> Thumbnail information). Hiding one of the
dates is rather unexpected.

Attaching small patch against KDE 3 branch. This is replacing

created :   -> C:
modified :  -> M:

With such shortened labels date is visible with much smaller thumbnails
+ with one letter initials dates are aligned perfectly which makes
spotting changes between dates easier (well, "perfection" may depend on
font...)

Full solution would be adding another sub-option (bleh) in Album
settings

[ ] Show file modification date
	[ ] Show only if different from date of creation


Created an attachment (id=24170)
aii.diff
Comment 2 Andi Clemens 2010-09-25 17:43:11 UTC
Closing some old bugreports that are related to old digiKam version, and that have not received answers for two years now.

If you think the reports are still valid, feel free to re-open them, but please provide updates and do not just open them without giving feedback.
Comment 3 Fri13 2010-09-30 17:57:43 UTC
The wish is still valid. I think I do have a wish as well about adding the same C: and M: in front of the dates to make them shorter, as now user need to set custom font for them and set them smaller. But only if using smaller thumbnails and not big thumbnails.
But still I think it could be maded as suggested that show only the creation date and if it is modified, then show that date under as well.
Comment 4 caulier.gilles 2015-07-04 06:01:52 UTC
New digiKam 4.11.0 is available.

https://www.digikam.org/node/740

Can you reproduce the problem with this release ?
Comment 5 caulier.gilles 2016-07-15 21:03:59 UTC
With digiKam 5.0.0, this problem is not reproducible.
I close this file now. Don't hesitate to re-open if necessary.
Gilles Caulier