Bug 100770

not sure what you want. can you give more details?

For example: One d/l all pictures from a camera to an album. After that one wants to split those pictures into several albums.
At the moment one would have to create all the albums and then select and move the pictures.

It would be very handy, if one could simply select some pictures and create a new album with them by right-click > Create New Album For Selected Pictures. The normal create album dialogue comes up and one enters the data, after clicking ok, the selected pictures are automatically moved to the new album.

Yes, indeed. I was just going to propose the same thing. As of now, you not only have to create the album itself, but you must first select the root folder before clicking the "create album" button in the toolbar. Otherwise, the new album gets created into your temp folder. It'd be nice to be able to select the pictures, right-click them and create a new album (in the root picture folder) out of them.

The thing about the "create new album" button creating it automatically inside the current folder could be maybe generalized to have it always (not only when right-clicking for new album) ask in which folder you want to create it (kind of like in Firefox's "Add Bookmark" dialog box). It could default to creating it into the curent folder, and have one of those unobtrusive ">Details" dialog expanders with the folder option in it.

*** This bug has been confirmed by popular vote. ***

Isn't it what tags are for? I would be in favor of closing that wish.

Hmm, but using tags does not allow to move images into a new directory,
so I don't see how these should be the solution to this wish.

In particular, as long as 
http://bugs.kde.org/show_bug.cgi?id=142774
is not solved, there is no way to move images between albums, right?

It is possible to copy images to new directory using temporary tags.

This bug is about:

1. selecting pictures
2. right-click the selection and select the "create new album for selection"
3. enter a directory-name and click on ok, which moves the pictures to the new directory/album.

Any tag involvement would not fullfill this simplicity known from e.g. juk or amarok.

What would be the best way to specify the new album?
(Somehow it has to be ensured that this is below the digikam root directory...)

Also it is worth mentioning, that the right mouse popup-menu is
pretty full ...

Regarding the context-menu. One might the show the feature only if more than one image is selected. Yet one might also remove the "show picture" item, since left-click on the picture is obvious enough.

Regarding the othe rissue: bug 149572 would solve that issue.

Left click on image is configurable. User can choose: view or edit. It
would be probably good thing to make it one entry depending on current
settings. When left click action is edit, in context menu should be view
and vice versa.

I would be for closing this bug. We cannot populate context menu ad infinitum to fulfill any wish.

There are two ways two copy any selection of images to new directory (as of 0.9.4svn)

1. Create directory anywhere
2. Create some selection of image, eg. tags, and select few of them
   a) now you can drag them on Albums tag, it will open and later drop them on previously created album
   b) Ctrl-C (or context menu-> Copy) these images, navigate to previously created album Ctrl-V (or context menu-> Copy); with this way you can create album *after* Ctrl-C (or menu)

And my hobby ;) this is one of perfect things for Actions menu mentioned in
Bug 88932

Waiting 24h for discussion and without significant input closing as WONTFIX.

Fine for me... Arnd ?

Gilles

As announced.

I think this would be a really nice (and kind of intuitive/expected/obvious) feature, and given the votes and attention it got, I think it's wrong to just dismiss it like this. If the only problem is the context menu getting big, that is another problem, and Burmeister has given at least some indication as to how to solve it.

> I think this would be a really nice (and kind of
> intuitive/expected/obvious) feature, and given the votes and attention it
> got, I think it's wrong to just dismiss it like this. If the only problem
> is the context menu getting big, that is another problem, and Burmeister
> has given at least some indication as to how to solve it.


And if you are looking for items to remove from the context-menu:

- "View", absolutely redundant since one only has to click a picture. dolphin 
does not have a "Open" item in the context-menu either.
- "Rate", since it is in the status-bar.

Hmm, seeing that this wish indeed already has 90 Votes, shows
that this is a feature which people would like to have
(including the very fact that someone took the time and pain to go
through the bug-tracker ...).

On the other hand I think that c#13 proposes a good and not too difficult
alternative ...

So as usual it is not easy to balance between useful features and
too many features (eg too many menu entries ...).

Still, the decision of closing should be re-considered in view
of the new comments
((even though I would fear that this would stay unimplemented
for another while, just because of way too many bugs/wishes
for digikam and not enough people helping with the code ... ;-))

to #13

> "View", absolutely redundant since one only has to click a picture. dolphin
> does not have a "Open" item in the context-menu either.

hum, agree. i'm waiting others viewpoint.

> "Rate", since it is in the status-bar. 

no. status bar is rating filter, not rating assignement widget

Gilles Caulier

#19

You have two basic actions on image: preview, edit. When clicking you perform one, context menu should be for second. Yes, in context menu could be one action but depending on state of clicking option it should perform second action. Ah, I am repeating my own #12.

Agree Mik. For this one, it's simple to implement

Gilles

Yesterday I just wished I had this feature, so I give it my votes, too.
I had an album with 5000 images (I got them by a friend, all in one folder). I just copied them into a temp folder and wanted to sort them the way I like.
But this is really hard in current implementation.
I browsed through the images and selected some. Then I right-click on the folder I want the new images to be in, but the problem is you lose focus on the current folder.
So your selection is gone and you even don't watch the folder anymore, but the one you right-clicked on.
This becomes really annoying after some time.
Sure you can go through all 5000 images, think of album names, create them first and use D&D later to sort them. But this is no good workflow.
Selecting a range of images, right-click->"create new album" would be really handy. It could open the dialog we get when we import images, you create a new folder in there and hit enter. The images are moved into the new folder.

So again, +20 from me :-)

Andi

Created attachment 31035 [details]
selection => new album patch

This patch will allow to move selected images into a new album. If more then one image is selected, you will get a new context menu entry to create a new album from the selection.

We have some issues with moving / copying files I guess (told you by mail some days ago).
If you move only three images, it takes more then 10 seconds until the have been moved. I guess there are some updates in the database going on. We should at least display a wait cursor or some other indication, because otherwise the user will not recognize that something is going on right now.
It feels "broken" the way it is.

This is not only true for this patch, but for normal D&D etc...

Andi

Andi,

No problem for me with this patch. let's go...

Gilles

Ok I moved 190 images now, digiKam is still doing stuff... since 4 minutes!!!
I think we need to check callgrind here, something is weird. You can not use digiKam since it is using 100% of your CPU all the time.

Gilles, Marcel,

any idea? Again this is not related to this patch, it is related to normal file operations in digikam.

SVN commit 922161 by aclemens:

If multiple images are selected, add a new context menu entry to move the selected images into a new album.

BUG:100770

 M  +46 -0     albumiconview.cpp  
 M  +2 -0      albumiconview.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=922161

(In reply to comment #19)
> to #13
> 
> > "View", absolutely redundant since one only has to click a picture. dolphin
> > does not have a "Open" item in the context-menu either.
> 
> hum, agree. i'm waiting others viewpoint.

I also think we can eliminate "View" and even "Edit" from the context menu. I personally never ever used "View", and "Edit" can be reached from toolbar as well.

Andi

One more comment on context menu:
Some of the entries currently do not make sense when multiple images are selected and should be disabled or even removed from the context menu:

- View
- Edit
- Rename
- Set as Album Thumbnail
- Find Similar

What do you think? I suggest to remove View and Edit completely and the other actions listed above when multiple images are selected.

Andi

"Edit" can be kept in ImageView mode though, because it makes a little bit more sense. You see the image in full size and you decide: "Hmm... need to change the color balance here.."

But in thumbnail view I would remove the action...

Created attachment 31042 [details]
actions patch

disable some actions if multiple images are selected, remove Edit and View from thumbnail view context menu

I personally use "Edit" from the context menu both in the thumbnail view and the ImageView mode. It's just less mouse movement compared to using "Edit" from the toolbar. Also, I think removing "Edit" from the thumbnail view but keeping it in the ImageView would create an unexpected inconsistency in the interface.

(In reply to comment #32)
Also, I think removing "Edit" from the thumbnail view but keeping
> it in the ImageView would create an unexpected inconsistency in the interface.

This wouldn't be the only inconsistency :-D
I personally don't understand why the imageview has "Slideshow" in the context menu, but thumbnailview has not. I think it would make much more sense if it was the other way around (or in both context menues).

The removal of the Edit actions was just a suggestion and my opinion, because I usually press F4 (I mostly use keyboard shortcuts in the applications I use).

Any more opinions on that?

Andi

Same here. As Michael, i always use Edit and View from context menu...

But, i'm agree, if multiple selection is done, all actions relevant of single selection need to be disable.

Also, your new action to create album from selection need to be duplicated to main menu.

Gilles

View too?
In the previous post you agreed to remove it...

But I guess removing View isn't good either, what if the user has "Open in Image Editor" turned on? In this case, you need view in the context menu.

(In reply to comment #34)
 > Also, your new action to create album from selection need to be duplicated to
> main menu.

Hmmm this makes me wonder again if we shouldn't add the already defined actions from the actionCollection into the context menues. I mean this is the purpose of the actionCollection. It makes it much easier to disable the actions in mainmenu and context menu when only one image is selected.
I started to work on this months ago, but stopped since you was not sure if this can make problems (although it shouldn't...).

Andi

>View too?

yes.

>In the previous post you agreed to remove it... 

I don't remember...

>I started to work on this months ago, but stopped since you was not sure if this >can make problems (although it shouldn't...). 

yes, i know. I'm not sure if this change will not have any side effect. Perhaps we can do it after RC2, when we branch 0.11.

Marcel, what do you think about ?

Gilles 

Maybe instead of disabling the actions on multiple image selection, we should remove them?
I have a huge context menu here, but only 40% of the actions are usable. It makes it harder to read and it could be easily trimmed down to all enabled actions only.

What do you think?

All this time I thought that you guys were talking about completely removing options from the context menu which don't make sense for multiple selected images. If I compare that to disabling (gray-ing out) options, then I would definitely choose completely removing them.

Additionally, I should mention that the toolbar buttons (View,Edit,etc), which make sense only for a single image, should be disabled when multiple images are selected.

I actually WAS talking about removing Edit and View from context menu ;-)
Disabling was meant for actions that are not suitable for multiple selected images.
I still would suggest to remove all the actions from the context menu that are not usable for many images. Just to cleanup the menu visually.


(In reply to comment #38)
> Additionally, I should mention that the toolbar buttons (View,Edit,etc), which
> make sense only for a single image, should be disabled when multiple images are
> selected.

This is not possible at the moment, at least not with easy. If we use all actions from the actionCollection in the context menu, you can disable to ones in menu and toolbar quite easily.

SVN commit 922349 by aclemens:

quick fix: disable actions from toolbar and menu if multiple images are selected.

CCBUG:100770

 M  +6 -0      digikamapp.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=922349

SVN commit 922358 by aclemens:

add action "New Album from Selection" to mainmenu

CCBUG:100770

 M  +1 -1      albumiconview.h  
 M  +10 -0     digikamapp.cpp  
 M  +2 -0      digikamappprivate.h  
 M  +2 -1      digikamui.rc  
 M  +5 -0      digikamview.cpp  
 M  +3 -2      digikamview.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=922358

SVN commit 922359 by aclemens:

use same name as mainmenu action

CCBUG:100770

 M  +2 -2      albumiconview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=922359

Hmm I liked the old action name better, it is more meaningful I guess.

Old: "Move Selection to Album"
New: "New Album from Selection"

Using the old version the user knows that the images will go into some folder, that can also be newly created.

Using the new version the user might think that you can only create new albums, and you are also not informed that the images will be moved into the album (which should be obvious though).

But when we want to use the old version again, I think I have to put the action into Image menu, right?

Andi

(In reply to comment #36)
> yes, i know. I'm not sure if this change will not have any side effect.

Gilles,

we use actionCollection in the context menu of the editorwindow:
http://lxr.kde.org/source/extragear/graphics/digikam/utilities/imageeditor/editor/editorwindow.cpp#182

So actually this should work fine. Maybe it is not possible for every action, but most of them should work fine. This is not too important right now, but for the future it might help enabling / disabling actions globally and maybe save some code as well.

Andi

Andi,

Let's a try to factorize action from context menu with actionCollections.

Also, i'm agree to remove single selection action from context menu when multiple selection is done.

Gilles

SVN commit 922570 by aclemens:

Remove disabled actions from context menu when multiple images are
selected.
To save us from many if-statements, we add all actions to the context
menu in the first place and remove them again later on. This way we have
one common place to disable / remove actions which makes the code more
easy to read.

CCBUG:100770

 M  +11 -17    albumiconview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=922570

Created attachment 31081 [details]
use actionCollection if possible

I tried to use the actionCollection in most of the cases, but now there is one little problem: In the context menu there is a checkbox next to "View" action, since it is a KToggleAction. This looks stupid, but there is no way to get rid of it. You can set the action "not checkable", but then the toolbar icon will look different.

I tried to clean up the context menu method and created some dedicated functions to create the menues. I think it is much easier to read now.

If we don't want to use actionCollection (if you think it isn't better then before), I still would suggest to clean up the context menu method. It is really hard to read right now.

Created attachment 31087 [details]
merged with trunk

trunk has changed a lot, updating patch...

Andi,

Patch sound work fine here.

A similar factoring with lead action collection need to be done into imagepreviewview.cpp:

http://lxr.kde.org/source/extragear/graphics/digikam/digikam/imagepreviewview.cpp#328

I'm not sure yet how we can factoring tags/rating and kipi sub-menu methods here. perhaps using static methods.

There is also something to do in the same way from Light Table:

http://lxr.kde.org/source/extragear/graphics/digikam/utilities/lighttable/lighttablepreview.cpp#346

Gilles 

Some of my relatives visited me today (well they are still here :-)) and I showed them the "new" context menu, because I don't like this checkbox in there.
Funny none of them even realized that it is there :-)

One positive aspect seems to be that keyboard shortcuts are displayed now in the context menu. My uncle didn't even know you can edit images by pressing F4.
He always right clicks on an image and chooses "Edit...". Now he is using the keyboard shortcut all the time :-)

So what do you think about the checkbox next to "View"? Maybe we should use a QAction again? I think it looks terrible.

Andi

To make it more logical having a checkbox in the context menu, we should add the view action to the context menu of imagepreviewview as well. So the action will be in there and the checkbox will be checked.
This will replace "back to album" I think, right?