Kdialog issues and proposed fixes

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.

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

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

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

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