Bug 146463 - HIG CL3: Warning messages from light table
Summary: HIG CL3: Warning messages from light table
Status: RESOLVED NOT A BUG
Alias: None
Product: digikam
Classification: Unclassified
Component: Usability-Ergonomy (show other bugs)
Version: unspecified
Platform: Ubuntu Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-06 23:32 UTC by Jakob Østergaard
Modified: 2022-01-20 04:19 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 7.6.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jakob Østergaard 2007-06-06 23:32:35 UTC
Version:           Current SVN  (using KDE KDE 3.5.6)
Installed from:    Ubuntu Packages
Compiler:          gcc 4.1.2 
OS:                Linux

I have an album with a number of .cr2 RAW files.
In this album, I select 5 images, right-click, and select "add to lighttable".
Now, in the lighttable, I add an image to the left side, one to the right side, and click on various images to change the right-side image.

Whenever I click on one of the images, I see (one pair for each click):

Warning: Directory Canon has an unhandled next pointer.
Warning: Size 5352 of Exif.Canon.0x4002 exceeds 4096 bytes limit. Not decoded.
Warning: Directory Canon has an unhandled next pointer.
Warning: Size 5352 of Exif.Canon.0x4002 exceeds 4096 bytes limit. Not decoded.
Warning: Directory Canon has an unhandled next pointer.
Warning: Size 5352 of Exif.Canon.0x4002 exceeds 4096 bytes limit. Not decoded.
Warning: Directory Canon has an unhandled next pointer.
Warning: Size 5352 of Exif.Canon.0x4002 exceeds 4096 bytes limit. Not decoded.
Warning: Directory Canon has an unhandled next pointer.
Warning: Size 5352 of Exif.Canon.0x4002 exceeds 4096 bytes limit. Not decoded.
Comment 1 caulier.gilles 2007-06-06 23:42:18 UTC
This is not a bug. 

These messages come from Exiv2 library witch handle metadata from pictures. Its want mean than Canon encode an Exif tag using a lenght bigger than the limit defined in Exif standard...

Gilles Caulier
Comment 2 Jakob Østergaard 2007-06-06 23:48:19 UTC
On Wednesday 06 June 2007 23:42:19 Gilles Caulier wrote:
...
> These messages come from Exiv2 library witch handle metadata from pictures.
> Its want mean than Canon encode an Exif tag using a lenght bigger than the
> limit defined in Exif standard...
>


Ok thanks Gilles,

I thought the warning messages might point to the cause of some of the other 
problems I see (I have found two problems and I am reporting them now).

So, while I usually would never report such a warning message, I felt it might 
be important in this case. Thanks for the quick reply!
Comment 3 Mikolaj Machowski 2007-06-07 08:56:39 UTC
http://wiki.openusability.org/guidelines/index.php/Checklist_Warning_Messages

Language 
Warning dialogs should be: 
 Understandable. 
Clearly phrased messages, non-technical terms and no obscure error codes should not be used.  
 Specific instead of general. 
If the message is reporting a problem concerning a specific object or application, the object or application name should be used when referring to it.  
 Informative and constructive. 
The reason for a problem should be given, and hints how to solve it. 
 Polite, non-terrifying and non-blaming. 
Wording that terrifies the user ("fatal", "illegal") shouldn't be used, users shouldn't be blamed for their behavior, and the message should be polite. 
Comment 4 caulier.gilles 2007-06-07 09:12:28 UTC
Mik,

I cannot accept this B.K.O file as well (:=))). The message do not appear in a dialog, but in the console as debug messages.

Also these messages are generated by Exiv2 library, not digiKam implementation. 
I'm agree with the way than debug console messages must be more explicit. There are a lots informations generated by Exiv2 in the console. But this is not relevant of digiKAm implementation. Please close this B.K.O file and open a new one the Exiv2 bugzilla...

Thanks in advance

Gilles
Comment 5 Jakob Østergaard 2007-06-07 09:15:51 UTC
I should add that I only submitted this bug because I thought it was 
related to #146464 (before I investigated #146464 properly).