Re: add test for QFileDialog::getExistingDirectory / bug?
On Tuesday 28 January 2014 15:05:30 Kevin Funk wrote: Am Sonntag, 26. Januar 2014, 18:53:42 schrieb Gregor Mi: With another addition to qfiledialogtest in frameworks/frameworkintegration another potential bug can be exposed: Calling $ ./qfiledialogtest --nameFilter c (*.cpp) --nameFilter h (*.h) --selectNameFilter h (*.h) Works for me. Using Qt 5.2.0, if that matters. Btw, on IRC, we found out that it also doesn't work for Kevin. He was using the native Qt dialogs. Greetings, Dominik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: add test for QFileDialog::getExistingDirectory / bug?
On Sunday 26 January 2014 18:53:42 Gregor Mi wrote:
With another addition to qfiledialogtest in
frameworks/frameworkintegration another potential bug can be exposed:
Calling
$ ./qfiledialogtest --nameFilter c (*.cpp) --nameFilter h (*.h)
--selectNameFilter h (*.h)
does not select the second filter. Can this be confirmed or maybe I am
using the API wrong?
Ok, so with respect to this test, here is what happens:
the `qfieldialogtest` calls
dialog.setNameFilters(nameFilterList); // list = (c (*.cpp), h
(*.h))
dialog.selectNameFilter(selectNameFilter); // filter = h (*.h)
dialog.setNameFilters() is a QFileDialog function that calls
void QFileDialog::setNameFilters(const QStringList filters)
{
// [...]
d-options-setNameFilters(cleanedFilters);
if (!d-usingWidgets())// this evaluates to 'true',
since we
return;// use the QPA
So at this point, the QFileDialogOptions class has the named filters set
correctly.
Finally, the `qfieldialogtest` calls:
dialog.exec();
And here comes the initeresting part: At this point, the
KDEPlatformFileDialogHelper is
finally shown, through the function
bool KDEPlatformFileDialogHelper::show(...)
{
initializeDialog();
// ...
return true;
}
So initializeDialog() is only called right before the dialog gets visible.
This function looks like this:
void KDEPlatformFileDialogHelper::initializeDialog()
{
// ...
QStringList nameFilters = options()-nameFilters();
m_dialog-m_fileWidget-setFilter(qt2KdeFilter(nameFilters));
}
So only now are the nameFilters from options() put into the fileWidget, which
means at the time
dialog.selectNameFilter(selectNameFilter); // filter = h (*.h)
is called (see `qfieldialogtest`), the combo box is not yet filled with the
items, and therewith setting the current index prior to calling dialog.exec()
or dialog.show() always fails.
I don't think this is how it is intended.
A possible workaround would be to to apply this patch to
QFileDialog::selectNameFilter():
void QFileDialog::selectNameFilter(const QString filter)
{
Q_D(QFileDialog);
if (!d-usingWidgets()) {
+ d-options-setInitiallySelectedNameFilter(filter);
d-selectNameFilter_sys(filter);
return;
}
And then putting into
void KDEPlatformFileDialogHelper::initializeDialog()
{
// ...
if (!options()-initiallySelectedNameFilter().isEmpty()) {
m_dialog-selectNameFilter(options()-initiallySelectedNameFilter());
}
Can someone confirm this (patch in Qt, patch in framrworksintegration) is the
correct fix for this?
I'm a bit surprised about this API right now, since this implies
dialog.setNameFilters(h (*.h), c (*.c));
dialog.selectNameFilter(h (*.h));
QString filter = dialog.selectedNameFilter(); // filter.isEmpty() == true
i.e., the code behaves totally different to what one would expect.
Is this the desired QPA API in KF5, or do I mess things up? ;)
Greetings,
Dominik
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: add test for QFileDialog::getExistingDirectory / bug?
On Tuesday 28 January 2014 15:05:30 Kevin Funk wrote: Am Sonntag, 26. Januar 2014, 18:53:42 schrieb Gregor Mi: With another addition to qfiledialogtest in frameworks/frameworkintegration another potential bug can be exposed: Calling $ ./qfiledialogtest --nameFilter c (*.cpp) --nameFilter h (*.h) --selectNameFilter h (*.h) Works for me. Using Qt 5.2.0, if that matters. Kevin, what exactly works here? Both tests do not work here: The first one for getting an existing directory, I have to choose a file, otherwise I cannot click Open. Probably the entire dialog is wrong, since I don't want a *file* dialog here. Instead, I want a dialog that shows a tree view of the folders, or am I wrong here? For the text above, --selectNameFilter is set to the h filter. But starting the dialog preselects the c filter here. So to me this looks like it doesn't work. Can you elaborate? ;) Greetings, Dominik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: add test for QFileDialog::getExistingDirectory / bug?
Am Sonntag, 26. Januar 2014, 18:53:42 schrieb Gregor Mi: With another addition to qfiledialogtest in frameworks/frameworkintegration another potential bug can be exposed: Calling $ ./qfiledialogtest --nameFilter c (*.cpp) --nameFilter h (*.h) --selectNameFilter h (*.h) Works for me. Using Qt 5.2.0, if that matters. does not select the second filter. Can this be confirmed or maybe I am using the API wrong? Gregor On 26/01/14 17:15, Gregor Mi wrote: Hi, with 2c1ee08a21a1f16f9c2523718224598de8fc0d4f I added a test for QFileDialog::getExistingDirectory. When I execute ./qfiledialogtest --staticFunction getExistingDirectory then a dialog opens that lets the user select files but not directories. This seems to be a bug. Greetings Gregor -- Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: add test for QFileDialog::getExistingDirectory / bug?
On 28/01/14 15:05, Kevin Funk wrote: Am Sonntag, 26. Januar 2014, 18:53:42 schrieb Gregor Mi: With another addition to qfiledialogtest in frameworks/frameworkintegration another potential bug can be exposed: Calling $ ./qfiledialogtest --nameFilter c (*.cpp) --nameFilter h (*.h) --selectNameFilter h (*.h) Works for me. Using Qt 5.2.0, if that matters. Hmm. I also use Qt 5.2.0 (the one that comes with kdesrcbuild). Does the other call (see below) also works for you? (Here is the console output for the first one: http://pastebin.kde.org/puwz8xzfc) does not select the second filter. Can this be confirmed or maybe I am using the API wrong? Gregor On 26/01/14 17:15, Gregor Mi wrote: Hi, with 2c1ee08a21a1f16f9c2523718224598de8fc0d4f I added a test for QFileDialog::getExistingDirectory. When I execute ./qfiledialogtest --staticFunction getExistingDirectory This one... then a dialog opens that lets the user select files but not directories. This seems to be a bug. Greetings Gregor ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: add test for QFileDialog::getExistingDirectory / bug?
With another addition to qfiledialogtest in frameworks/frameworkintegration another potential bug can be exposed: Calling $ ./qfiledialogtest --nameFilter c (*.cpp) --nameFilter h (*.h) --selectNameFilter h (*.h) does not select the second filter. Can this be confirmed or maybe I am using the API wrong? Gregor On 26/01/14 17:15, Gregor Mi wrote: Hi, with 2c1ee08a21a1f16f9c2523718224598de8fc0d4f I added a test for QFileDialog::getExistingDirectory. When I execute ./qfiledialogtest --staticFunction getExistingDirectory then a dialog opens that lets the user select files but not directories. This seems to be a bug. Greetings Gregor ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
