Summary: | KDE replacement Qt file dialog gives bugs for Qt applications | ||
---|---|---|---|
Product: | [Unmaintained] kfile | Reporter: | Jeremy Sanders <jeremy> |
Component: | general | Assignee: | Olivier Goffart <ogoffart> |
Status: | RESOLVED FIXED | ||
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: | ||
Sentry Crash Report: |
Description
Jeremy Sanders
2010-03-04 10:43:11 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. 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") ); dialog.setDirectory(homedir); dialog.exec(); 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. 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. System: Ubuntu 12.10 KDE 4.9.5 Qt 4.8.3 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. Is this still an issue with the KDE Frameworks 5.x version? I cannot reproduce this anymore with the given test code. Excellent, thanks for testing! |