[Digikam-devel] [Bug 205776] "Embedded preview loads full image size" does not only do what it says, confusing users

[Matti Rintala]

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





--- Comment #22 from Matti Rintala <bitti cs tut fi>  2009-09-03 11:06:32 ---
Marcel,

I have no strong feelings about doing the patch. The feature itself (using
embedded raw previews in full size) is important for me, so I'm willing to try
to help, if help is needed. However, I have no prior experience in Digikam's
source, so I'm sure it takes me much more time to do the patch than if one of
you regular developers has time to invest in this matter. My goal is just to
get the needed feature as quickly as possible. :-)

I have some questions about the design:
- There are now two separate user preferences for preview quality, one for
previews and one for lighttable. Should the "use embedded preview for raw, if
available" setting duplicated to both places, so that the user can change
behaviour of album preview and lighttable independently?
- Earlier there has been only one bool option and one set of functions
(...LoadFullImageSize...) for preview quality. The most straightforward
solution for embedded previews would be to add another bool and set of
functions (...UseEmbeddedRawPreview...) to control this feature. However, I'm
no longer sure if that is good for future development. What if more control
over preview quality is needed later? Would it be wise to make a struct (or
enum) PreviewQuality, and replace current setLoadFullImageSize() functions with
setPreviewQuality() etc.? Then new preview quality options could be added more
easily without having to modify the intermediate classes which now only pass
through changes in preview quality. Currently PreviewQuality could contain just
two bools (full-size & embedded-preview), but later it could be expanded to
include user-defined maximum size etc, if need arises.

What do you think?

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.