wxDirDialog::GetPath() doesn't return the user-selected path

[MichaelClerx]

The following snippet always prints the default path, never the user-selected one:

dlg = wx.DirDialog(self, 'Export', '/home/michael')
ok = dlg.ShowModal() == wx.ID_OK
if ok:
    print dlg.GetPath()

I'm using a 64 bit version of Fedora 17 (with Gnome 3.4.2) and using the packages from Fedora's repositories.

It worked when I used it some months ago, but now I have two machines with similar installs where the method fails. The FileDialog's GetDirectory() method has also started displaying this behaviour but that can be worked around by using os.path.dirname(file_dialog.GetPath())

[vadz]

Works fine for me with 2.9.4 but I don't have exactly the same configuration to test against. Please retest with 2.9.

[MichaelClerx]

Ok, I've been trying but the library has a lot of dependencies so it's taking some time to build.

Right now the build script is complaining about not being able to find GStreamer, although it's definitely installed:

checking for GST... configure: WARNING: GStreamer 0.10 not available, falling back to 0.8
checking for GST... configure: WARNING: GStreamer 0.8/0.10 not available.
configure: error: GStreamer not available
Error running configure
ERROR: failed building wxWidgets
Traceback (most recent call last):
  File "./build-wxpython.py", line 378, in <module>
    wxbuild.main(wxscript, build_options)
  File "/home/michael/install/wxPython-src-2.9.4.0/build/tools/build-wxwidgets.py", line 359, in main
    "Error running configure")
  File "/home/michael/install/wxPython-src-2.9.4.0/build/tools/build-wxwidgets.py", line 74, in exitIfError
    raise builder.BuildError(msg)
BuildError
[root@thinkpad wxPython]# yum list gstreamer*
Loaded plugins: langpacks, presto
Installed Packages
gstreamer.x86_64                                                                         0.10.36-1.fc17                                             @koji-override-0/$releasever
gstreamer-devel.x86_64                                                                   0.10.36-1.fc17                                             @fedora                     
gstreamer-plugins-bad-free.x86_64                                                        0.10.23-7.fc17                                             @updates                    
gstreamer-plugins-bad-nonfree.x86_64                                                     0.10.22-3.fc17                                             @rpmfusion-nonfree          
gstreamer-plugins-base.x86_64                                                            0.10.36-1.fc17                                             @koji-override-0/$releasever
gstreamer-plugins-good.x86_64                                                            0.10.31-4.fc17                                             @updates                    
gstreamer-plugins-ugly.x86_64                                                            0.10.19-1.fc17                                             @rpmfusion-free             
gstreamer-python.x86_64                                                                  0.10.19-3.fc17                                             @koji-override-0/$releasever
gstreamer-rtsp.x86_64                                                                    0.10.8-2.fc17                                              @koji-override-0/$releasever
gstreamer-tools.x86_64 

Not to be rude, but if it works in 2.9, is your response going to be "Then use 2.9"? Because I'd much rather find the origin of this behaviour in 2.8. I'm guessing it's not a problem in wxPython or even wxWidget (since both versions I have installed seem to have been built sometime in January, and this would have affected quite a lot of users since then), but I don't have the know-how to dig into the underlying components myself.

[vadz]

Replying to MichaelClerx:

Right now the build script is complaining about not being able to find GStreamer, although it's definitely installed:

You should be able to just turn off wxMediaCtrl. Also, look at config.log to see why exactly does the test fail.

Not to be rude, but if it works in 2.9, is your response going to be "Then use 2.9"?

Not really but I personally don't work on 2.8 since a couple of years already so if the bug is fixed in 2.9, I won't be trying to fix it. So while you definitely can use 2.8, my personal advice would definitely be to use 2.9.

[MichaelClerx]

Okay I found the missing gstreamer devel package, but now the install halts on.. win_gtk?

creating build/temp.linux-x86_64-2.7
creating build/temp.linux-x86_64-2.7/src
creating build/temp.linux-x86_64-2.7/src/gtk
gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -DSWIG_TYPE_TABLE=_wxPython_table -DSWIG_PYTHON_OUTPUT_TUPLE -DWXP_USE_THREAD=1 -UNDEBUG -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -Iinclude -Isrc -I/usr/local/lib/wx/include/gtk2-unicode-2.9 -I/usr/local/include/wx-2.9 -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/python2.7 -c src/helpers.cpp -o build/temp.linux-x86_64-2.7/src/helpers.o -pthread -O3 -pthread
src/helpers.cpp:32:36: fatal error: wx/gtk/private/win_gtk.h: No such file or directory
compilation terminated.
error: command 'gcc' failed with exit status 1
ERROR: failed building wxPython.

[vadz]

This looks like a wxPython bug, hopefully Robin can look into this, I don't really know anything about this myself, sorry.

[MichaelClerx]

Replying to vadz:

This looks like a wxPython bug, hopefully Robin can look into this, I don't really know anything about this myself, sorry.

Thanks for your help though, it's much appreciated :)

[biaji]

Same problem here. And I have submit a bug report in fedora's bugzilla at  https://bugzilla.redhat.com/show_bug.cgi?id=849692

Name : wxPython
Version : 2.8.12.0
Release : 2.fc17
Architecture: x86_64

[robind]

Replying to vadz:

This looks like a wxPython bug, hopefully Robin can look into this, I don't really know anything about this myself, sorry.

There is a patch available for wxPython 2.9.4.0 that takes care of the missing include files in wxGTK builds. It is at  http://sourceforge.net/projects/wxpython/files/wxPython/2.9.4.0/wxPython-src-2.9.4.1.patch/download

Oh, and for the record, wx.DirDialog.GetPath is working fine for me on Ubuntu (recent but not newest) with both wxPython 2.8.12.0 and with 2.9.x from SVN trunk.

[MichaelClerx]

Could you try the newest? I've been getting the error in code that worked fine on fedora 16. If there's anything I could do to help, please let me know.

[sciurius]

Maybe this is related to a similar problem that I encounter using wxPerl.

In a DirDialogue, when you click on a directory in the Places pane, this directory will be shown in the dialog. The path on top of the dialog shows the correct path. Note however, that nothing is selected in the main (right) pane and the Location field is empty. Now click [Open] and the dialog will return the default path.

This happens with Wx 2.8.12 and Wx 2.9.3.

When I try this with Fedora 16, the selected path is returned, as expected.

System information: Fedora 17 x86_64 with all updates as of 2012-08-23.
Perl 5.014002, wxPerl 0.9903, Wx 2.008012

Alternative: CitrusPerl 5.14.2, wxPerl 0.9906, Wx 2.009003

[sciurius]

It looks like DeVeDe ( http://www.rastersoft.com/programas/devede.html) shows the same problematic behaviour, and it uses 'raw' Gtk, not wxWidgets...

[gertjanzwartjes]

The problem seems to lie in the way how you select a directory. If you go inside the directory you want to select and then click ok, the returned path will be the default path.

However, if you do not go inside the dir you want to select, but actually select it and then click ok, GetPath() will actually return the selected directory.

This is the behavior I get with Arch Linux, Gnome 3.4.2 and wxPython 2.8.12.

[MichaelClerx]

Nice catch! I can confirm this is what happens on Fedora 17, Gnome 3.4.2, wxPython 2.8.12

[vadz]

OK, so can we just chalk this up to confusing GTK UI and close it? Or does anybody still think there is a bug here?

[MichaelClerx]

Still a bug. It's not the way the UI is intended to work on GTK.

I just found a post on an Archlinux board that deals with the same issue:  https://bbs.archlinux.org/viewtopic.php?pid=1151508

Some quotes:

I've confirmed that reverting back to gtk2-2.24.10-3 fixes the problem. Upgrading to 2.24.11-2 reintroduces it. I can't figure out what the issue is though. I wrote a test GTK program which uses the same file chooser control as wxWidgets and it works fine on both GTK2 versions

...

So the problem seems to stem from the way wxWidgets uses GTK. I have checked the GTK git repo on the 2.24 branch and there have been a few recent changes to the file chooser control (gtkfilechooser*.cpp), but none that seem like they would've affected this behaviour.

[vadz]

This is downright mysterious: the diff between 2.24.10 and 2.24.11 is small and the only possibly relevant change I see is the addition of "unmap" signal on the toplevel but I have no idea how could it affect us nor what to do about it. And I don't have 2.24 to debug this...

[gertjanzwartjes]

I would also say that this is certainly a bug; if you go all the way into a directory and then press ok, it is very confusing that the default directory will be used. Selecting the dir instead of entering it before pressing ok is just a workaround I would say.

However mysterious it is indeed...

[sciurius]

Since it is gtk related I filed a but for Fedora.
 https://bugzilla.redhat.com/show_bug.cgi?id=853399

[obfuscated]

This is definitely a bug. It is easily reproducible using the dialogs sample.

Using the following patch, I was able to pinpoint where does it happen:

Index: src/gtk/dirdlg.cpp
===================================================================
--- src/gtk/dirdlg.cpp  (revision 72775)
+++ src/gtk/dirdlg.cpp  (working copy)
@@ -47,6 +47,8 @@
         chdir(filename);
     }

+    wxGtkString str(gtk_file_chooser_get_filename(GTK_FILE_CHOOSER(widget)));
+
     wxCommandEvent event(wxEVT_COMMAND_BUTTON_CLICKED, wxID_OK);
     event.SetEventObject(dialog);
     dialog->GetEventHandler()->ProcessEvent(event);
@@ -152,7 +154,13 @@
 void wxDirDialog::OnFakeOk( wxCommandEvent &event )
 {
     if (!gtk_check_version(2,4,0))
+    {
+        wxGtkString str1(gtk_file_chooser_get_filename(GTK_FILE_CHOOSER(m_widget)));
         EndDialog(wxID_OK);
+        wxGtkString str2(gtk_file_chooser_get_filename(GTK_FILE_CHOOSER(m_widget)));
+        int a=5;
+        a+=5;
+    }
     else
         wxGenericDirDialog::OnOK( event );
 }

The problem happens after the call to EndDialog in OnFakeOk. Using the debugger?I verified that the value of str1 is correct and str2 is wrong. I don't know what exactly happens in EndDialog, as I'm not familiar with the code, but it definitely breaks it.

Hopefully someone with better knowledge of wxgtk will fix it:)

I'm running Gentoo Amd64, wxGTK 2.8.12 and HEAD of WX_2_8_BRANCH (r72775), gtk+ 2.24.13.

[obfuscated]

After further investigation the call to gtk_widget_hide in wxWindowGTK::Show breaks it.

I've commented the call to this function and the return value by GetPath was correct.

[vadz]

We should be able to fix this just by remembering the path before hiding the dialog then. Please test the patch I'm going to commit soon.

Thanks for debugging this!

[VZ]

(In [72779]) Store the selected directory in wxGTK wxDirDialog.

This should help with the selected directory not being remembered since
GTK+ 2.24.11 as apparently gtk_file_chooser_get_filename() doesn't work any
more now after hiding the dialog -- so call it before doing this and save the
result.

Also get rid of the ugly and apparently completely unnecessary OnFakeOk().

Closes #14525.

[obfuscated]

It works, thank you for the quick fix.

Is it possible to backport this change to wx2.8's branch?

[vadz]

It should be but I'd rather leave this to someone else, I have too many things to do in 2.9.

[PC]

(In [72781]) Store the selected directory in wxGTK wxDirDialog, fixes #14525

[vadz]

This needs to be redone to avoid breaking ABI, new members can't be added to the stable branch.

[PC]

(In [72798]) redo r72781 in a way that preserves binary compatibility, closes #14525