Kdialog issues and proposed fixes

Linux
1

Hi, I get warnings and errors when using native file dialogs under kde like those reported here

http://www.juce.com/forum/topic/kdialog-errors-appear-filechooser-result-path

I investigated the issues and I've come up with the following patch for JUCE

diff --git modules/juce_gui_basics/native/juce_linux_FileChooser.cpp modules/juce_gui_basics/native/juce_linux_FileChooser.cpp
index 5d8028a..c371533 100644
--- modules/juce_gui_basics/native/juce_linux_FileChooser.cpp
+++ modules/juce_gui_basics/native/juce_linux_FileChooser.cpp
@@ -41,7 +41,7 @@ bool FileChooser::isPlatformDialogAvailable()
 void FileChooser::showPlatformDialog (Array<File>& results,
                                       const String& title,
                                       const File& file,
-                                      const String& /* filters */,
+                                      const String& filters,
                                       bool isDirectory,
                                       bool /* selectsFiles */,
                                       bool isSave,
@@ -79,11 +79,14 @@ void FileChooser::showPlatformDialog (Array<File>& results,
         }
 
         String startPath;
-
-        if (file.exists() || file.getParentDirectory().exists())
+        if (file.exists())
         {
             startPath = file.getFullPathName();
         }
+        else if (file.getParentDirectory().exists())
+        {
+            startPath = file.getParentDirectory().getFullPathName();
+        }
         else
         {
             startPath = File::getSpecialLocation (File::userHomeDirectory).getFullPathName();
@@ -93,6 +96,8 @@ void FileChooser::showPlatformDialog (Array<File>& results,
         }
 
         args.add (startPath);
+        args.add (filters.replaceCharacter(';', ' '));
+        args.add ("2>/dev/null");
     }
     else
     {

The above patch makes juce use the kdialog properly. From running kdialog --help we get

...

--getopenfilename [startDir] [filter] File dialog to open an existing file                                                                                                   
--getsavefilename [startDir] [filter] File dialog to save a file                                                                                                             
--getexistingdirectory [startDir] File dialog to select an existing directory

...

so kdialog needs a directory to work as it should.

Moreover the patch enables to use the file filters with kdialog and it also adds the "2>/dev/null" as the last arguement as seen in the other thread.

Most of the warnings I got here where actually coming from kdelibs. I got warnings from KSambasharePrivate::.. and KUrlCompleter::.. To get rid of them I had to apply these 2 patches on KDE.

Fix for KSambaSharePrivate warnings: http://bugsfiles.kde.org/attachment.cgi?id=84643

Fix for KUrlCompleter warnings: http://bugsfiles.kde.org/attachment.cgi?id=84790

For more details from the KDE side look at https://bugs.kde.org/show_bug.cgi?id=320199 and https://bugs.kde.org/show_bug.cgi?id=330278

With all three patches applied I don't have any strange warnings anymore when using native dialogs in KDE. I tested the Demo, Introjucer and my code as well. Now Introjucer actually is usable: "Add new GUI component ..." works properly. Even the dialogs in Tracktion (choosing vst plugin folders) work as they should. The final thing that is missing is to display a yes/no dialog when someone wants to overwrite a file after selecting it from the save dialog box.

All the above was tested on Slackware 14.1 with KDE 4.10.5 and the latest JUCE from git.

2

Thanks, much appreciated! I'll take a look at that right away!

3

We got a report that on Linux the native file chooser using kdialog doesn't work. I don't have a KDE installation to test this myself, but I had a quick look at the source here:

https://github.com/julianstorer/JUCE/blob/master/modules/juce_gui_basics/native/juce_linux_FileChooser.cpp#L79

I think the problem is the order of the arguments: --attach <topWindowID> is put between the --getsavefilename and <startPath> arguments.

--
Roeland

4

Why would the order make any difference? Surely its command-line parser will get their values regardless of the order?

5

I could finally test this on a KDE installation. Here's some output from kdialog --help:

Options:
  (...)
  --getopenfilename [startDir] [filter] File dialog to open an existing file
  --getsavefilename [startDir] [filter] File dialog to save a file
  --getexistingdirectory [startDir] File dialog to select an existing directory
  (...)
  --attach <winid>          Makes the dialog transient for an X app specified by winid

The file name and filter patterns are not positional arguments, they're two values belonging to the --getopenfilename option. A possible fix is moving the code adding the --attach option to the bottom of the function.

--
Roeland