When opening a FileChooser, it does not show up and instead the whole application freezes. I'm not sure what causes this behaviour, but I think it happens since the latest Gnome update (3.18). This is why I'm reporting this in the Linux forum.
It works for us, so you'd need to debug and provide some more clues for us to be able to help...
It's the same problem as reported last year in this thread.
If you open a native file chooser on gnome 3.18 (using zenity) the programs hangs. I can reproduce it in the Demo.
I looked into the code and it seems the main program is trying to read from the stdout of zenity, but the read call is blocking and waiting for zenity to close its stdout. For some reason zenity doesn't show up, so one can't select any files. When you uncomment the
line in the ChildProcess::ActiveProcess constructor everything works fine.
Maybe zenity doesn't like the closed stderr...
Also I think in the linux FileChooser::showPlatformDialog() it's quite senseless to add a "2>/dev/null" to the arguments list, this should work in a shell, but not when passing arguments directly to a child.
any ideas on this? or should we provide some more debugging information?
More info would be good - we've not seen this problem on our linux machines.
i'm using gdm 3.18.2 and zenity 126.96.36.199 on arch linux. the issue can be reproduced on other arch machines and in the demo
I've come across this issue before but never had time to investigate. In the end I used non-native file browsers which seem to work fine across all flavours of linux.
This highlights the combinatorial explosion problem that we have when people report bugs on linux! I can't justify the expense of getting one of us to spend half a day setting up an arch linux machine just to test and debug this.. Can you give us any more clues that might help us suggest a fix?
How come a linux system is too much work?
ArchLinux is a rolling release distro (like Windows 10 seems to be rolling now), which means running the updates from time to time is enough to get the latest linux stuff.
Of course such system won't be ideal for building public binaries, but that's what chroots are for.
Anyway, using the non-native file dialog seems to be the best option for now.
Gnome3 is updated frequently and we have KDE5 now, so things might not work as before.
I've been surprised to see such a problem, running Juce 4.1, after a long time without playing with it (several years).
I'm on ArchLinux, with an OpenBox window manager, not using Gnome libs (well, except gvfs and some others), but only Gtk+ (I guess the issue comes from Gtk+ filechooser wrapper).
Can somebody point me to an easily downloadable iso where this can be reproduced? I've managed to install ArchLinux in a VM and also installed openbox - but openbox seems to be completely broken, i.e. all fonts seem to be displayed incorrectly. I don't really feel like spending time on debugging arch linux.
It wont be easy as I don't have much time to make it one myself, but I will try.
It does not have to be a big investment.
A very long time ago I began to do my development on a Guest Virtual Machine. The core Host system is simply used to run vms. I am very careful about what gets installed on the Host with the result that it is very unlikely it will ever get whacked.
One benefit to this is that many distributions offer ISO images of virtuals and after a quick download and filling in some screen forms about the new Guest, it is running. It is also real easy to clone and backup a vm.
VirtualBox is free and VMware is about $250, so it ranges from free to very affordable for the core software. They are both pretty high performing and you would be surprised how close they come to a Native install for build times.
Also, be aware of the multiplier factor of Juce time versus Customer time. One hour spent by Juce can save 1,000's of Customer hours.
Yes, I meant it's expensive in terms of time. Which is something we're always short of. Linux is just one of those enormously time-consuming things to work with, so we do have to rely a lot on feedback from our linux users.
If it can help. The FileChooser seems to work on Ubuntu 14.04 (I use VirtualBox) but someone posted an issue on my project for Ubuntu 16.04. The only solution was to replace
#elif JUCE_MAC || JUCE_LINUX
at line 103 of …/modules/juce_gui_basics/filebrowser/juce_FileChooser.cpp
If I find the underlying problem, I’ll keep you informed.
Modifying the Linux Makefile by adding the following Extra Preprocessor Definition in Projucer would serve the same without need for modifying the juce_FileChooser code:
That’s an idea, although I think the best way would be to have a fallback, so that when the
which command fails, the non-native chooser is launch, with a warning in the console (because the native chooser was expected).
I didn’t make the changes to try it, any feedback on the idea is welcome.
It looks like this filechooser issue - as far as I can see is mainly related to zenity.
Furthermore trying to reproduce it on exactly same fresh Linux installations - once installed on Parallels Desktop and once installed on VMware gives different results.
My actual investigations based on installations using my descriptions in this thread gives in a reproducible way the following results :
On Parallels Desktop 11 on Mac OSX hosted (El Capitan):
Ubuntu 14.04 (zenity 3.8.0), 16.04 beta2 (zenity 188.8.131.52) , elemtary OS 0.3.2, Mint 1.7, Fedora 23 (zenity 184.108.40.206)
->no issues at all everything works without freezes
On VMware as well as on VirtualBox, independent if hosted on Windows 10 64bit or Mac OS X (El Captian) the newer zenity versions freezes, that means Ubuntu 16.04 freezes, Fedora 23 freezes.
My actual assumption is, that the newer zenity version 220.127.116.11 interferes somehow with the VMWare as well as Virtual Box approaches of interacting between host and guest filesystem (their kernel modules, e.g. for copy & paste between host and guest file system etc. ) - but this is actually just a guess, I’m drilling it further down.
… to be precise about fallbacks, it looks like there are already fallbacks implemented (juce_linux_FileChooser.cpp):
- There is no zenity (e.g. it’s removed by ‘sudo apt-get remove zenity’)
- kdialog has been installed (e.g. using ‘sudo apt-get install kdebase-bin’)
In this case Projucer falls back automatically to kdialog.
Note for this szenario: In case you have to install kdialg (sudo apt-get install kdebase-bin), then start first once kdialog in a shell (e.g. 'kdialog --yesno “yes/no”). kdialog seems to do some user configs on first startup which causes kdialg to crash when started first time directly through Projucer.
- zenity is installed
- kdialog is installed as well
- variable KDE_FULL_SESSION is set to true (for test e.g. you execute in the shell from which you start Projucer
In this case Projucer doesn’t check first the existence of zenity but invokes directly kdialog instead
… to finalize my filechooser-weekend, the driver for the freeze must be a change introduced in gtk±3.17.8 in gtkfilechooserwidget.c (access check for parent folder, see diff first image below.) Somehow zenity gets frozen at munmap() on Linux’ on pyhsical systems, VMWare and Virtualbox but not on Parallels Desktop guests (see second image with comparison of strace -ff attached to zenity left side on parallels desktop, right side on Vbox guest).
Might be the new parent folder access check in gtkfilechooserwidget.c conflicts with an access to the same parent folder from within juce_linux_FileChooser.cpp ?