Bug 184444

Created attachment 31340 [details]
view broken

What do you expect to be shown?
If you want a sequence number, check the check box. If you want time and date, check the checkbox.

Again, why the catty comments? Do you think I don't SEE the checkboxes right there? Honestly, don't treat bug reporters like fools and you'll not annoy the userbase that is trying to help developers. I created a bug report and an annotated screenshot that clearly shows the issue. Everyone in my office understood the bug report, so I know it's not a bad report.

If you look at the screenshot I sent in (let me double-check), yes, it should be very obvious what the problem is (I even circled it):

When you put a prefix on something, it should show the final image name, and it's not. If I "prefix" something with blah, then the resulting filename should be "blah_img_5822.jpg", but in this view (if you see the giant black circle marks I made) EVERY filename has the prefix, and just the prefix, in what is to be the "final" filename. Obviously, to anyone who looked at this, it's just that someone probably called the wrong variable, and should be calling what var stores "prefix + filename" and not "prefix".

So, to sum up, in the screenshot: top left image should result in a filename called "MineFalls-img_1645.jpg", since "MineFalls-" is what I selected as the prefix. Instead, the filename shows "MineFalls-" on *every filename*.

Brendan,

We are not payed to work with open-source development. We cannot accept injure or other dumy words like you said. You must respect all team member who try to _HELP_ you !

Gilles Caulier

Yes, I know. I actually work on OSS as well, and have for over a decade.

The reply was written by my coworker, who is triaging bugs with me. He's a bit blunt, so sorry if he was a bit too direct. I'll talk to him about being so forward.

But honestly, the response to this bug has been fairly "dumb user", since the suggestion was to check the checkbox! I can certainly see why my coworker responded the way he did. Respect flows both ways, and hiding behind "We don't get paid" when not respecting the work the bug submitter puts into it, is probably not very helpful.

>When you put a prefix on something, it should show the final image name, and
>it's not. If I "prefix" something with blah, then the resulting filename should
>be "blah_img_5822.jpg", but in this view (if you see the giant black circle
>marks I made) EVERY filename has the prefix, and just the prefix, in what is to
>be the "final" filename. Obviously, to anyone who looked at this, it's just
>that someone probably called the wrong variable, and should be calling what var
>stores "prefix + filename" and not "prefix".

No. the renaming rule don't care about old file-names provided by camera. And this is true for KDE3 release (just checked).

The file renaming rule is :

- a prefix (can be empty)
+ a sequence number (optional - here this is the problem)
+ date & time (optional)
+ camera name (optional)
+ a suffix (can be empty)

In all case, original file name is never add to file renaming.

In your screen-shot, a sequence number option is disable. All files have the same name. This is the problem. In fact, sequence number must always enable, else file renaming is not suitable.

Gilles Caulier

I guess Brendan is right, a prefix should be a prefix, so something that is added to the old name. Same for suffix.
We should at least add a checkbox for custom renaming to add the old filename again.
Since I rename my files with krename (because I automatically add folder names etc to the filename) I never complained about this, but it is actually a "big" usability problem.
Adding a checkbox should be easy, if you want I can do it (at least for 0.11, 0.10 is string frozen now).

Andi

The easiest way to set custom names would be with a custom string (I guess we have a bug report for that):

"bla_%f_%n.%e"

with %f for old filename
%n for sequence number
%e for extension or something like that.

This way you can define the order of the elements for the renamed image.
If you want a name like this:
bla_NUMBER_DATE.jpg
it is not possible at the moment, only
bla_DATE_NUMBER.jpg

Andi,

Yes, you can try of course...

Gilles

SVN commit 930395 by aclemens:

Add an option to use old filename when customizing the filename when
downloading from camera.
This is by far not perfect, we should think of a different way of
renaming (like we use in the custom date format dialog).

CCBUG:184444

 M  +2 -1      cameraiconview.cpp  
 M  +1 -0      cameraiconview.h  
 M  +29 -11    renamecustomizer.cpp  
 M  +3 -2      renamecustomizer.h  


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

As Yoda would say: "To Andi, you listen."

Krename was my usability example on this one.

I'm working on a simple parser to have custom renaming... well "simple" and "parser" doesn't go well together :D
Right now I will only add the options we can set right now, nothing fancy, just a LineEdit.
But this will all go into 0.11 branch, 0.10 is frozen...

@12, Andi

Maybe not immediately but you could make it expendable in future for use with many different codes for: filename, various dates, any metadata, etc.

And also shared a rename config panel with Batch Queue Manager will be great.

I plan to do a Bach Rename tool in BQM.

Gilles

A shame that this can't be shared with krename or gwenrename.

"A shame..." great! It's better and better...

Gilles Caulier

Andi,

It still valid with 0.11.0 ?

Gilles

About comment 15:
Well with the new "Open With" submenu in the context menu this should be possible, unfortunately I can't test it because krename exists only as a KDE3 version in Archlinux and I don't want to install all those old dependencies, just to test this.
But you can open files with any application now, so this should work.

About the original issue: I guess this is not fixed.
But it can be handled with the ManualRenameWidget, but this is not what the bugreport originally was about.
I will need to check this one again.

Andi

What about this one?
We now have an easier to use ManualRename utility, that is capable of doing the renaming that can be done with the custom renaming options, plus it can be extended to have metadata support etc.
I would say we can close this one, and maybe even remove the custom widgets someday.

What do you think?

I'll close this one now...