Thanks for the report. First time I hear this, also sadly can not reproduce it when trying with Okteta from openSUSE TW package, as well using Qt 5.15.2 & KF 5.85.0 (and Plasma 5.22.4).

For now I have to suspect some Arch-specific issue. Does opening files via the Open menu entry and then the file picker work for other KF-based programs?

Just tested opening ZIP archive with Ark - works fine

Looking at the different code paths, the only thing for now I could imagine to fail between showing the file picker dialog and the methods then triggering loading is the usage of the QFileDialog::urlsSelected signal, which I just fonud to be Okteta the only one in the KDE sheres by lxr.kde.org grepping.
So chance is that whatever got broken (perhaps by some Arch-specific patches) then also only affects Okteta.

Respective ocde is at
https://invent.kde.org/utilities/okteta/-/blob/0.26/libs/kasten/controllers/documentsystem/loader/loadercontroller.cpp#L63

Qt API docs:
https://doc.qt.io/qt-5/qfiledialog.html#urlsSelected

So this needs someone to invesigate why with Arch that signal would not be emitted. Does Arch have some special file dialog plugin, after all Qt uses the one coming from the respective plugin integration?

According to their PKGBUILD (https://github.com/archlinux/svntogit-packages/blob/packages/okteta/trunk/PKGBUILD) no special patches were used for Okteta package

While you gave "KDE Plasma Version: 5.22.4" as requested by the form, are you also using Plasma when experiencing this? Or some other environment (like the person whose Arch report you linked)? In that case our eyes should move to the Qt plugin for that environment and what QFileDialog implementation it provides.

It happens both in Plasma and Cinnamon as well

I've filed a bug (https://bugs.archlinux.org/task/71964) for Arch too

Quick dump of where on first understanding the issue might to be searched:

the file dialog picker dialog as provided by Qt when using QFileDialog can be delivered from the platform integration used for the respective environment. That will be loaded from a respective plugin, where e.g. a QPlatformTheme subclass is provided and in the override of
   QPlatformDialogHelper *createPlatformDialogHelper(DialogType type) const
would provide a specific subclass of QPlatformFileDialogHelper in case of type being QPlatformTheme::FileDialog.

That QPlatformFileDialogHelper implementation needs to emit the signal
    void filesSelected(const QList<QUrl> &files);
accordingly to the expectations of QFileDialog itself, which cares for the emission of the QFileDialog::urlsSelected when that other signal is emitted
See the wire-up at https://code.qt.io/cgit/qt/qtbase.git/tree/src/widgets/dialogs/qfiledialog.cpp?h=5.15#n559

So we would need to find what QPA plugin(s) are used here and what their QPlatformTheme subclass injects here as file dialog helper code. As by now I would suspect it misses to emit the filesSelected() signal.

No clue about QPA myself otherwise, also not a bug of Okteta then.

Some further code understandings:

QFileDialog in QFileDialog::accept() (see https://code.qt.io/cgit/qt/qtbase.git/tree/src/widgets/dialogs/qfiledialog.cpp?h=5.15#n2809) has code to trigger the emission of the QFileDialog::urlsSelected even if the platform integration helper does not emit the filesSelected() signal, as !d->usingWidgets() would be true and   d->_q_emitUrlsSelected(urls); would trigger the emission.

Looked around elsewhere and found some suspicuous code in the xdg portal variant of the Plasma integration which perhaps could trigger things, left comment at related MR:
https://invent.kde.org/plasma/plasma-integration/-/merge_requests/4#note_296573

Are you using qt5ct? That's the only way I can reproduce this.

(In reply to Antonio Rojas from comment #9)
> Are you using qt5ct? That's the only way I can reproduce this.

Actually, the problem seems to be the plain Qt file picker. I can reproduce in Plasma by removing plasma-integration (I couldn't find an env variable to force using the Qt file picker without removing it)

(In reply to Antonio Rojas from comment #10)
> Actually, the problem seems to be the plain Qt file picker. I can reproduce
> in Plasma by removing plasma-integration (I couldn't find an env variable to
> force using the Qt file picker without removing it)

Good idea. Indeed, on a quick look I could not find how QFileDialog itself would invoke the signal if not using a QPlatformDialogHelper. Ouch.

And the built-in would be used for any QPA which does not provide a custom one on the request by QGuiApplicationPrivate::platformTheme()->createPlatformDialogHelper(static_cast<QPlatformTheme::DialogType>(type));

Seems https://codereview.qt-project.org/c/qt/qtbase/+/89484 missed out that code path :(

Next up: writing a test & bug for Qt

I'm using qt5ct and the only thing that it serve is to select breeze theme

I created some sample code to demonstrate the bug and filed an issue with Qt: https://bugreports.qt.io/browse/QTBUG-96157

Hopefully someone can invest into fixing that bug, should not be that difficult, given things are done properly in the other code paths. No spare resources myselr sadly. I would also not want to invest any resources in a work-around in Okteta, they all should be put onto fixing this upstream and helping any users of those signals.

Thanks Viktor for reporting the bug and Antonio for hunting down at least one source for the wrong behaviour.

*** Bug 452943 has been marked as a duplicate of this bug. ***

*** Bug 454083 has been marked as a duplicate of this bug. ***

*** Bug 461185 has been marked as a duplicate of this bug. ***