Exports to Wrong Output Directory

[Zian]

Steps to Reproduce:

1. Start RawTherapee
2. Right-click on an image and select "Put to Queue" from the context menu.
3. Go to the Queue tab; screenshot: https://onedrive.live.com/redir?resid=87EA02230C32BE40!747&authkey=!AKLg1zlKbbETZL4&v=3&ithint=photo%2cpng
4. Click on the drop down menu next to "Save to folder:"
5. Select Other
6. Click on a folder (e.g. "Out"); screenshot: https://onedrive.live.com/redir?resid=87EA02230C32BE40!748&authkey=!ALOEjCGSQBhx9Hs&v=3&ithint=photo%2cpng
7. Click "Open"; screenshot: https://onedrive.live.com/redir?resid=87EA02230C32BE40!749&authkey=!AKvtJ0LWyDfYOio&v=3&ithint=photo%2cpng
8. Click "Start Processing"
9. The folder will be placed in the folder that contains "Out" rather than being saved inside the "Out" folder.

Context:

Branch: default Version: 4.2.1 Changeset: 46bed7f4dc9d Compiler: gcc 4.8.1 Processor: generic x86 System: Windows Bit depth: 64 bits Gtkmm: V2.22.0 Build type: Release Build flags: -m64 -mwin32 -mthreads -msse -msse2 -mtune=generic -fopenmp -Werror=unknown-pragmas -mwindows -DNDEBUG -O3 -Wno-aggressive-loop-optimizations Link flags: -mwin32 -mthreads -static-libgcc -mtune=generic -mwindows -s -O3 OpenMP support: ON MMAP support: ON

[Beep6581]

When you click "Open", the currently opened folder is used instead of actually opening the one you selected. This is clear, in Linux at least, as the path in the button shows this. Does the path in the button in Windows show otherwise?

[Beep6581]

My "Save to folder" button in the Queue tab showed my Hald CLUT folder probably because I saved something there before. I restarted RT, clicked on the "Save to folder" button in the Queue tab to choose a different folder, and doing either of these things triggers the bug:

• the combobox contains "tmp" because I saved /tmp as "tmp" in the bookmarks panel on the left side of the "Save to folder" window, this one http://i.imgur.com/vzHb8xr.png and clicking on "tmp" changes the label on the "Save to folder" button in the Queue tab but it doesn't actually seem to use that folder while saving.
• let's say I have a folder structure /foo/bar/woof/. In the "Save to folder" window if I navigate to /foo/bar/ and click on the woof folder once, its selected, and I click the Open button. The "Save to folder" window closes and the "Save to folder" button in the Queue tab shows "woof", but again it doesn't actually save to woof but to /foo/bar/

[adamreichold]

I think the branch fixes by this using the file chooser's get_filename instead of get_current_folder method. This should implement the expected behaviour as the file chooser is in folder mode and the documentation says

If the file chooser is in folder mode, this function returns the selected folder.

about that. (However in both cases described above, the label actually said e.g. /foo/bar when I selected /foo/bar/woof/ on my system and before the change so I am not a hundred percent sure if the fix is complete.)

[heckflosse]

@adamreichold : Doesn't work as expected on my system. Image is still saved in the current folder, not in the 'mouse'-selected folder.

to reproduce:

create folder 'foo' with subfolder 'foo1' put image to queue. Save to folder 'foo'. Works put image to queue again. Choose save to folder 'foo1' by selecting 'foo1' and 'Open' (no doubleclick) Now there should be one save image in 'foo' and one in 'foo/foo1' but there are two in 'foo'

Ingo

[adamreichold]

@heckflosse Hhhmmm, seems I have no luck reproducing stuff I break today: I tried again the exact sequence above again and it work as expected here. Could this be a Windows versus Linux Gtk+ behaviour difference? Does Gtk+ use native file dialogs on Windows?

[heckflosse]

@adamreichold : I'll try that on my linux box now

[heckflosse]

@adamreichold : Branch: fix-save-to-folder-button Version: 4.2.477 Changeset: 18cda52568fbde4a4c6cda2b38b21d98c5c811bf Compiler: cc 4.8.4 Processor: x86_64 System: Linux Bit depth: 64 bits Gtkmm: V2.24.4 Build type: release Build flags: -std=c++11 -march=native -Werror=unused-label -fopenmp -Werror=unknown-pragmas -O3 -DNDEBUG Link flags: -march=native OpenMP support: ON MMAP support: ON

works fine on Linux but not on windows. I'll investigate further tomorrow

Ingo

[Hombre57]

Does Gtk+ use native file dialogs on Windows?

No, it uses Gtk ones.

[adamreichold]

@heckflosse I think I understand now why the fix did not work on Windows. There is a currently Windows-specific code path as we do not use Gtk::FileChooserButton on the other platforms. I did adjust that one as well, rebased and pushed an updated branch. Could you retest?

Also rather strange: I was unable to properly test this on Windows XP since using Gtk::FileChooserButton always crashed on me with

(rawtherapee.exe:1444): Gtk-CRITICAL **: gtk_tree_model_filter_get_value: assertion 'GTK_TREE_MODEL_FILTER (model)->priv->stamp == iter->stamp' failed

(rawtherapee.exe:1444): GLib-GObject-WARNING **: ../../glib-2.46.2/gobject/gtype.c:4272: type id '0' is invalid

(rawtherapee.exe:1444): GLib-GObject-WARNING **: can't peek value table for type '<invalid>' which is not currently referenced
Segmentation fault

when using Gtk::FILE_CHOOSER_ACTION_SELECT_FOLDER. (The access violation itself is within Gtk+'s internal event handlers.) Can somebody confirm this? I will look into debugging Gtk+ w.r.t. this on Linux. Maybe we should remove that on all platforms?

[adamreichold]

On the other hand, it seems like this does not crash on Linux using Gtk+ version 2.24.29 even when using the above combination?!

[heckflosse]

@adamreichold : I retested and now it works. Great, thank you :-)))

Ingo

[Beep6581]

Works correctly here, tested in linux using 2.24.28-r1

[adamreichold]

I'll commit this to master then?

[heckflosse]

+1 fro me to commit

[adamreichold]

Closed by commit b343b9a7b3bd13c5b37155296efe703fd2168d8e.