Very strange problem, maybe related to some library changes in Arch

Jacek Poplawski · 2012-07-29 12:55:08

Hello,

I use wxWidgets because I develop application using it (delaboratory), and yesterday I noticed something very strange,
this library has dialog to open dir, simple dialog where you click your desired dir and click OK.
This dialog was working correctly for a long time, and I know it works for other people (for instance with Windows).
But yesterday I realized this dialog always returns my home dir instead desired dir.

So.... I started searching for bugs in my code. Then I downloaded old version (which I know was working correctly). Then I rebooted system. Then I reinstalled wxgtk with pacman, then I reinstalled gtk2, then I removed every package related to gtk2 or gtk3 or glib and installed everything again. Then I tested wxgtk-2.9 instead 2.8. Still no change.

Then I found demo applications for wxWidgets here;

http://www.wxwidgets.org/downloads/demos.htm

Please download DIALOGS DEMO "Linux with GTK+", this is SUSE binary (doesn't work on Arch) and sources.

Then compile source:

g++ -o dialogs dialogs.cpp `wx-config --libs --cxxflags`

and run dialogs

click "Directory operations", then "Choose a directory".

select any dir (other than your home dir). What dir is displayed? On my system it shows home dir every time!

Does it work for you on Arch? I am really confused so it would be nice if at least someone realized it's Arch related and my computer is not crazy

Last edited by Jacek Poplawski (2012-07-29 12:55:44)

stqn · 2012-07-30 03:07:02

$ g++ -o dialogs dialogs.cpp `wx-config --libs --cxxflags`
dialogs.cpp:28:25: fatal error: ../sample.xpm: No such file or directory
compilation terminated.

Jacek Poplawski · 2012-07-30 10:03:14

Ah yes I also got that problem, I simply removed both lines with sample.xpm from dialogs.cpp, the first one includes it, the second one sets the icon.

stqn · 2012-07-30 19:30:19

Ok, same problem here then.

Jacek Poplawski · 2012-07-31 12:28:37

Well so current Arch is somehow broken, but it's not wxWidgets, this package is unchanged for a long time, I am not sure is it gtk+ or some X libraries.

Jacek Poplawski · 2012-07-31 16:32:07

It was working correctly on Arch with glib2 2.32.3-1, gtk2 2.24.10-3, glibc 2.15-11, libx11 1.5.0-1, wxgtk 2.8.12.1-3

Malvineous · 2012-08-26 03:34:54

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.

I recompiled wxWidgets 2.8.12 from the Arch PKGBUILD with the new GTK installed but it still has the same problem. I added a print statement in the wxWidgets file src/gtk/dirdlg.cpp in the GetPath() function, and it turns out that the GTK function gtk_file_chooser_get_filename() is incorrectly returning $HOME instead of the selected path. So it appears the bug is not in wxWidgets, as it is the GTK function returning the incorrect value.

But what I don't understand is how my test program works, when it calls the same gtk_file_chooser_get_filename() function! I have tried to duplicate the same settings but my code works, and wx doesn't!

Here is my test program in case anyone else has any ideas how to reproduce the problem:

/* GTK+ folder selection example
 *
 * Compile with:
 *   $ gcc -o gtk-test gtk-test.cpp `pkg-config gtk+-2.0 --cflags --libs`
 *   $ ./gtk-test
 */
#include <gtk/gtk.h>

int main(int argc, char *argv[])
{
  GtkWidget *dialog;
  gtk_init(&argc, &argv);

  dialog = gtk_file_chooser_dialog_new ("Open File",
    NULL,
    GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER,
    GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
    GTK_STOCK_OPEN, GTK_RESPONSE_ACCEPT,
    NULL);

  gtk_dialog_set_default_response(GTK_DIALOG(dialog), GTK_RESPONSE_ACCEPT);
  gtk_file_chooser_set_current_folder(GTK_FILE_CHOOSER(dialog), "");

  if (gtk_dialog_run (GTK_DIALOG (dialog)) == GTK_RESPONSE_ACCEPT) {
    char *filename;

    filename = gtk_file_chooser_get_filename (GTK_FILE_CHOOSER (dialog));
    g_print ("Selected folder: %s\n", filename);
    g_free (filename);
  }
  const gchar *m = gtk_check_version(2,4,0);
  if (m) {
    g_print ("version mismatch: %s\n", m);
  } else g_print ("version ok\n");
  gtk_widget_destroy (dialog);
  return 0;
}

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.

I'm stumped.

MichaelClerx · 2012-08-28 12:01:49

There's a wxWidgets bug filed for this issue here

stqn · 2012-08-28 12:48:09

I can confirm the behaviour talked about in the bug report: selecting a directory (in the “dialogs” wx demo) and clicking “Open” works, but actually entering the directory before clicking “Open” returns the home dir.

gtk2 2.24.11-2, wxgtk 2.8.12.1-3, wxgtk-2.9 2.9.1-2 (I believe the demo uses wxgtk 2.8, based on what “nm dialogs” is returning.)

Malvineous · 2012-08-28 15:01:45

@MichaelClerx: Thanks for the link to the wx bug. Hopefully they can figure it out!

Jacek Poplawski · 2012-11-21 01:51:49

well it's november, looks like wxwidgets 2.8 is broken and we should move to 2.9

vadmium · 2012-11-22 00:07:11

According to the comments at the bottom of the WX Widgets bug it looks like they made changes in a 2.8 branch.

Related mailing list post: [arch-general] Weird GTK+ open directory chooser dialog behaviour

Arch Linux

#1 2012-07-29 12:55:08

Very strange problem, maybe related to some library changes in Arch

#2 2012-07-30 03:07:02

Re: Very strange problem, maybe related to some library changes in Arch

#3 2012-07-30 10:03:14

Re: Very strange problem, maybe related to some library changes in Arch

#4 2012-07-30 19:30:19

Re: Very strange problem, maybe related to some library changes in Arch

#5 2012-07-31 12:28:37

Re: Very strange problem, maybe related to some library changes in Arch

#6 2012-07-31 16:32:07

Re: Very strange problem, maybe related to some library changes in Arch

#7 2012-08-26 03:34:54

Re: Very strange problem, maybe related to some library changes in Arch

#8 2012-08-28 12:01:49

Re: Very strange problem, maybe related to some library changes in Arch

#9 2012-08-28 12:48:09

Re: Very strange problem, maybe related to some library changes in Arch

#10 2012-08-28 15:01:45

Re: Very strange problem, maybe related to some library changes in Arch

#11 2012-11-21 01:51:49

Re: Very strange problem, maybe related to some library changes in Arch

#12 2012-11-22 00:07:11

Re: Very strange problem, maybe related to some library changes in Arch

Board footer