Storing session? about ashpd

[bilelmoussaoui]

I am not familiar with that portal, you should ask people who wrote the portal.

[bilelmoussaoui]

Or some KDE developers to explain where those sections come from

[tytan652]

while using global shortcuts i've noticed every time create_session is called (and shortcuts are bound to it) it creates a new section in KDE's shortcut settings.

This sentence give the impression that you did not understand how the portal flow works (it can really differs from what you are used to), so it may not work like you expect. I may be wrong.

The paradigm of the portal expects you to gave a set of bindings in advance, after that the application has no control besides closing the session.
Note, that you can create multiple session but the user will get a prompt for each session.

i wish to avoid this.

You can't avoid this, this is how the portal is designed. The user only way to change a binding it through the DE settings.

is this even a reasonable way to do what i want to do? i couldn't find anything related to this in the x-d-p documentation

You did not clearly explain what you want to do.

[tuxinal]

my apologies for not being clear. by that i meant i have tested multiple create_sessions at the same time so i could find out if the new set of bindings in the DE settings are caused by that. i don't intend to actually use multiple sessions at the same time.
my issue right now is every time my app starts i have to call create session and that causes a whole new set of keybinds to be created - but they aren't even enabled because the ones from last session are still enabled and are blocking the new ones to take effect. i assumed by loading the session from last time i could avoid that. but there is no way to do that (and i don't really have any evidence that might work in the first place, so i thought to ask)

[bilelmoussaoui]

my issue right now is every time my app starts i have to call create session and that causes a whole new set of keybinds to be created - but they aren't even enabled because the ones from last session are still enabled and are blocking the new ones to take effect. i assumed by loading the session from last time i could avoid that. but there is no way to do that (and i don't really have any evidence that might work in the first place, so i thought to ask)

that looks like an issue on the KDE implementation