[Digikam-users] Suggestion for a Showfoto

[Arnd Baecker]

On Wed, 9 Apr 2008, Lawrence Plug wrote:

> I'm another mostly-lurker on this list, and a new one,  but am a daily
> user of digikam. I like the mockup a great deal. It would improve
> showfoto's usability and appearance quite a bit. I'll offer up one
> suggestion for a modification to the mockup, which I would prefer
> slightly.
>
> Rather than have the tools selected from a dropdown menu, an alternative
> would be to have the tools within tabs stacked vertically, which then
> individually drop down to show their respective sliders etc when
> selected.  This is the way that rawtherapee, for example, organizes
> tools. I find it very convenient (I use rawtherapee for ORFs). The tools
> are stacked in the order that they would generally be used (WB and
> exposure at the top, noise reduction near the bottom), and more than one
> tool can be opened at a time.

I like this variant.

> The advantage of this is that all the related tools are visible (visual
> cue to user), and because several can be open at one time, it is
> possible to see their settings even when not adjusting that particular
> tool. I find this useful. The commonly used tools i just leave open,
> others are nearly always closed.

Another option here would be to just have a subset
of tools visible. Something like "tool collections", e.g.
- one with a default subset
- another  collection with all tools,
- and user-definable subsets (which can be saved and loaded)

> The tools would be grouped into broader categories of transform tools,
> filters etc.. exactly as shown in the mockup.
>
> Ideally, I'd like to be able to open and close a tool with a keystroke.
> eg. ctrl-s drops down (or up) sharpening.
>
> On a related note (perhaps I should open a different thread) it would be
> FANTASTIC if showfoto would operate nondestructively on RAWs, like
> rawtherapee does, rather than the converted images. Perhaps this is
> already in the pipeline.

Well, this is the next step and discussed in
http://bugs.kde.org/show_bug.cgi?id=125387
Having such a tool collection (whatever you want to call it ;-)
would be the visual representation of the "action lists".

((What I would like a lot if such actions could be easily
exchanged/shared; this might also be related to
scripts written in KROSS; http://bugs.kde.org/show_bug.cgi?id=146866 ))

Code-wise all this will be a substantial change.
As discussed before: Maybe the most tricky bit is how to treat changes of
parameters in the chain of tools. Eg., if a crop is at the beginning,
followed by a levels adjustment, noise reduction and some sharpening,
then changing the crop means that everything in the chain has to be
re-computed.
In order that this works sufficiently smoothly for the user,
maybe it can only be done on the preview. Only when OK
is selected, all steps are executed on the full image...

BTW: Shouldn't also the raw conversion itself (including lense
correction) be put at the top of the pipeline?

Best, Arnd

> cheers
> Lawrence
>
> ** screenshot of the rawtherapee layout, with white balance and
> sharpening tools open.
> http://ljplug.smugmug.com/photos/277201951_u8QY4-X2.jpg
>
>
>
> On Wed, 09 Apr 2008 13:54:03 -0400, "Scott Chevalley"
> <avalon at osguru.org> said:
> >
> >
> > Marcel Wiesweg wrote:
> > >> Hi! I have made mockups (2) of the Showfoto. This PDF is my suggestion for
> > >> faster (=better) workflow when editing multiple photographs.
> > >> Hopefully this would open some discussion about the Showfoto's GUI and
> > >> questions about can it be polished even more? I think that digiKam already
> > >> has great GUI and professional options for photo management, now it's
> > >> editor needs polishing ;-)
> > >>
> > >
> > > Taking the main point (as it appears to me):
> > > Moving from separate dialogs to integrating the settings in the sidebar and
> > > the preview in the main area.
> > >
> > > This is an interesting idea, generally in KDE and other software there is a
> > > move away from modal dialogs towards non-modal solutions like the one
> > > suggested here. It is a valid point; the dialog is modal, so the window in
> > > the background cannot be used anyway. It would be interesting to hear the
> > > opinion of the people here on this list, as well as the opinion of a
> > > usability expert.
> > >
> > > Technically, such a change requires a larger amount of work. The main window
> > > need to be adapted, the base classes of the current image plugin dialogs need
> > > to be refitted into the new framework, and (at least with trivial changes)
> > > each image plugin need to be ported.
> > >
> > > _______________________________________________
> > > Digikam-users mailing list
> > > Digikam-users at kde.org
> > > https://mail.kde.org/mailman/listinfo/digikam-users
> >
> > As a mostly-lurker on the list, I just thought I'd throw my 2 cents in
> > and say that I like the mockup.  I think it follows more closely the
> > flow that other image/raw editors take, so would be easier for users to
> > get up to speed.
> >
> > I also see how being able to switch between images to apply the current
> > tool to each is much better than the modal dialog method.
> >
> > The only additional suggestion would be to somehow speed up the preview
> > of the modification, because some of the tools take a long time to do
> > what they do and try to do it for even the most miniscule change in
> > parameters.
> >
> > Scott
> > _______________________________________________
> > Digikam-users mailing list
> > Digikam-users at kde.org
> > https://mail.kde.org/mailman/listinfo/digikam-users
> _______________________________________________
> Digikam-users mailing list
> Digikam-users at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-users
>
>