Yasuhiko, All, The kde3 kdialog source needs to be updated to accept an `--attach` option to be compatible with the current KDE kdialog. This is critical as more apps move to using the xdg-desktop-portal features for using native file-dialogs. Recently this has broken Firefox/Thunderbird and vscode/vscodium under KDE3. The problem is the xdg-desktop-portal fileChooser implementations use kdialog for the chooser. They use options for the current Plasma kdialog implementation that includes options that do not exist in KDE3 kdialog like the --attach option. See vscodium BUG (bottom comments): Linux - vscodium no longer displays file-dialog after update to Ver. 1.90.0 #1927 https://github.com/VSCodium/vscodium/issues/1927 In the case of both Firefox/Thunderbird and vscode/vscodium there was no way to open or save files. The dialog in the case of vscode/vscodium would fail to open and no fallback file-dialog was provided in case of failure. I didn't fully debug Firefox/Thunderbird, but mozilla provides an option to turn the portal chooser interface off with: widget.use-xdg-desktop-portal.file-picker=0 (1: always on, 2: auto) Apparently this is set to 1 by default in openSUSE so KDE will use the native file dialogs, but breaks the dialogs completely for KDE3. In vscode/vscodium the portal/kdialog open string is formed from: kdialog --attach=22020099 --title=Open File --multiple --separate-output --getopenfilename /path/to/file This fails in KDE3 for 2 reason (1) no --attach option and (2) "Open File" must be quoted. The debug (--verbose --vmodule=*/ui/*=2) options for vscode/vscodium shows: [main 2024-11-17T00:53:51.814Z] [DialogMainService]: request to acquire file dialog lock { title: 'Open File', buttonLabel: undefined, filters: undefined, defaultPath: '/home/david/dev/embedded-rpz/rpz/tst/gpio_v2_ir_snsr', properties: [ 'multiSelections', 'openFile', 'createDirectory' ] } [main 2024-11-17T00:53:51.815Z] [DialogMainService]: new file dialog lock created { title: 'Open File', buttonLabel: undefined, filters: undefined, defaultPath: '/home/david/dev/embedded-rpz/rpz/tst/gpio_v2_ir_snsr', properties: [ 'multiSelections', 'openFile', 'createDirectory' ] } [2127:1116/185351.853415:VERBOSE1:select_file_dialog_linux_kde.cc(425)] KDialog command line: kdialog --attach=22020099 --title=Open File --multiple --separate-output --getopenfilename /home/david/dev/embedded-rpz/rpz/tst/gpio_v2_ir_snsr [2127:1116/185351.883868:VERBOSE1:select_file_dialog_linux_kde.cc(568)] [kdialog] MultiFileResponse: [main 2024-11-17T00:53:51.884Z] [DialogMainService]: file dialog lock disposed { title: 'Open File', buttonLabel: undefined, filters: undefined, defaultPath: '/home/david/dev/embedded-rpz/rpz/tst/gpio_v2_ir_snsr', properties: [ 'multiSelections', 'openFile', 'createDirectory' ] } Here the dialog is created and destroyed in 69 ms (difference between T00:53:51.884Z and T00:53:51.815Z) This issue will only get worse as more apps try and implement this portal chooser interface that was intended for Flatpak to avoid sandbox issues. We probably just need to include the current KDE/Plasma options for kdialog like --attach and can simple have those invoke a stub function to prevent an error. That should allow these portal chooser implementations to work with KDE3 and keep the dialog from throwing an exception for unknown options. This likely will effect TDE as well. I'll forward to the TDE dev list. -- David C. Rankin, J.D.,P.E.