TDE Devs, I stumbled onto an issue that breaks the file-open/file-save dialog display on Firefox/Thunderbird using the openSUSE builds and the vscode/vscodium dialogs. The problem is the apps have begun to use the Flatpak xdg-desktop-portal interface to invoke the native desktop file dialogs. A good idea, but only half-baked because they break the file dialogs on desktops that do not support the latest options to the native file choosers. For openSUSE kde3, that means the dialogs fail when the portal inteface passes the --attach option to kdialog which does not exist for kde3 kdialog. The following is the e-mail sent to the openSUSE kde3 list as well as a link to the bug filed against vscodium. If you have new unexplained "the file dialogs are not appearing issue in some non-TDE app XYZ" -- this is a prime suspect. == Original Message == 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 devel list. == End Original == So if you have already fixed k/tdialog, then you are good. If not, I'll pass along anything we come up with. -- David C. Rankin, J.D.,P.E.