This bug is already open for some time so expect it's not that clear.

I would like to have similar functionality: At this moment all downloaded files from the camera are stored in a directory with as name the date and time of the time of the download (of course inside the directory you have specified yourself).

What the poster of this bugreport probably wants (and so do I) is that the files are stored in a directory with as name the date when the photo was shot. I think this information is available inside the EXIF information or maybe it's even provided as the time when the picture was written to the flash memory of the camera.

So suppose I have to pictures on my camera. One shot yesterday (26-AUG-2007) and one today (27-AUG-2007). If I download these via gthumb tomorrow, I do not want the both in a directory named 28-AUG-2007 (or 2007-08-28--21.05.40 to be precise if I did it five past nine). I WANT these two pictures stored in two different directories, namely 2007_08_26 and 2007_08_27.

This would also prevent duplicate photos stored in different directories (if they are similar then they could just be ignored).

I would be happy to help, participate or test a possible solution, I just have not coded anything yet in gthumb.

Maybe this UI should be re-worked a bit. Something like:

- Folder dialog: Destination (the main dest folder)
- Combo box: Group into sub-folders based on:
             - Exif date (yyyy-mm) - the default
             - Exif date (yyyy-mm-dd)
             - Current date/time (yyyy-mm-dd--hh.mm.ss)
             - no grouping (no sub-folders)

If an exif-date-mode is selected, but no exif date tag is present, the image would be placed in the Destination folder.

There would be no provision for the manually naming of "films". That would be handled by the folder selection dialog (new folder if required).

I think the "film" distinction / icons could be removed. I'm not sure that serves any purpose.

- Mike

(In reply to comment #2)
> Maybe this UI should be re-worked a bit. Something like:
> 
> - Folder dialog: Destination (the main dest folder)
> - Combo box: Group into sub-folders based on:
>              - Exif date (yyyy-mm) - the default
>              - Exif date (yyyy-mm-dd)
>              - Current date/time (yyyy-mm-dd--hh.mm.ss)
>              - no grouping (no sub-folders)
> 
> If an exif-date-mode is selected, but no exif date tag is present, the image
> would be placed in the Destination folder.
> 

Yeah, that would be great. Some people use their camera every day and need a new folder for every day (most of the times this equals a typical event like visiting the Zoo, or meeting grandparents) so I would even suggest making that the default, but I would certainly also promote have them grouped per month just to prevent an explosion of folders for a user.

Would this be complete new functionality or is it (underground via for instance Gconf-editor settings) already built in and does it only requires some extra UI code?

Roalt,

The importer code would have to be modified (src/dlg-photo-importer.c) to read the dialog values, read the exif tag if required, build the appropriate folder names (and create them if they don't already exist), and put the files in the right folder.

The glade UI would need to be changed as described above.

The libgthumb/preferences.c|h and typedefs.h files would need to be modified to support the new preferences and delete the old ones.

Lastly, we'd need to scan the source code and see where it refers to "film" and purge that.

So, no, we can't just enable it with a secret gconf setting :-)

Want to try writing a patch?

- Mike

Yes, in fact I have already a working patch now, but I want to see if I can clean it up.

I think we need another boolean trigger to indicate that you do not want duplicate  imported files, as importing them a second time now generates duplicates starting with "1.IMG_3455.JPG", "2.IMG_3455.JPG", etc.

(In reply to comment #5)
> I think we need another boolean trigger to indicate that you do not want
> duplicate  imported files, as importing them a second time now generates
> duplicates starting with "1.IMG_3455.JPG", "2.IMG_3455.JPG", etc.

That worries me a little bit. The current scheme keeps the UI simple, and makes sure that no photos are lost. Adding another UI element / preference that makes the import less robust might not be a good idea.

- Mike 

Yes, you are right about possible confusion on the extra option. 

However, for many people who do not delete their photographs during import (to prevent loss) might up ending with lot of duplicates especially with those 2 GB or more memory cards.

Maybe it's a good idea (for me?) to post another bug-report issuing the finding and removal of duplicate files?

One issue I'm still investigating is to retrieve the EXIF information prior to the saving of the imported photo. Having this information beforehand would prevent an extra 'moving' of the picture into the right sub-folder.

> Maybe it's a good idea (for me?) to post another bug-report issuing the finding
> and removal of duplicate files?

Sure, go ahead. Perhaps gthumb should pop up a dialog offering to delete duplicate files (with the same base name, same date, same size) if it detects duplicates. 

 
> One issue I'm still investigating is to retrieve the EXIF information prior to
> the saving of the imported photo. Having this information beforehand would
> prevent an extra 'moving' of the picture into the right sub-folder.

Hmm, I'm not sure there is a good way to do that. You might need to import to a /tmp folder first...

- Mike

Created attachment 99054 [details] [review]
Patch to fix this bug

This patch will provide a SubFolder 4-choice option to the store to store the imported photos. It also removes the "film" field as it was suggested by a comment on bug 431187. This patch can be applied on gthumb 2.10.6

Yes, I did it!

Can someone test this patch? please apply it with:

tar -xjf gthumb-2.10.6.tar.bz2
cd gthumb-2.10.6
patch -p1 ../gthumb_improve_import_bug431187.patch
(and then the usual configure, make && make install)

Although it's my first attempt to fix a gnome related program, I did my best to keep it in-line with existing code. See the comments above for its functionality.

Except for the deprecated "film" option, the original date/time subfolder is still there so I suggest that this patch will go into the main development tree.

Any comments welcome.

Cool!

I'll try to review it this weekend - it will take a while.

A quick check shows that it doesn't use gthumb's normal tmp-file-creation routines. That will need to be changed. (gthumb's routine check for the tmp location with the most free space, and are careful with security. I forget the details...)

Since it changes the UI, it would be applied against svn trunk (instead of the gthumb-2-10 branch). Do you know how to check out trunk?


- Mike

> A quick check shows that it doesn't use gthumb's normal tmp-file-creation
> routines. That will need to be changed. (gthumb's routine check for the tmp
> location with the most free space, and are careful with security. I forget the
> details...)

I am indeed using the system tempnam() to get a unique filename in case of grouping pictures per day or month. A file_move()  from gthumb self is used to move it to the right position

> 
> Since it changes the UI, it would be applied against svn trunk (instead of the
> gthumb-2-10 branch). Do you know how to check out trunk?

I know subversion but not the location of the gthumb svn trunk.

I think I would use get_temp_dir_name to make a tmp_dir, and move the image there (without renaming the base filename). Then move the file to its final destination, and remove the tmp_dir using local_dir_remove_recursive. That will keep it consistent with the rest of gthumb. (There are some security issues with temp file creation described in bug 358894, so that's why we do it that way.)

An example of get_temp_dir_name use is in src/rotation-utils.c:apply_transformation_jpeg.

gnome svn is described here:
http://developer.gnome.org/tools/svn.html

To check out trunk:
svn co http://svn.gnome.org/svn/gthumb/trunk your_gthumb_dir

It can also be viewed online at:
http://svn.gnome.org/viewvc/gthumb/trunk/


- Mike

Created attachment 99623 [details] [review]
import grouping patch

Here is a modified patch against trunk.

The tmp file handling is more gthumb-ish now.

The imported handles movie files correctly now (read mtime if no exif tag is present).

Some UI strings have been tweaked.

Please give it a test, Roalt.

- Mike

I tested the patch for all the four different options and it is good!

The different sub-folder options are renamed to reflect what happens, which is better. The directories are also a bit better named, using dashes instead of underscore which is more compatible with the 'old' date/time behaviour.

A subsequent import on the same set will generate the number-prefix file and will not overwrite existing ones, just as discussed here.

As far as I'm concerned: this fix should be incorporated into the default gthumb and thus gnome development tree.

(And the STATUS of this bug may be changed to anything but unconfirmed).

OK, the patch has been committed to trunk, svn rev 2075:

http://svn.gnome.org/viewvc/gthumb?view=revision&revision=2075

Thanks for taking the time to code this useful feature, Roalt! I've added you to the AUTHORS file :-)

This will eventually appear in 2.11.0 and later releases, although I'm not sure when the main developer (Paolo) plans to make a release from trunk. So checkout trunk from svn for now if you want this feature...

- Mike

(In reply to comment #2)
> There would be no provision for the manually naming of "films". That would be
> handled by the folder selection dialog (new folder if required).
> 
> I think the "film" distinction / icons could be removed. I'm not sure that
> serves any purpose.

I don't think the removal of the "film" is a good idea. It is still very useful if you have a different naming scheme.

For instance, I have organized my photo collection in subfolders by date and event (YYYYMMDD EVENT). When importing images from my camera, the destination folder is always the toplevel folder and I enter the name of the subfolder in "film". Since I usually download photos after every event, this works really well for me.

Now, with this patch, I'm forced to use the file chooser and create the subdirectory manually. I assume that new folder is also remembered (instead of my toplevel folder), which means I also have to navigate the file hierarchy every time. That is much more work than it used to be.

I propose to re-add the "film" textbox underneath the grouping combobox to provide a means to enter a custom naming scheme. Something like

Group into subfolders: <combobox>
 - No Grouping -> textbox is disabled
 - By Date (month/day/...) -> textbox contains the format
 - Custom -> textbox is enabled

Format: <textbox>

Jef,

I'm OK with that - are you able to provide a patch?

Maybe in the future the custom textbox could accept format codes for the date, if someone feels motivated to code it (it could probably re-use some of the file-renaming code).

Someone suggested appending a comment to the auto-generated date-based folder-names to handle your usage case, in bug 452764. That is, it would generate folder names like 2007-04-03_comment_text, or something similar. I'm not sure that's any better or worse... thoughts?


- Mike

I think using a format string to make the subfolder name is not that difficult, it would even be quite powerful. If you specify something like "%y-%m-%d Citytrip to Amsterdam" it would generate a string for today as "2007-11-28 Citytrip to Amsterdam".

However, in may be 'complicated' with respect to the generic GNOME User. I'm not sure if there are similar solutions elsewhere in other gnome applications?

.. Or we could consider parsing the string for %<something> values a somewhat hidden feature and just add it as a custom subfolder name.

Roalt,

I don't see a problem putting format strings in the custom text field. The details can go in the "Help" documentation, for power users, so that we don't clutter up the UI and scare "average" users.

When the automatic-date modes are enabled, the textbox can show the matching format string (grayed out) so that users get the idea that format strings are available.

The rename tool uses some format strings already.


- Mike

Mike, Jef,

I agree with this option. The option open issue here is what format strings are allowed? I think we should conform to the strftime() format but for which format strings? 

Shall we rely that strftime() will do all conversion and thus allow all those conversion options or should we limit them to a fixed set?

I guess any strftime-parseable string would be fine... taking care to check that the result is actually a valid filename (%n/newline and %t/tab would be bad).

The date formats would work on the extracted metadata time (or mtime, if no exif time is present), rather than the current time or anything else.

- Mike

(In reply to comment #19)
> I think using a format string to make the subfolder name is not that difficult,
> it would even be quite powerful. If you specify something like "%y-%m-%d
> Citytrip to Amsterdam" it would generate a string for today as "2007-11-28
> Citytrip to Amsterdam".
> 
> However, in may be 'complicated' with respect to the generic GNOME User. I'm
> not sure if there are similar solutions elsewhere in other gnome applications?
> 
> .. Or we could consider parsing the string for %<something> values a somewhat
> hidden feature and just add it as a custom subfolder name.
> 

Hi all,

First thank you guys for implementing the enhancement proposed in this bug report. Great job !
I didn't try it yet, but it looks good.

As for the format string customization, it's really a good option to have.
The example given here ("%y-%m-%d Citytrip to Amsterdam") could be extended this way.
You could have in your custom format textbox something like :
%y-%m-%d %p
where %p is a description to fill in with a dialog box, prompted to user, for each day for example.

Good example is done in cam2pc, a similar tool (not available for linux).
See the following screenshot for more details:
http://www.nabocorp.com/cam2pc/shots.php?id=20

Cheers,
Matthias

OK, I've added a basic "Custom Subfolder" feature to trunk.

It still needs:
- additions to the schema file
- additions to the help file
- checking on the custom folder name, maybe a better strftime buffer

Please test.

- Mike

I finally managed to test the trunk !
(well the one from yesterday)
It was hard to get all the correct dependencies.

So I tested this feature. 
The combobox works well. Import is OK.

But the odd thing is that in gthumb itself,
if I click on a picture or folder it exits with core dump :/
Whatever picture, whatever folder... it's weird...

Maybe I missed some killer warning...
Thing is I don't have much experience in open source compilation...

Anyway I'll try your new adds Mike, thanks.

Cheers,
Matthias

Matthias,

What distro are you using (Fedora 8, etc...)?

Can you generate a backtrace to see what is crashing?

- Mike

Ubuntu 7.10 Gutsy

$ uname -a
Linux hobbes 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

As for backtrace I'll have to google it up, since I never did it.
Maybe you have a few hints ?

Matthias

Sure, install the gthumb-dbg package (http://live.gnome.org/GettingTraces/DistroSpecificInstructions).

Then run gthumb from the console (not by clicking a desktop icon). Hopefully a backtrace will be dumped to the console when the program crashes. The backtrace shows what the program was ding just before the crash.

If that doesn't work, try:

gdb gthumb
run
(and after it crashes)
thread apply all bt

- Mike

Possible future improvement:

In the import dialog, add a "Post-import script" combo box for people who
want to process imported files immediately (e.g., rename files with a unique
serial number).

See bug 502309.

- Mike

*** Bug 502542 has been marked as a duplicate of this bug. ***

Matthias

> But the odd thing is that in gthumb itself,
> if I click on a picture or folder it exits with core dump :/
> Whatever picture, whatever folder... it's weird...

I had the same problem. Turned out I didn't have libopenraw and exempi installed - there are packages for SuSE and Ubuntu, but I couldn't spot any for Fedora. 

The gthumb code will merrily compile without them but then breaks when you try to load an image and it attempts to look up the xmp data. I tried a ./configure with the disable flags set for both but that, oddly, didn't help.

Good luck!
Andrew

Oops, the exempi stuff is new and not-quite-fully-tested...

Anyway, please try the latest svn rev (2122 or higher) and see if the exempi problem is fixed. 

- Mike

Andrew,

Fedora 8 does have libopenraw and exempi.

yum install exempi* libopenraw*

- Mike
 

Thanks for the inputs.

I'll try them asap.

I tested trunk 2123.
It works fine.

Import dialog :
- good improvement
- nice custom option
- help is up to date, but I'm using French Ubuntu, so new section is not translated : I'm willing to translate, where can I help on that ?

exempi and libopenraw "bug"
- it's gone, I can browse directories and images fine
- I compiled without having them installed

Still nice to have :
- be able to add a description field, see my comment #23

Thanks !
Matthias

*** Bug 310393 has been marked as a duplicate of this bug. ***

(In reply to comment #35)
> - help is up to date, but I'm using French Ubuntu, so new section is not
> translated : I'm willing to translate, where can I help on that ?

See the po/fr.po file, and then read:

http://developer.gnome.org/projects/gtp/l10n-guide/
http://developer.gnome.org/projects/gtp/
http://www.traduc.org/gnomefr/Presentation
http://l10n.gnome.org/module/gthumb

 
> Still nice to have :
> - be able to add a description field, see my comment #23

I don't think this is worth the effort and added complexity. This is best left for the browser view.

- Mike

(In reply to comment #37)
> > Still nice to have :
> > - be able to add a description field, see my comment #23
> 
> I don't think this is worth the effort and added complexity. This is best left
> for the browser view.
> 
> - Mike
> 

What do you mean by "left for the browser view" ?

IMHO it's worth the effort :)
I think people are looking for that kind of feature.
As you mention in comment #18 : bug #452764
Also bug #479987 (we can follow up this feature in this bug report, since it's narrowed down to this feature only)

Of course it adds complexity, by having additional pop-ups to prompt the user for description, etc.
But maybe in the long term it means reorganizing the UI.

My thoughts :
- Have some options moved to a preference tab : grouping option, grouping format
- If you use the "description per day" option (%e or %p...), 
  a different import dialog will open up per day, 
  with only the pictures of the day displayed, 
  with a textbox to fill in the description.
  Then you import.
  You would have a more simple import dialog (less option displayed) per day.
- Else one import dialog with all the pictures, 
  still more simple (less option displayed)

These are only thoughts...

Voila :)
Matthias

OK, further discussion is moved to bug 479987.

- Mike

Since development in bug 479987 has halted since December 2007 and probably will not resume "any time soon" (http://bugzilla.gnome.org/show_bug.cgi?id=479987#c3), would it be possible to incorporate the patch as tested here in the current release in the mean time?

It would be a great step forward to have at least this functionality.

This functionality is in the trunk version, which can be obtained from the git repos.

It will appear in 2.11.x, when it is released "some day".

Other issues are blocking the release of 2.11.x (bug 583464).

- Mike

I would also like to comment (again) on the implementation of this bug into the main 2.11.x : For me it's a bit frustrating to see that I did work about almost 2 years ago to help to improve gthumb and not seeing it back into the main tree. I really would like to help, but this doesn't help my motivation to do so.

I'm fully aware that there might still be bugs that will make gthumb not the perfect program, I also know that it's difficult to maintain a open source project between all other work (I know). But at this moment I cannot get gthumb (trunk version) to work so there is no way to help to solve any open bugs. Or do I miss out and can someone give me a howto to get the trunk version running under (for instance) Ubuntu Jaunty?

It would be really helpful to get a bit of direction what needs to be solved, or a time-schedule what can be done to get this bug implemented. As an alternative, we should consider back-porting if the current trunk version is stuck for much longer.

Or is this process now handled by newly initiated Bug 583464 ?

I totally agree with Roalt (frustration + project management constraints).

As far as I'm concerned, I try to report bugs and patches, but it's true I have to stay on trunk to get them. Which means compilation from source after each distro release upgrade (I use Ubuntu). It's not a problem as such, but it's true, as "simple" contributor, we lack visibility on project direction, and thus it's hard to get motivated for further contributions.

gthumb is definitely lacking a central place for project management, like a developer mailing list for example.
The bug tracking system is good but is now showing its limitations.
Or maybe I/we missed something?

Cheers,
Matthias

Hi guys,

Yes, gthumb has been stuck in a rut for a while. I am trying to give it a push by listing what I see as blocker bugs in bug 583464: 

http://bugzilla.gnome.org/showdependencytree.cgi?id=583464

The main blocker is the gio migration, but that is nearing completion.

The other big tricky blocker is the slideshow bug 501512. Someone contributed a series of patches, which I committed, and then they vanished and left us hanging without fully working code. So, I either have to revert it (which is a mess, due to the other work that has happened) or get someone clever to finish the work that has started. This is a little frustrating!

I am not the gthumb project owner. Paolo B is, but he hasn't been active lately. I'm not sure why.

So... basically, I am the only person doing sustained maintenance on gThumb, and I am not a gifted programmer. I am also frustrated that my nifty new code has not hit a release yet. Unfortunately, the only way to make this work available is... to do more work.

Roalt, what build issues are you having with trunk? gThumb should build without much trouble. You know about the migration to git, right? To checkout, use:

git clone git://git.gnome.org/gthumb

Matthias, I'm not sure there are enough people to warrant a mailing list. If people aren't active in bugzilla, why would they come to a mailing list?


- Mike

A mailinglist could be useful for discussing things that are not directly related to a particular bug. Not everyone is subscribed to each topic, so I think a mailinglist might be better than bugzilla for discussing stuff like a roadmap, getting feedback from end users, etc.

Yes, after thinking about it some more, a mailing list is probably a good idea. I'll get one set up through gnome (it might take a few days). Everybody promise to subscribe? I don't like talking to myself :-)

- Mike

Note: I was typing my message, while Mike send his.. I post it anyway:
----------------------

Jef got the point:
a mailing list will cover project management topics, which bugzilla can't.

There's no developer "area".

Let's take it from the official web site.
You browse to http://gthumb.sourceforge.net/
The only developer "aspect" is the feedback page: http://gthumb.sourceforge.net/feedback.html

This brings you here. You contribute to bugs. Period.

Actually there's the sf.net project page
http://sourceforge.net/projects/gthumb/
which does have a ML in fact :-)
http://sourceforge.net/mailarchive/forum.php?forum_name=gthumb-devel
which looks long abandoned (and spamed)

So here we are :-)
ML is a common way for developers to discuss on the development of a project.

Paolo,
you're comments are welcomed ;-)

Cheers,
Matthias