Bug 519631 - The Dynamic Launcher Portal does not have a button to accept the proposed launcher
Summary: The Dynamic Launcher Portal does not have a button to accept the proposed lau...
Status: RESOLVED FIXED
Alias: None
Product: xdg-desktop-portal-kde
Classification: Plasma
Component: general (other bugs)
Version First Reported In: 6.6.2
Platform: Fedora RPMs Linux
: HI normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 517124 (view as bug list)
Depends on:
Blocks:
 
Reported: 2026-05-01 00:35 UTC by Ryan Brue
Modified: 2026-05-20 15:18 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 6.6.5
Sentry Crash Report:


Attachments
The dialog that shows up when triggering the dynamic launcher portal. (66.20 KB, image/png)
2026-05-01 00:35 UTC, Ryan Brue
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Brue 2026-05-01 00:35:43 UTC
Created attachment 191956 [details]
The dialog that shows up when triggering the dynamic launcher portal.

SUMMARY

When using the dynamic launcher portal to install desktop entries, there is no confirmation button to actually install the app, just a pop-up with the app name and icon. The app doesn't get installed when closing this dialog.



STEPS TO REPRODUCE
1. Install the ASHPD Demo from Flathub: https://flathub.org/en/apps/com.belmoussaoui.ashpd.demo
2. Use the dynamic launcher section to test installing an app or web app

OBSERVED RESULT

No button to confirm installing a desktop entry

EXPECTED RESULT

A button to confirm installing a desktop entry

SOFTWARE/OS VERSIONS
Windows: N/A
macOS: N/A
(available in the Info Center app, or by running `kinfo` in a terminal window)

Operating System: Fedora Linux 44
KDE Plasma Version: 6.6.4
KDE Frameworks Version: 6.25.0
Qt Version: 6.10.3
Kernel Version: 6.19.14-300.fc44.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × 12th Gen Intel® Core™ i5-1245U
Memory: 16 GiB of RAM (15.3 GiB usable)
Graphics Processor: Intel® Iris® Xe Graphics

ADDITIONAL INFORMATION

Unsure which version is the first to have this regression, or if it ever worked in the first place.
Comment 1 Bug Janitor Service 2026-05-08 02:57:01 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/552
Comment 2 Nate Graham 2026-05-08 13:28:19 UTC
Git commit f07493b7ffb6423fea0fe3db157203693a3299a8 by Nate Graham.
Committed on 08/05/2026 at 13:28.
Pushed by ngraham into branch 'master'.

PortalDialog: fix standard button handling

The top-level standardButtons property was aliased to something in a
component, which then referred back to the top-level property! And the
whole button box would only be visible if any of its own buttons were
shown (not taking into account custom buttons).

This was fine in cases where implementations specified which buttons
they wanted, but failed in the case where they wanted none and also
specified their own set of custom actions.

Untangle this by specifying default buttons in the top-level property
and making visibility take into account custom actions.

As a cleanup, now we can remove all the requests for the standard
buttons in the implementations (they'll fall back to the defaults).
FIXED-IN: 6.6.5

M  +0    -2    src/AccessDialog.qml
M  +2    -0    src/DynamicLauncherDialog.qml
M  +0    -1    src/GlobalShortcutsDialog.qml
M  +0    -2    src/InputCaptureDialog.qml
M  +2    -2    src/PortalDialog.qml
M  +0    -2    src/RemoteDesktopDialog.qml
M  +0    -2    src/ScreenshotDialog.qml
M  +0    -2    src/UsbDialog.qml
M  +0    -2    src/UserInfoDialog.qml
M  +0    -2    src/WallpaperDialog.qml

https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/f07493b7ffb6423fea0fe3db157203693a3299a8
Comment 3 Nate Graham 2026-05-08 14:47:24 UTC
Git commit b67b6e092e4109941e57915f59f40db0b9d60fec by Nate Graham.
Committed on 08/05/2026 at 14:27.
Pushed by ngraham into branch 'Plasma/6.6'.

PortalDialog: fix standard button handling

The top-level standardButtons property was aliased to something in a
component, which then referred back to the top-level property! And the
whole button box would only be visible if any of its own buttons were
shown (not taking into account custom buttons).

This was fine in cases where implementations specified which buttons
they wanted, but failed in the case where they wanted none and also
specified their own set of custom actions.

Untangle this by specifying default buttons in the top-level property
and making visibility take into account custom actions.

As a cleanup, now we can remove all the requests for the standard
buttons in the implementations (they'll fall back to the defaults).
FIXED-IN: 6.6.5


(cherry picked from commit f07493b7ffb6423fea0fe3db157203693a3299a8)

a60e8955 PortalDialog: fix standard button handling

Co-authored-by: Nate Graham <nate@kde.org>

M  +0    -2    src/AccessDialog.qml
M  +2    -0    src/DynamicLauncherDialog.qml
M  +0    -1    src/GlobalShortcutsDialog.qml
M  +0    -2    src/InputCaptureDialog.qml
M  +2    -2    src/PortalDialog.qml
M  +0    -2    src/RemoteDesktopDialog.qml
M  +0    -2    src/ScreenshotDialog.qml
M  +0    -2    src/UsbDialog.qml
M  +0    -2    src/UserInfoDialog.qml
M  +0    -2    src/WallpaperDialog.qml

https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/b67b6e092e4109941e57915f59f40db0b9d60fec
Comment 4 David Redondo 2026-05-20 07:35:56 UTC
*** Bug 517124 has been marked as a duplicate of this bug. ***