Suggestion for a Showfoto

[Paristo]

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 ;-)

Here is link to my PDF (5.8MB)
http://saukonpaa.com/digikam/digikam_showfoto.pdf
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

Thanks Risto for the mocup.

I think you can make a new file in bugzilla to:

- attach your PDF document on new file (warning, file size is limited.)
- Make numerated sections in your document for each main point to
solve. These one will be referred to bugzilla entry. This is the most
important stuff to do.

There are few sections that i can fix easily :

- Reset buttons for each settings.
- Color bar temperature for White balance tool.

All others points are more complex to fix : thumbbar checkbox, sidebar
integration as editor plugins settings, etc.

Marcel, I would to see your viewpoint here. Thanks in advance

Best

Gilles Caulier

2008/4/8, Risto Saukonpaa <[hidden email]>:

>
>  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 ;-)
>
>  Here is link to my PDF (5.8MB)
>  http://saukonpaa.com/digikam/digikam_showfoto.pdf
>  _______________________________________________
>  Digikam-users mailing list
>  [hidden email]
>  https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Marcel Wiesweg]

> 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
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Osguru Mail]

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
> [hidden email]
> 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
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Am Mittwoch 09 April 2008 schrieb Scott Chevalley:

> 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.

These are the same thougts that came into my mind.
I like the idea to put the tools into the sidebar,  i can imagine that this
gives a better overview.
But the time for calculating a preview might be a problem.

regards
Stefan

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

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.

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.

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.

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"
<[hidden email]> 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
> > [hidden email]
> > 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
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Dnia Wednesday 09 of April 2008, Marcel Wiesweg napisał:
> 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

I like the idea. It should simplify interaction with tools. But it
should be full implementation as in first mockup - all or nothing.

> 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.

I remember about first introduction of digikamimage plugins in current
form that it was choice: have plugins now in that form or wait several
months for necessary for rewrite of Image Editor/showFoto. Consensus was
on "now", but maybe KDE4 migration is good time for such thing?

m.

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Dnia Wednesday 09 of April 2008, Lawrence Plug napisał:
> 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.

RT uses very compact GTK style. Default KDE/Qt is much more spacey,
stacked tabs will take much more space.

> Ideally, I'd like to be able to open and close a tool with a keystroke.
> eg. ctrl-s drops down (or up) sharpening.

Don't see why current shortcuts should stop working.

m.

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gerhard Kulzer-3]

On Wednesday 09 April 2008 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.

I think this is the way to go after KDE4  release. I've been expressing my wish for non-modal editing on this ML already, I was just quiet because of the amount of work involved. Right now is not a good time to start such a project. But you Gilles and Marcel know much better what is involved.

Gerhard

> 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
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Lawrence Plug]

On Wed, Apr 09, 2008 at 10:26:38PM +0200, Mikolaj Machowski wrote:

> Dnia Wednesday 09 of April 2008, Lawrence Plug napisał:
> > 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.
>
> RT uses very compact GTK style. Default KDE/Qt is much more spacey,
> stacked tabs will take much more space.

I did not know of this limitation in KDE. (digikam is the only
KDE app I use. It certainly is a great one by the way). Is there
no option to compress?

> > Ideally, I'd like to be able to open and close a tool with a keystroke.
> > eg. ctrl-s drops down (or up) sharpening.
>
> Don't see why current shortcuts should stop working.

No, I suppose not. My point was that it would be very useful for
digikam to have multiple tools open (and close as needed) in the
right panel using keystrokes (RT doesn't do that with keystrokes
AFAIK, for example). If it wont work, c'est la vie.

L

>
> m.
>
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

I take it that showfoto is the image editor part of digikam? I am using
kubuntu 7.10 and the kubuntu default shipped digikam version 0.9.2 (KDE3.5.8)
and in that version the image editor has no name, just "image editor".

The changes suggested are good imho. I don't like "modal dialogs" if that
means dialogs that work to the exclusion of all other functionality in the
program.

I'd like to comment on two things though:
1) workflow
2) data storage

1) I am not sure if Risto was aware of it, but many applications
use "workflow" as a synonmymous term with macro: a collection of discrete
steps to be performed in a given order in the editing of data using various
functionality available in the program (and/or external applications).
A "script" (although usually edited with tools in the programs GUI) which can
be stored, and applied to more than one instance of data (in this case
images). This is nice to have, especially for bulk data handling.

Workflows could be used for automating series of actions that are always
performed similarly and considered routine boring work for the user. One
example of a series of actions I could like to have put into a "workflow
object "that I use every time I am "done, for now" editing a picture:

*save file regularly (see remarks under 2) below)
*save copy to screen size resolution and put in wallpaper slideshow folder
*export copy to flickr using specified settings
*print copy on my printer in selected reolutions and picture size etc
*send e-mail to "recipient" "look at my new cool pictures" "+link to image in
flickr"

2) In my opinion, a more user-friendly data handling is possible in showfoto.
When a picture is selected for editing, the original should rest un-changed,
with original filename on disk. (I assume this is started from digikam
although I think showfoto can work standalone too?)
 
The editing should work on a copy. When the user selects save, the default
option is to save the copy along with the original image. Alternative to
overwrite original image should be available and in application settings it
should be possible to reconfigure the default.

When the user continues to edit the picture, and then later selects save
again, default should be to save yet another file, and keep both the
original, the first edited version and the new edited version. Alternative:
overwrite first edited version, overwrite original (and destroy all other
versions.) And so forth for the third edited version. Of course, it is
possible to create multiple new edited versions based on the first edited
version - and then you have a tree with several branches.

I realize I am describing a version-handling like system for storing images as
they are being edited. I am quite sure it must be possible to implement that
but not skilled to do it myself, so I thought I should challenge someone else
to implement it. :-)
 
PS: some kind of storage space limit per tree created (per edited picture)
might be a good idea even if storage is cheap these days. For laptop users it
is more restrictive than for the typical desktop user, who is rapidly
approaching terabytes of storage space if he/she is an enthousiast.

--
Thomas



_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

2008/4/10, Lawrence Plug <[hidden email]>:

> On Wed, Apr 09, 2008 at 10:26:38PM +0200, Mikolaj Machowski wrote:
>  > Dnia Wednesday 09 of April 2008, Lawrence Plug napisał:
>  > > 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.
>  >
>  > RT uses very compact GTK style. Default KDE/Qt is much more spacey,
>  > stacked tabs will take much more space.
>
>
> I did not know of this limitation in KDE. (digikam is the only
>  KDE app I use. It certainly is a great one by the way). Is there
>  no option to compress?
>

yes, there are 2 options can used in layout to set margin and spacing.
By default i use KDE settings but i can customize of course.

Gilles Caulier
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

On Thu, 10 Apr 2008 12:54:39 +0200, "Gilles Caulier"
<[hidden email]> said:

> 2008/4/10, Lawrence Plug <[hidden email]>:
> > I did not know of this limitation in KDE. (digikam is the only
> >  KDE app I use. It certainly is a great one by the way). Is there
> >  no option to compress?
> >
>
> yes, there are 2 options can used in layout to set margin and spacing.
> By default i use KDE settings but i can customize of course.


Thanks for the reply. If you can make stacked tabs fit, it would be a
good option (especially for those with large screens -- which I guess is
more and more). The RT interface scrolls the right panel when the it
overflows.

cheers
Lawrence
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

I'd like to comment on large screens:
I use a 3200x1200 twin screen setup and what definetly works best with this is
menus/palettes that can be torn of and displaced around on the desktop,
outside the main application window - GIMP is an example here.

When working with twinview setups, having viewports that stretch across the
screen boundary is a hassle. When working with GIMP I put a maximised or near
maximised image on left side, and lay out all my tools (the ones I am using=)
on the right hand side.

--
************************
Thomas Sperre
8900 Research Forest Drive apt.1313
The Woodlands, Texas
77381
United States of America
e-mail: [hidden email]
phone: [phone]


_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

I should add: scrolling on overflow is fine. If the user could arrange
the order of tools in the stack, it would be very good as scrolling
would then rarely be necessary.

I hope the suggestions are helpful (that is the intent). I'm sure
implementation, of whatever is done, is not so easy!

Lawrence

On Thu, 10 Apr 2008 09:27:40 -0300, "Lawrence Plug" <[hidden email]>
said:

>
> On Thu, 10 Apr 2008 12:54:39 +0200, "Gilles Caulier"
> <[hidden email]> said:
>
> > 2008/4/10, Lawrence Plug <[hidden email]>:
> > > I did not know of this limitation in KDE. (digikam is the only
> > >  KDE app I use. It certainly is a great one by the way). Is there
> > >  no option to compress?
> > >
> >
> > yes, there are 2 options can used in layout to set margin and spacing.
> > By default i use KDE settings but i can customize of course.
>
>
> Thanks for the reply. If you can make stacked tabs fit, it would be a
> good option (especially for those with large screens -- which I guess is
> more and more). The RT interface scrolls the right panel when the it
> overflows.
>
> cheers
> Lawrence
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Marcel Wiesweg]

> I take it that showfoto is the image editor part of digikam? I am using
> kubuntu 7.10 and the kubuntu default shipped digikam version 0.9.2
> (KDE3.5.8) and in that version the image editor has no name, just "image
> editor".

Showfoto is a standalone program, but it shares the essential parts with the
image editor integrated into digikam. (No database usage in showfoto, most of
the code is common) So the discussion here applies equally well to both
ShowFoto and the Image Editor.

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Sveinn í Felli]

Hi all;

Lawrence Plug wrote:

>
> 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.
>
> 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.
>
> The tools would be grouped into broader categories of transform tools,
> filters etc.. exactly as shown in the mockup.
>

>
> ** screenshot of the rawtherapee layout, with white balance and
> sharpening tools open.
> http://ljplug.smugmug.com/photos/277201951_u8QY4-X2.jpg
>

Personally I like this approach - up to certain complexity.

My experience with 3D-Max (which has been using similar
tabbed-interface) is that once the number of tabs exceeds a
reasonable number it becomes a task of its own trying to
find that nice feature you want to apply. Yet more tabs, the
tabs have to be grouped, which would be fine if one could
customize which tabs go to which page.
And even if the tabs in 3D-Max unfold when clicked, most of
the time they don't fit on a laptop screen (you need real
screen estate to work with these).

Other approach, also quite unsuitable for laptops, is
Blender. But anyway who does 3D on a laptop?

Possibly these tabs could behave as windows if undocked
(w/drag'n'drop), then people would be able to decide whether
to spread their tools all over their multi-screen xinerama,
or to compact everything down on a smaller screen.

Just my centimes;

regards

Sveinn í Felli

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Marcel Wiesweg <[hidden email]> wrote:

> I take it that showfoto is the image editor part of digikam? I am using
> kubuntu 7.10 and the kubuntu default shipped digikam version 0.9.2
> (KDE3.5.8) and in that version the image editor has no name, just "image
> editor".

Showfoto is a standalone program, but it shares the essential parts with the
image editor integrated into digikam. (No database usage in showfoto, most of
the code is common) So the discussion here applies equally well to both
ShowFoto and the Image Editor.

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Thank you, Marcel, I just looked at the pictures in the PDF and recognized a lot of elements from the editor I use so I guessed it was somehow related. It is good to know that I didn't write that entire e-mail on a failed assumption ;-)

 

-

Thomas

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

"Sveinn í Felli (IMAP)" <[hidden email]> wrote:

Other approach, also quite unsuitable for laptops, is
Blender. But anyway who does 3D on a laptop?

Who does 3D on a laptop? I do.....

At work I have two computers running windows, 1 is a desktop with dual head display running WinXP64 and the other is a laptop with a wide screen running WinXP32. I am working with "3d" most of the time (although it is not graphical 3D modelling it is quite similar in terms of vizualisation and tool needs).

As my current project does not exceed the memory limitations of a 32bit system I use my laptop more than the desktop these days. 32 bit systems have a lot of advantages wrt software and compatibility even on WinXP. Also the program I use offer enough flexibility for me to work efficently with my laptop screen real estate. (This is also a matter of adapting personal habits). Another great advantage with the laptop is that it goes where I go and I can always get my job done.

On the other hand I can do things on my workstation that is simply not possible on the laptop - mostly "big computing" and high-end vizualisation.

 

Most of my ideas on what to do with Digikam and kipiplugins in terms of development are derived from applications that I have used at work. I am happy to contribute with my experience.

 

 

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

"Sveinn í Felli (IMAP)" <[hidden email]> wrote:

Possibly these tabs could behave as windows if undocked
(w/drag'n'drop), then people would be able to decide whether
to spread their tools all over their multi-screen xinerama,
or to compact everything down on a smaller screen.

I second that!

 

-

Thomas

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users