Bug 229375

Summary: KDE replacement Qt file dialog gives bugs for Qt applications
Product: kfile Reporter: Jeremy Sanders <jeremy>
Component: generalAssignee: Olivier Goffart <ogoffart>
Severity: normal CC: halla, jakob.leben, jeremy, nate, ogoffart
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Fedora RPMs   
OS: Linux   
Latest Commit: Version Fixed In:

Description Jeremy Sanders 2010-03-04 10:43:11 UTC
Version:           4.4.0 (using KDE 4.4.0)
Compiler:          gcc version 4.4.3 
OS:                Linux
Installed from:    Fedora RPMs

As mentioned here https://bugzilla.redhat.com/show_bug.cgi?id=570090 KDE replaces the Qt file dialog in Qt applications with the KDE file dialog.

This would be okay, but the KDE file dialog behaviour is buggy and causes quite serious usability problems in my Qt application Veusz:

- The QFileDialog::selectFilter(filt) function call (documented in Qt <= 4.3) does not appear to work. The selected filter in the dialog box remains at the first one. This function call, as far as I can see, is not deprecated.

- QFileDialog::setDirectory(somedir) does not show the contents of the directory given in the dialog, but shows the directory above. This is different to the behaviour of the standard Qt file dialog.

- The file dialog does not act quite like a normal dialog. With compositing switched on, the main application does not go dark like it does with the standard Qt file dialog. This is a minor issue, however.

I can work round the first issue using QFileDialog::setNameFilter, which appears to work, but I cannot work round the second issue.

Is there a way of switching off the KDE replacement file dialog as a workaround until this is fixed?
Comment 1 Olivier Goffart 2010-03-24 10:49:40 UTC
- The QFileDialog::selectFilter(filt) 

There is no equivalent in the KFaileDialog.

- QFileDialog::setDirectory(somedir)

I cannot reproduce the problem.  Here, both QFileDialog and KFileDialog act the same.  Do you have a test case?

- KWin does not dark the parent window.

That is probably a bug in KWin, the problem is maybe that the parent hierarchy is different that the one KWin usually expect.
Comment 2 Jeremy Sanders 2010-05-29 15:47:11 UTC
There's definitely a problem with QFileDialog::setDirectory on my system. Here is an example program:

#include <QApplication>
#include <QFileDialog>
#include <QString>

#include <cstdlib>
using std::getenv;

int main(int argc, char *argv[])
  QApplication app(argc, argv);

  QFileDialog dialog;
  QString homedir( getenv("HOME") );

  return 0;

With the KDE file dialog, this shows the contents of the /home directory, selecting my home directory in that directory.

With the Qt file dialog, this shows the contents of my home directory.
Comment 3 Jakob Leben 2013-04-09 21:13:03 UTC
I can confirm issues with QFileDialog::setDirectory() in QFileDialog::AcceptSave mode:
1. instead of the given directory, it's parent is shown
2. the given directory is selected (it's name is in the filename edit box), despite allowing only opening files, and not directories

Note that setDirectory() in the AcceptOpen mode works ok.

Ubuntu 12.10
KDE 4.9.5
Qt 4.8.3
Comment 4 Halla Rempt 2014-06-24 09:58:06 UTC
Me too... So, now i am checking which desktop env. is running and choosing whether to use the static methods or not based on that.
Comment 5 Nate Graham 2018-04-10 19:31:20 UTC
Is this still an issue with the KDE Frameworks 5.x version?
Comment 6 Halla Rempt 2018-04-11 06:52:08 UTC
I cannot reproduce this anymore with the given test code.
Comment 7 Nate Graham 2018-04-11 13:50:45 UTC
Excellent, thanks for testing!