Bug 467868 - kdialog --getopenfilename filter argument text is unclear, needs updated documentation change
Summary: kdialog --getopenfilename filter argument text is unclear, needs updated docu...
Status: RESOLVED FIXED
Alias: None
Product: kdialog
Classification: Applications
Component: general (show other bugs)
Version: 22.12.3
Platform: Neon Linux
: NOR normal
Target Milestone: ---
Assignee: Brad Hards
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-03-28 01:42 UTC by Michael
Modified: 2024-03-07 23:56 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael 2023-03-28 01:42:38 UTC
SUMMARY

kdialog's --getopenfilename argument used to accept a simple filter of file extensions, like *.jpg, but the functionality has changed to only support Mimetypes, and it is not documented in the usage text. Scripts which use kdialog appear to be broken. It's annoying, but it needs to be documented somewhere, and it would be super if kdialog itself documents itself.


STEPS TO REPRODUCE

1.  In Konsole, type kdialog to see the usage text. We're interested in getopenfilename:

  --getopenfilename                 File dialog to open an existing file
                                    (arguments [startDir] [filter])

Instead of just "[filter]", it should say: "[Mimetype filter]" 

2. To test this, type: 

kdialog --getopenfilename ~/Downloads "*.jpg"

A standard file dialog will appear, but instead of only showing .jpg files, it shows *all* files, and any file can be selected. A regression.

This is documented here: 
   https://develop.kde.org/docs/administration/kdialog/#--getopenfilename-dialog-box
   https://mostlylinux.wordpress.com/bashscripting/kdialog/#get-open-file-name

3. The new, Mimetype-only functionality of kdialog is now: 

kdialog --getopenfilename ~/Downloads "image/jpeg"

Filtering works as expected. Please update the usage text to reflect this.


SOFTWARE/OS VERSIONS

Operating System: KDE neon 5.27
KDE Plasma Version: 5.27.3
KDE Frameworks Version: 5.104.0
Qt Version: 5.15.8
Kernel Version: 5.19.0-35-generic (64-bit)
Graphics Platform: X11
Comment 1 shenlebantongying 2023-05-26 20:00:33 UTC
> 2. To test this, type: 
> kdialog --getopenfilename ~/Downloads "*.jpg"

The related code for wildcard match still exists, and this syntax still works:

kdialog --getopenfilename ~/Downloads "Some Strings (*.jpg)"

This is KDE's file dialog's bug.

---

It seems plasma's file dialog doesn't support simple filter like "*.jpg"

https://doc.qt.io/qt-6.4/qfiledialog.html#setNameFilter

Compile code below with Qt5 will reproduce this bug


```
#include <QApplication>
#include <QFileDialog>

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

// Doesn't work on KDE (only have problem on KDE)
    auto *dlg1 = new QFileDialog();
    dlg1->setNameFilter("*.txt");
    dlg1->exec();

// Works
    auto *dlg2 = new QFileDialog();
    dlg2->setNameFilter("Force to work with KDE (*.txt)");
    dlg2->exec();

    return QApplication::exec();
}
```
Comment 2 shenlebantongying 2023-05-26 20:08:08 UTC
Yes, it is KDE's file dialog bug.

`kdialog --getopenfilename ~/Downloads "*.jpg"` works on xfce which has a different file dialog.
Comment 3 Michael 2023-05-26 23:49:37 UTC
Very good sleuthing. So how would we reassign this bug so that the developers in charge of the file dialog will see it?
Comment 4 shenlebantongying 2023-06-11 08:26:02 UTC
> So how would we reassign this bug so that the developers in charge of the file dialog will see it?

I created a new one: https://bugs.kde.org/show_bug.cgi?id=470893
Comment 5 Baltasar Sanchez 2023-08-03 10:14:00 UTC
I think I found a related bug with --getexistingdirectory

this used to work, I just updated to kdialog 23.04.3 and it no longer works as it used to
Comment 6 Michael 2023-08-06 03:28:15 UTC
(In reply to Baltasar Sanchez from comment #5)
> I think I found a related bug with --getexistingdirectory
> 
> this used to work, I just updated to kdialog 23.04.3 and it no longer works
> as it used to

I can verify that it doesn't seem to work, but maybe it should have it's own bug report to be tracked as a separate issue?
Comment 7 Michael 2023-12-26 04:11:05 UTC
This may have been fixed in: https://bugs.kde.org/show_bug.cgi?id=470893

Test this with the new KF6 release.
Comment 8 Michael 2024-03-02 04:50:03 UTC
The functionality is fixed in KF6: kdialog 24.02.0 works with both file extensions and mime-types.

However, the docstring still says:

--getopenfilename                 File dialog to open an existing file
                                    (arguments [startDir] [filter])

...and "filter" is not clarified. It can now be "*.jpg" or "image/jpeg". 

Instead of just "[filter]", it would be clearer to say: "[Mimetype or file extension filter]"
Comment 9 shenlebantongying 2024-03-03 02:12:11 UTC
Do you mind sending a merge request on KDE's GitLab? It should be simple since it is just a string change.
Comment 10 Michael 2024-03-03 22:22:00 UTC
(In reply to shenlebantongying from comment #9)
> Do you mind sending a merge request on KDE's GitLab? It should be simple
> since it is just a string change.

Thank you for the invitation, but I don't know how to do a merge request.
Comment 11 Bug Janitor Service 2024-03-03 23:16:07 UTC
A possibly relevant merge request was started @ https://invent.kde.org/documentation/develop-kde-org/-/merge_requests/351
Comment 12 Bug Janitor Service 2024-03-03 23:20:57 UTC
A possibly relevant merge request was started @ https://invent.kde.org/utilities/kdialog/-/merge_requests/37
Comment 13 Michael 2024-03-07 23:56:01 UTC
Great! Thank you so much and even for updating the documentation 🙏