Opened 2 years ago

Closed 2 years ago

#14525 closed defect (fixed)

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

Reported by: MichaelClerx Owned by:
Priority: high Milestone: 2.8.13
Component: wxGTK Version: 2.9.3
Keywords: Cc: cell@…
Blocked By: Blocking:
Patch: no

Description

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())

Change History (28)

comment:1 Changed 2 years ago by MichaelClerx

  • Cc cell@… added

comment:2 Changed 2 years ago by 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.

comment:3 follow-up: Changed 2 years ago by 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.

comment:4 in reply to: ↑ 3 Changed 2 years ago by 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.

comment:5 Changed 2 years ago by 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.

comment:6 follow-ups: Changed 2 years ago by vadz

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

comment:7 in reply to: ↑ 6 Changed 2 years ago by 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 :)

comment:8 Changed 2 years ago by 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

comment:9 in reply to: ↑ 6 Changed 2 years ago by 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.

comment:10 Changed 2 years ago by 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.

comment:11 Changed 2 years ago by 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

comment:12 Changed 2 years ago by sciurius

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

comment:13 Changed 2 years ago by 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.

comment:14 Changed 2 years ago by MichaelClerx

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

comment:15 Changed 2 years ago by 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?

comment:16 Changed 2 years ago by 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.

comment:17 Changed 2 years ago by vadz

  • Component changed from wxPython to wxGTK
  • Summary changed from DirDialog.GetPath() doesn't return the user-selected path to wxDirDialog::GetPath() doesn't return the user-selected path
  • Version changed from 2.8.12 to 2.9.3

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...

comment:18 Changed 2 years ago by 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...

comment:19 Changed 2 years ago by sciurius

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

comment:20 Changed 2 years ago by 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.

comment:21 Changed 2 years ago by 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.

comment:22 Changed 2 years ago by 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!

comment:23 Changed 2 years ago by VZ

  • Resolution set to fixed
  • Status changed from new to closed

(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.

comment:24 Changed 2 years ago by obfuscated

It works, thank you for the quick fix.

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

comment:25 Changed 2 years ago by vadz

  • Milestone set to 2.8.13
  • Resolution changed from fixed to port to stable
  • Status changed from closed to portneeded

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

comment:26 Changed 2 years ago by PC

  • Resolution changed from port to stable to fixed
  • Status changed from portneeded to closed

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

comment:27 Changed 2 years ago by vadz

  • Priority changed from normal to high
  • Resolution changed from fixed to port to stable
  • Status changed from closed to portneeded

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

comment:28 Changed 2 years ago by PC

  • Resolution changed from port to stable to fixed
  • Status changed from portneeded to closed

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

Note: See TracTickets for help on using tickets.