November 2024 - openSUSE KDE 3 - openSUSE Mailing Lists

Gtk app launching at 96dpi - fixed - was it purposeful?
by David C. Rankin 24 Nov '24

24 Nov '24

Yasuhiko, All, For years, after launching konsole via a bash script that made dcop calls to setup and establish ssh connections to 5 different hosts on startup, all subsequent Gtk apps and xterm would be at 96 dpi instead of the laptop default of 103. This has some benefit in that it made the Gtk app interface smaller and much nicer and it fit with the remaining desktop config I have for kde3. This problem (feature) is now fixed and all apps consistently launch at the native 103 dpi. Was there an intentional fix, or is this strange 96 dpi Gtk default something that finally worked its way out of the system? I'm curious, but because I find I really liked the Gtk apps starting at 96 dpi for the look at feel. At 103 dpi, all fonts are about 1 pt larger and things like the Thunderbird folder-list no longer fit without wrapping in the allocates space I have set. So much so I've gone to creating wrapper scripts to set the resolution before app start and then restoring the native resultion afterwards (trying to set Gtk look at feel is now almost impossible with the current gnome config tools and the frustrating everything Adwaita or nothing themes) For example, I create a .desktop for Thunderbird to launch it as: $ cat ~/bin/tbird-fix.sh #!/bin/sh # set Xft.dpi to 96 (Gtk default) xrdb -merge /home/david/cnf/xterm/Xresources-96_dpi sleep .5 # launch tbird with gdk fix GDK_CORE_DEVICE_EVENTS=1 thunderbird & # reset Xft.dpi to 103 sleep 5 xrdb -merge /home/david/cnf/xterm/Xresources-103_dpi Where the Xresources-XX files contain: $ cat /home/david/cnf/xterm/Xresources-96_dpi ! DPI ! set dpi in separate file and xrdb -merge filename after startup for FF/TB Xft.dpi: 96 So I'm curious was the fix that stabilized app dpi an intentional fix in KDE3 somewhere, or just a side-effect of some fix somewhere unknown? -- David C. Rankin, J.D.,P.E.

1 0

kdialog needs update to add --attach option to be compatible with xdg-desktop-portal fileChooser implementations
by David C. Rankin 24 Nov '24

24 Nov '24

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.

2 3

Regarding the response to the deprecation of update-desktop-files
by Yasuhiko Kamata 23 Nov '24

23 Nov '24

Hello all, As there was an announcement in factory mailing list [1], update-desktop-files is going to be dropped. [1] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message… It will still be a spare while before it is actually dropped, this patch creation process (as explained in [1]) is very heavy and time consuming (kdelibs3 build process takes 4+ hours!), so I decided to migrate not to use it. If simply remove the %suse_update_desktop_file script from spec file, our translation efforts will be lost, so converted the script results (extracted from the built rpms) into a patch, namely kde**-deprecate-update-desktop-files.patch. (done for kde3 core packages, working on for other packages) These patches should not affect behavior or translation results, but please report if you have any problems. Thanks, -- Yasuhiko Kamata E-mail: belphegor(a)belbel.or.jp

2 2

Tumbleweed - kate sftp: won't open symlinks on remote?
by David C. Rankin 18 Nov '24

18 Nov '24

All, Using sftp: in kate, I can't open symlinks on the remote host. They do not show anything in "Preview" and if you open the link, it opens empty. I can sftp on the command line and "get thelink" and it transfers just fine. I cannot recall if this is a new problem or if this has always been a problem. I think I would recall if symlinks behaved this way in the past, because I have numerous symlinks -- but I can't swear kate behaved one way or the other in the past. I know there are limitations with the sftp protocol that requires treating links as directories and only falling back to treating them as a file if changing into the directory fails -- but kate should be smart enough to do that since that is handled by sftp itself. Is this a new problem or a problem that has always been there? -- David C. Rankin, J.D.,P.E.

1 0

Re: vscode/vscodium file-choose broken on Tumbleweed - No such interface “org.freedesktop.portal.FileChooser”
by David C. Rankin 17 Nov '24

17 Nov '24

On 11/16/24 3:29 AM, Masaru Nomiya wrote: > DCR> 02:32 wizard:~> /opt/vscodium-bin/codium > DCR> [56965:1116/023333.000043:ERROR:object_proxy.cc(576)] Failed to call method: > DCR> org.freedesktop.DBus.Properties.Get: object_path= > DCR> /org/freedesktop/portal/desktop: org.freedesktop.DBus.Error.InvalidArgs: No such > DCR> interface “org.freedesktop.portal.FileChooser” > DCR> [56965:1116/023333.000324:ERROR:select_file_dialog_linux_portal.cc(287)] Failed > DCR> to read portal version property > > Have you installed xdg-desktop-portal? Yes, xdg-desktop-portal was slipped in as a dependency to MozillaFirefox from openSUSE -- but the portal file chooser logic using kdialog is BROKEN for KDE3 because KDE3 kdialog does not have an --attach option. This broke Firefox and vscodium/vscode. The portal fileChooser (originally a Flatpak interface to avoid sandbox issues) only works to pick native file dialogs for "some" desktops and "breaks" others. Thankfully mozilla provides an option to turn it off so file dialogs work again. I found this after 1/2 a gigabyte of unnamed downloads appeared in the ~/Downloads folder: 18:55 wizard:~> l -rt Downloads/ total 672580 drwx------ 48 david david 4096 Nov 16 18:55 .. drwxr-xr-x 2 david david 4096 Nov 16 19:46 . -rw-r--r-- 1 david david 303335 Aug 28 02:36 IRF9Z24.PDF -rw-r--r-- 1 david david 529687 Aug 28 02:37 IRF9130.PDF -rw-r--r-- 1 david david 174833 Aug 30 23:49 cd00003223.pdf -rw-r--r-- 1 david david 317328 Oct 18 01:54 settings.png -rw-r--r-- 1 david david 776370 Oct 18 01:55 settings.xcf -rw-r--r-- 1 david david 316833 Oct 18 01:56 settings1.png -rw-r--r-- 1 david david 113122 Oct 18 01:57 settings1-fs8.png -rw-r--r-- 1 david david 5524488 Nov 9 21:27 frag_bunny.mp4 -rw------- 1 david david 148378619 Nov 16 16:39 i7Rmj0w8.gz.part -rw------- 1 david david 148378619 Nov 16 16:39 5-v9QHZY.gz.part -rw------- 1 david david 20331269 Nov 16 16:40 -3bU-fu3.gz.part -rw------- 1 david david 20331269 Nov 16 16:40 eF7LSKQs.gz.part -rw------- 1 david david 26288471 Nov 16 16:40 PyNivark.zip.part -rw------- 1 david david 26288471 Nov 16 16:40 0QZUksul.zip.part -rw------- 1 david david 148378619 Nov 16 16:50 VSCode-linux-x64-1.95-3.tar.gz -rw------- 1 david david 142220013 Nov 16 17:18 xtr905zZ.rpm.part All of the *.part files are source and binary downloads of vscode and vscodium, but since the file-chooser was broken, no dialog was presented for download, and no filename was ever formed by Firefox -- so the download icon never appears in the toolbar letting you know something is downloading -- and when the thing finishes downloading, it cannot be renamed to a real filename since that was never optained by firefox due to the dialog failure.... The xdg-desktop-portal thing isn't fully-baked yet. Whether you get a file-dialog displayed cannot depend on what desktop you are running. Proper programming would validate the file-dialog is open and ready for use, and if not, a sane fallback dialog (e.g. the default gtk fileChooser) should be shown. I know I can't be the only one bitten by this one. cc: kde3 list -- since this is a live issue for KDE3 -- David C. Rankin, J.D.,P.E.

1 0