[Bug 225471] New: Change Digikam to follow usability guidelines

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

           Summary: Change Digikam to follow usability guidelines
           Product: digikam
           Version: unspecified
          Platform: openSUSE RPMs
        OS/Version: unspecified
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: [hidden email]
        ReportedBy: [hidden email]


Version:            (using KDE 4.4.0)
Installed from:    openSUSE RPMs

I love the features of Digikam. It can do alot of things other programs cant
do, but the User Interface is horrible. Everything is just thrown together with
no clear design or usability guidelines. I came up with a mockup to show what
needs changing in Digikam's current layout and how it can be designed to be
more usable.

http://www.kde-look.org/content/show.php/Digikam+Usability+Improvements+Mockup?content=119622

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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


Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]
          Component|general                     |Usability
            Version|unspecified                 |1.2.0




--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

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


Marcel Wiesweg <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]




--- Comment #1 from Marcel Wiesweg <marcel wiesweg gmx de>  2010-02-04 18:31:27 ---
I am not willing to accept "the interface is horrible" and some mockup thrown
at us.
Please detail what you intend to change, and give references to the guidelines
you mention.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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





--- Comment #2 from Supreme1012 <supreme1012 gmail com>  2010-02-05 01:32:50 ---
Well you need to accept it regardless. Mockups are one of the only ways users
have to show a developer good changes to the interface. It allows users to help
with the development process. My mockup on KDE-Look.org is not finished(Im
still making revisions) but it also has explanations for changes in the
description as well as why. If you'd like me to clarify my reasonings Im more
than willing to respond to criticisms and make changes to the mockup if
necessary. Digikam needs to come up with a vision for what it wants to do and
how it should do it. I suggest Digikam conduct some user research studies. As
for references, I work on Accounting Information Systems and have taken classes
that cover interface usability and KDE has a set of guidelines(very incomplete)
for applications on Techbase thats interesting. Also, I compared Digikam's UI
to several other Photo Management applications.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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


Fri Duh <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]




--- Comment #3 from Fri Duh <friiduh gmail com>  2010-02-05 13:36:15 ---
This idea could be done by distributors because I myself dont feel that
professionals would like to see photo ratings, tags, creating date only on
sidepanel one by one function.

When we do have rating, tags and modification time under the thumbnail, a user
can see right away the information from multiple photos without clicking
trought them or doing a "blind filter" by filtering the view to see what photos
would have 3, 4 or 5 stars.

And we do have thumbnails listing possible to place by name, date and rating.

Now for users who want this (they can be distributors etc) suggested thing.
They can go to settings and turn off all metadata shown under thumbnails. Then
they can resize the thumbnail size to smaller and they end up to view that has
no empty space between photos.

But rows and colums are tied to have at least the 1:1 format when disabled all
metadata under thumbnails, because the photos can be horizontal or vertical
position. http://imagebin.ca/view/reS8PG-C.html

We already have had the discussions about some metadata being top of the
thumbnails on album view, example the rating stars. And we have ended up to
have the current way for that to not block the thumbnails what is very
important information on album view, like the rating and other metadata itself
if user wants to see them.

The sidepanels in the mockup has the normal usability flaw that does not allow
hiding them. I am not willing to use a digiKam on 1280x800 or under (netbooks
etc) resolution screens if I can not hide the sidepanel when needed. I already
hide them even with over 1920x1200 resolution because sometimes I do not need
other side.

And what someone says "dublicate" like having tags on left and right, I say it
a feature because I can do mure accurate searching and filtering together. Like
first choosing a whole tag parent from left and then from right to do more
accurate filtering with parent, childrend or just selected. Something what I
can not do on any other photo management application (lightroom included).

What I think is that we should continue doing what we are doing, making a sane
defaults what works for the most people but does not stop skilled users to get
their needed tools. The starting wizard is great example of that what ask basic
questions and makes default settings by that. What we could do, is think is
there any way to include 1 question more without that comes a too long wizard.
Very difficult question to answer.

Because we are trying to offer a photo management application for:

Home users:
* Takes photos with cellphones and Pocket cameras (less DSRL owners)
* Owns a normal computer, usually normal laptop with small screen and one
hard-drive
* Receive photos from friends
* Wants to share own photos
* Wants to make a slideshow for friends
* Does basic tagging
* Does basic fixing like removed redeyes, crops, rotates and basic lighting.


Amateurs:
* Owns DSLR and might take hundreds of photos on day
* Owns external drives, mayby other computers and second monitor.
* Receive photos from friends
* Maintain own gallery
* Does complex searches among photos (might own GPS locator)
* Manipulates photos and edit them usually in complex ways (HDR/Panorama,
fixing spots and perspective)
* Makes backups trought digiKam

Professionals:
* Owns multiple DSLR's and might take a thousands of photos on day
* Owns multiple computers (for journeys and home/studio etc), multiple external
drives (backups, different album locations on network shares etc) and multiple
monitors (Not so rare to have 2-3 big screens where one has album and one
editor while third one showing the last shot photo from camera)
* Receive photos from other photographers
* Maintain multiple own galleries
* Shows multiple slideshows of own work to customers
* Does very complex searches and edits lots of metadata (copyrights etc)
* Maintains multiple different versions from same photos.
* Does need to have complete control to all RAW-processing.

We just end up that we can not have one simple GUI for everyone. We can not
integrate image editor to photo management window. We can not just hide
metadata and other important features to context menu or to sidepanels and just
show "pictures" like user would be browsing the own music collection.

And I say we do very good job on balancing between all these three lines. We do
need help to find problems and find a solution for them, but the solution need
to take all three different groups of users in care.

We are not trying to fight against Gwenview or F-Spot. They have own home
users. But we are not either trying to be too complext for basic user.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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





--- Comment #4 from Supreme1012 <supreme1012 gmail com>  2010-02-05 18:43:42 ---
Great response! Are you the same person as Fri13 on kde-look.org by any chance?
I've been thinking a lot about showing the file name, rating, etc underneath
the thumbnails in Album view and I think Ive changed my mind. I think it SHOULD
be available, but I think it should be turned off by default(or just show
simple information like name and date created as the default) and you can later
go into the settings and specify the metadata you want shown below/above the
image. I'm not going to make a mockup of metadata in album view though, at
least not anytime soon.  

“The sidepanels in the mockup has the normal usability flaw that does not allow
hiding them.”

That's why I added the show/hide “sidebar” buttons to the toolbars on the left
and right sides (Same as how Firefox's Bookmark button works). This actually
saves the user a lot of horizontal space. In the current setup its impossible
to get rid of the half-inch on each side that displays the vertical tabs. I
will be experimenting with tabs at the top of the panel though, as that is how
its “supposed” to be according to usability guidelines.

“And what someone says "duplicate" like having tags on left and right, I say it
a feature because I can do more accurate searching and filtering together. Like
first choosing a whole tag parent from left and then from right to do more
accurate filtering with parent, children or just selected.”

The same thing can be done by entering the tag's name into the search bar and
then searching through the results. This is better than scrolling through a
long list of tag names, and that list should already be included in the Tags
sidebar on the right-hand side anyways. You're showing multiple views of the
same list of tags, whereas you can combine it to make the tags selectable as a
group as well as editable in the same Tab view. Also, you should not need to
show two Marble globes in the sidepanel in order to do map searches and
geolocation.

“We can not integrate image editor to photo management window.”

I think having the “Editor” tab listed may confuse some people as to what would
be available from that view. Im not proposing adding ANY new image editing
abilities to Digikam, and it would not be a mashing of Digikam and Showfoto's
capabilities. The Image tab would display those simple editing options that are
available already in Digikam, but are not located together in a cohesive or
easy to use way. Most of those options are currently located under “Tools” in
the main menu and some in the context menu.

“What I think is that we should continue doing what we are doing, making a sane
defaults what works for the most people but does not stop skilled users to get
their needed tools.”

I DO NOT want to get rid of functionality in Digikam. Digikam's features are
what makes it such a great program, but I want to get rid of the layout design
clutter, duplication, and unstructured menu and view organization. I'm not just
saying “Hey! This doesnt work, go fix it!” Im working on coming up with
solutions to how to fix things. The biggest problem at this point is that it
just takes too long to make the mockups and then explaining how each thing
works. BTW, the changes Im proposing are NOT drastic changes to Digikam. It'll
still be toolbar, right and left sidepanels, and main middle view and keeps all
the same features it has now.

“We just end up that we can not have one simple GUI for everyone. We can not
integrate image editor to photo management window.”

I dont think this is true. The way Digikam looks right now it would maybe be
impossible to come up with a great default view that works for everyone, but I
think that is a flaw in Digikam's basic layout that needs to be addressed. I
think I can come up with a GUI that has a great simple default view that lets
everyone do the most frequent photo management tasks, while still keeping the
flexibility to show and hide information, change the tabs/toolbars/panels, and
maintain overall control of how digikam looks and feels without interfering
with those advanced tools and tasks that advanced users want. But it has to
start by putting tools/options in the right places and having a clear idea of
how Digikam should look and work. Right now Digikam is not PROGRESSING, and a
start for this progression should come with the porting the view to Qt4. But I
want you guys to PLAN!!! how things should look and work in the best possible
layout and design.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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





--- Comment #5 from Fri Duh <friiduh gmail com>  2010-02-05 19:42:41 ---
"That's why I added the show/hide “sidebar” buttons to the toolbars on the left
and right sides (Same as how Firefox's Bookmark button works). This actually
saves the user a lot of horizontal space. In the current setup its impossible
to get rid of the half-inch on each side that displays the vertical tabs"

The horizontal space is not the problem. The vertical space is the problem. And
the functionality what we get whit current setup is better than what can be
achived by adding a "Hide sidepanel" button on toolbar.

a) User can hide the toolbar and is not forced to have it.
b) Single click show/hide functionality with wanted sidepanel without need to
first show the panel.
c) Two buttons less in the toolbar (there is space problem on smaller screens
when toolbars having a text side).
d) Possibility to have a tabs on top of current tools (tabs like Exif, XMP
etc).

"I will be experimenting with tabs at the top of the panel though, as that is
how
its “supposed” to be according to usability guidelines."

That is one thing what I am suggesting for current setup, that we move as much
possible some functions in showFoto to up. Like now there is great job done to
get the preview buttons and view tools to one collected place away from the
image view area. Here is now very old mockup
http://saukonpaa.com/projects/mockups/digikam_sidepanel_firstdraft.jpeg
That is from showFoto for tools moved from menu (still visible) to sidepanel
where tools are located (it was not polished at all). The idea is to use more
and more the sidepanels so the user can even hide the menubar (what is now
possible with Ctrl+M) because tools could be moved away from there. But that is
one (big) usability suggestion what I am making and I have problems with it
because digiKam developers are too fast to follow while they fix bugs etc. Like
think that you have the filter panel at bottom of the tools sidepanel. From
there you can just type "curves" or "black" and you would get to right panel
the tools what would do something to that. And buttons would be even at
different sizes for different size screens. Idea is that user can if wanted to
hide all bars and have only photo + sidepanel open. But that is other subject.

And the current sidepanel implentation is not liked by some people because one
small problem, the text is sideway and while trying to find out a way to get
rid of that, we end up to have bigger problems. Sometimes it is wiser to have a
small problem to gain bigger features somewhere else.

"The same thing can be done by entering the tag's name into the search bar and
then searching through the results. This is better than scrolling through a
long list of tag names, and that list should already be included in the Tags
sidebar on the right-hand side anyways."

It is not same thing. That is a blind-filtering. User is trying to remember
tags and actually is searching tags and not filtering them. The tag tree is
powerfull because you can see the available tags. The filtering is to help when
you already remember/know what you are looking for. Thats why the one single
"superbar" to search tags, metadata, locations etc does not work because it is
like Googling trought your own database without knowing what data there is
possible to be.

And both tags bars on left and right have different functions on them. The left
side is like selecting single information. A one tag, one album, one map
location or one date. On the right side you get the information but the tag is
cloned there to allow you manage the filtered data what you got from left
search. They are not duplicate work but they completes each other.
And this way we can solve one big problem what comes when starting to have lots
of data, user can search just the specific data from wanted place without
getting wrong results. Example you have tags of every person by their name.
Then you have renamed files to have names of the persons. Then there is map
places and albums with same kind names. Now if you search in one "superbar"
search a wanted tag or person. You get everything in front of you. We should
make a somekind drop down list or selection that allows user to choose what
data it will be searched. Like on Google page has Images, Maps, Books, News,
Internet etc. So now when we have simple filter/search functions on every
wanted place (tags, map, albums, dates) user does the filtering in the first
place by using the wanted tool.

This is one problem what caused that we need to have a normal search and a
advanced search separated.

"You're showing multiple views of the
same list of tags, whereas you can combine it to make the tags selectable as a
group as well as editable in the same Tab view. Also, you should not need to
show two Marble globes in the sidepanel in order to do map searches and
geolocation."

They are not about duplicating the same search. Again example. You do a
location search on left by dragging a box around wanted area. Now you get all
that area photos in front of you. How do you filter just one person from the
massive amount of photos? Example I could want only to be seen photos where
this one person is but no one else. Now I can do it from right sidepanel. The
idea is to give the user simple but powerfull tools what the user itself can
mixture to get wanted photos in front of them. We can not build a "black box"
full of photos in front of user what she/he then needs to search with quessing
and remembering all what he wants. He needs to have possiblity to see the
choises and it makes the management lots easier.

"but I want to get rid of the layout design
clutter, duplication, and unstructured menu and view organization."

I see your point. But where you see duplication and unstructured menu (there is
always polishing on the menus) I see simple and powerfull tools what I can mix
together. That is the one feature what many other photographers who use
Lightroom in daily use just amaze when I can pull wanted photos in matter of
seconds without wrong results. It is like having two hands and not just one ;-)

"Im working on coming up with
solutions to how to fix things."

That is good thing what you are doing. And discussing about them is good so
that we can find new ideas and solutions what to think.

"The biggest problem at this point is that it
just takes too long to make the mockups and then explaining how each thing
works."

So it usually does. But mockups can be for developers a good "frame" where they
can build their own ideas later.

"BTW, the changes Im proposing are NOT drastic changes to Digikam. It'll
still be toolbar, right and left sidepanels, and main middle view and keeps all
the same features it has now."

Yes it still would be but as I tried to explain, the functionality to use the
features would change, even thet the UI itself would not be changed (like the
Amarok 2 got the context-view middle of the collection and playlist what many
disliked).

"But it has to
start by putting tools/options in the right places and having a clear idea of
how Digikam should look and work."

That is one current big problem. We have two sidepanels with both having great
functionality and supporting each other (as I explained) and just having one
tool (like tags) to do everything in one place (only one tag panel/tab with
mixed functuons) is not always the best choise.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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





--- Comment #6 from Supreme1012 <supreme1012 gmail com>  2010-02-08 05:13:26 ---
I added a new screenshot showing the "Tags" sidepanel. Please check it over and
let me know what you think!


Here's my responses to Fri Duh's last post:

"The horizontal space is not the problem."

You say this because the way the options currently are presented means that the
sidepanels have long lists of features and options. Im working on consolidating
the sidepanels so that there is plenty of room, and having more horizontal
space means more space for viewing your photos, or for when you have two images
side by side like with Light Room.

"User can hide the [current] toolbar and is not forced to have it."

I disagree. With my design you can press a button, hit shortcut keys, or use
the menu to remove the sidepanels completely, but the way it is currently for
Digikam the toolbar on the left and right sides of the screen always take up
space.

"c) Two buttons less in the toolbar (there is space problem on smaller screens
when toolbars having a text side)."

Small screens are in no way Digikams target market. But besides which, having
it display as "Icons only" will show only two small icons on each side, and if
you'll notice, I changed around the toolbar so that its showing the most
commonly used controls and this takes up less space than Digikam's current
Toolbar.

"d) Possibility to have a tabs on top of current tools (tabs like Exif, XMP
etc)."

If designed right, extra tabs should not be needed. But I will grant that
having all that extra space to stick things is nice, its just not very user
friendly or well designed.

"That is one thing what I am suggesting for current setup, that we move as much
possible some functions in showFoto to up."

That's good! After making the mockups I believe that having the search and
filter bars at the top really helps make things look better and more consistent
with the rest of KDE.

"And the current sidepanel implentation is not liked by some people because one
small problem, the text is sideway and while trying to find out a way to get
rid of that, we end up to have bigger problems. Sometimes it is wiser to have a
small problem to gain bigger features somewhere else."

Just because the solution hasnt been found yet doesnt mean it cant be fixed! Im
very optimistic about this. I know I'm receiving literally no support but I
have pretty clear ideas about how this could work, and work really well and
I'll continue to make more mockups to show the developers a way to work out the
mess.

"The tag tree is powerfull because you can see the available tags. The
filtering is to help when you already remember/know what you are looking for."

Please check out my most recent screenshot that shows how the "Tags" sidepanel
could work at both managing tags as well as filtering through them. Please let
me know what you think.

"And both tags bars on left and right have different functions on them. The
left side is like selecting single information. A one tag, one album, one map
location or one date. On the right side you get the information but the tag is
cloned there to allow you manage the filtered data what you got from left
search.

The Left sidepanel is for finding and selecting images. The Right sidepanel is
for viewing and manipulating the images properties (eg: tags, metadata,
caption, crop, red-eye). My design is the same basic goal as Digikam's, but its
presented in a clearer way, while still maintaining all of the same functions.

"Example you have tags of every person by their name. Then you have renamed
files to have names of the persons. Then there is map places and albums with
same kind names. Now if you search in one "superbar" search a wanted tag or
person. You get everything in front of you.We should make some kind of drop
down list or selection that allows user to choose what data it will be
searched."

That is why the Albums tab searches through your folders, and the Places tab
will search through your locations and the Tag tab on the right will let you
search through your tags. The "Search Bar" will be configurable to decide what
results get displayed, but sometimes you want to find ALL of those things in
the same place, and the "superbar" would make this possible as well as simple.
Thank you for the idea of configuring the Search results though, I will add
that into my mockups.

This is one problem what caused that we need to have a normal search and a
advanced search separated.

"You do a location search on left by dragging a box around wanted area. Now you
get all that area photos in front of you. How do you filter just one person
from the massive amount of photos?"

You can enter their name in the search and it will filter the "Places" results
to show the photos of that person by filename, tag, or metadata. Or if you're
using tags for people, you can click on the tag representing them and get the
photos that way. You keep saying "to find people" but currently Digikam doesnt
have special controls for people in images. Are you saving peoples names as
tags and searching for them in your tags? Is that what you mean?

"simple and powerfull tools what I can mix together"

Powerful is right! I love Digikam's features, but it is not anywhere near
simple. And I'm working on designing them to work even more closely together,
with less panels and windows and clearer menus and controls.

"That is good thing what you are doing. And discussing about them is good so
that we can find new ideas and solutions what to think."

And thank you for your feedback! I've already made several changes based off
your comments. Please continue to let me know if you see anything that you
think would not work or work well.

"Yes it still would be but as I tried to explain, the functionality to use the
features would change, even thet the UI itself would not be changed"

Functionality is what I'm working towards. Changes do take a second to adapt
to, but good changes can make adapting worth it.

"That is one current big problem. We have two sidepanels with both having great
functionality and supporting each other (as I explained) and just having one
tool (like tags) to do everything in one place (only one tag panel/tab with
mixed functuons) is not always the best choice."

The best choice is what I'm trying to find. Look over what I did with the
"Tags" panel and tell me what you think. I believe that I have successfully
combined the functionality of the two current sidepanels into the one "Tags"
tab.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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





--- Comment #7 from Supreme1012 <supreme1012 gmail com>  2010-02-14 03:46:43 ---
I believe I've found a solution to the "Editor" tab problem. Fri was arguing
that Editing controls shouldnt be in digiKam. Whereas, I was trying to keep it
all together in one sidepanel, but I can understand wanting to have digiKam for
photo management and Showfoto for editing. The biggest problem I had with this
setup was with how to batch edit multiple images, but I believe Ive found a
solution.

Remove the "Editor" tab from the mockup and replace it with a "Faces"(or maybe
People) tab instead. I thought of this when I saw you talking about adding in
face recognition and people tagging.

All photo editing tools will then be moved into Showfoto(I'll start doing
mockups for Showfoto eventually)

Batch Editing will be done by selecting multiple images in digiKam and hitting
the "Edit" button. The selected photos will be placed in thumbnail view(or just
opens a special Batch processing window, lmk which would be best) of Showfoto
and can be batch edited, light table, or w/e in the Showfoto window.

I'll make some mockups in the next week or so to better display the changes.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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





--- Comment #8 from Fri13 <friiduh gmail com>  2010-02-14 17:49:32 ---
"Batch Editing will be done by selecting multiple images in digiKam and hitting
the "Edit" button. The selected photos will be placed in thumbnail view(or just
opens a special Batch processing window, lmk which would be best) of Showfoto
and can be batch edited, light table, or w/e in the Showfoto window."

That is what I have being designing now about a year. You can select a puch of
photos and just bring only those to the image editor for processing (just like
they can now being opened in showFoto but needed to have in Image Editor as
well). But still there is need for having a simple batch job without image
editor what the Batch queue Manager is great for.

What is needed to do is to get a underlaying technology of workflow processing
to work faster that you can fast just set wanted edits to photos and send them
as queued to process in background while working with all other tools. I have
somewhere older mockups of that.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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


Supreme1012 <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID




--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Version Fixed In|                            |1.4.0

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Usability                   |Usability-Ergonomy

--
You are receiving this mail because:
You are the assignee for the bug.