Okay so it turns out theres a link to the single relevant docs you need buried in the c code and nowhere else
#🖥-vesktop-development
floral ledge
basically its the desktop environment's or window manager's job to launch applications as systemd units
the correct way to do this in hyprland is to use uwsm app https://wiki.hyprland.org/Useful-Utilities/Systemd-start/
this gives me an appid
better yet i can modify the appid with a command line argument
You may or may not spot the bug immediately
Mysteriously that is printing the request handle
This is quite literally a typo
Dude how the fuck does no one notice this shit
This will LITERALLY never work
God forbid you use ListShortcuts because its arguments are mixed up
Absolutely incredible
scenic hollow
wow linux desktop IS doomed
crazy how there is an entire api that no one has actually tested to at least make sure it works
floral ledge
crazy how there is an entire api that no one has actually tested to at least mak...
As a side note
You are completely correct about KDE's implementation
And that singular line
Because if you look.. hyprland finds by appid!!!!
Even though from a surface level it looks like this will break after opening multiple sessions because of a separate issue, it uses appid!!
not appid + unique garbage
for keybinds
But it should be replacing the old session not adding a new session with the same appid, will cause the same duplication issue
so thats a separate issue
scenic hollow
yeah i don't think it will matter for vesktop. vesktop has a single instance lock thingy on its own
floral ledge
yeah i don't think it will matter for vesktop. vesktop has a single instance loc...
no no
the problem is even after a session is closed
m_vSessions is not cleaned
scenic hollow
ah
floral ledge
The unique_ptr is never freed
Only the underlying session dbus object and request dbus object
floral ledge
wow linux desktop IS doomed
ohh my god
i made a pr on my own repo
thanks github
worst ui EVER...
Who knew keybinds could be so complicated
Year of the linux desktop
floral ledge
ah
Also heres the Official™️ year of the linux desktop developer response for why nothing using xdp works https://github.com/hyprwm/xdg-desktop-portal-hyprland/issues/56#issuecomment-1533659631
"The spec fucking sucks"
simple groveBOT
floral ledge
https://github.com/hyprwm/xdg-desktop-portal-hyprland/pull/310
ITS ALREADY MERGED
pr description: "I have not tested this at all and made it with the github web editor"
Maintainer 15 minutes later: "thanks" merged
gg
i sure hope the 2 apps in existence that use global shortcuts dont break
hot juniper
Also heres the Official™️ year of the linux desktop developer response for why n...
this is rather ironic because vaxry isn't immune from breaking spec either (see asahi moment)
hot juniper
ITS ALREADY MERGED
LMAO
floral ledge
you would never see this kind of development speed in kde .. Only hyprland
floral ledge
ah
can we just use a wayland client and use input method v2 over the wire or something
scenic hollow
what even is that
floral ledge
what even is that
hyprland supports it guys!!
oh m y god wait
you cant even use this
it sinks input
scenic hollow
i'd also assume it wouldn't work with flatpak
hot juniper
can we just use a wayland client and use input method v2 over the wire or someth...
what are you even trying to achieve at this point
floral ledge
what are you even trying to achieve at this point
Global shortcuts on wayland
On X11 its like super dooper easy
On wayland its a disaster
hot juniper
what does input method v2 have anything to do with shortcuts
floral ledge
I misread the spec
it would work if it didnt sink all input and not allow the compositor to further process the input events
if it did not sink input then you could just use it like x11 or windows input processing where you just get key up/down events for all input
hot juniper
i think i get what you're trying to do now
scenic hollow
On wayland its a disaster
yeah but that's kinda intentional for "security" or whatever i don't think there would ever be a protocol making it as easy as it is on x11
floral ledge
and not a very good one at that
floral ledge
yeah but that's kinda intentional for "security" or whatever i don't think there...
Yeah i know its intentional
hot juniper
yeah but that's kinda intentional for "security" or whatever i don't think there...
wayland moment
floral ledge
its so you can grant an app permission to register global shortcuts
or something
instead of giving apps all input for free
hot juniper
i don't think i've ever encountered an app that misbehaves in a way where wayland's security model would've prevented it from misbehaving
ehhhh some fullscreen jank in games maybe but idk
floral ledge
Global shortcuts seem to be a rare exception. And not "misbehaving" just "no one has implemented the compositor support"
hot juniper
Global shortcuts seem to be a rare exception. And not "misbehaving" just "no one...
yeah I know
floral ledge
I did not realize before today how poor of a state xdg-desktop-portal and related spec implementors were in though its like really bad
had not even touched d-bus before today
scenic hollow
it's just that the spec is kind of ass and is poorly implemented everywhere but i think global shorcuts as a whole is very much in the scope of xdp i don't think we should look elsewhere for this
floral ledge
Oh yeah for sure
I don't think there is elsewhere
it was wayland protocols or the highway
and theres no wayland protocol that will hand over input or shortcuts as is necessary
hot juniper
is xdp where features that couldn't get a wayland protocol go to die be implemented badly
floral ledge
so just have to deal with the crap spec and crap implementation
The sad part is it could actually be a good spec
It's just documented so so poorly that it sucks
Like... wow! Thanks for the SENDER where it doesnt tell me what the SENDER should be, only the TOKEN other than "callers unique name"
Which in every implementation of the spec seems to be the same generation as TOKEN where its just random
oh unique name
is it just the bus name
yeah its just the bus name
no one actually does that though
hot juniper
I'm not going to pretend that I have actually tried to implement any of this, I haven't
one day I might try to implement it
floral ledge
And then the portal spec doesn't even mention app ids
only the desktop impl spec
The desktop impl spec doesnt tell you how these app ids are acquired
floral ledge
https://systemd.io/DESKTOP_ENVIRONMENTS/
This is buried in a random C file in xdg-desktop-portal code and finally clarifies it
hot juniper
I don't really have a whole lot of advice but good luck reverse engineering the code because the docs won't get you anywhere
floral ledge
Nothing that launches .desktop apps seems to actually launch them with app ids on hyprland at least except hyprland's suggested uwsm app solution
hot juniper
I once tried to make a plugin to integrate with KDE's notification system
floral ledge
from what I understand freedesktop notifications dbus didnt look too bad
hot juniper
the docs for that were so bad that you had to read the code to understand how to do text replies
floral ledge
since it seemed actually documented
hot juniper
from what I understand freedesktop notifications dbus didnt look too bad
this is a poorly documented extension to that though
floral ledge
ew
hot juniper
afaik the library just adds some extra properties to it
floral ledge
the docs for that were so bad that you had to read the code to understand how to...
😭
floral ledge
xdg-desktop-portal hard-coded only supports appids from
- Systemd units following the https://systemd.io/DESKTOP_ENVIRONMENTS/ spec
- Flatpak apps
- Snap apps
that information alone took a hour and a half of code diving
hot juniper
😭
floral ledge
because I had no clue what part of the toolchain actually handled app ids
so I checked the xdg-desktop-portal-hyprland backend and hyprland itself
hot juniper
so you are saying if you launch vesktop from a terminal everything breaks lol
floral ledge
Yes.
Unless on Hyprland you use uwsm app -- vesktop
Which on the fly generates a spec conforming systemd unit
and runs it
floral ledge
Mind you it took like 3 hours and no extra libraries other than a widestring library for C FFI to implement the WIndows venbind support
because uiohook supports it out of the box and its super easy
and winapi just directly supports the input event processing globally
X11? just as easy
hot juniper
do people want the security model to be broken because the sandboxing is just that horrible to work with?
floral ledge
It wouldn't even be horrible to work with its just that xdp needs to be implemented for every single compositor with their own display portal backends
hot juniper
it feels like they are begging you to read the input devices directly
floral ledge
and none of them have remotely complete implementations
floral ledge
it feels like they are begging you to read the input devices directly
literally
Like I really like wayland but I understand why a bunch of boomer developers hate it so much
hot juniper
guh
scenic hollow
guh
hot juniper
you know what else is funny
chromium's wayland support
it doesn't even enable support for the input method protocol by default
floral ledge
chromium's wayland support
free joke:
<insert any major app here that isnt made in rust and is 2020 or newer>'s wayland support
hot juniper
doesnt vesktop flatpak do something about that
hot juniper
free joke:
<insert any major app here that isnt made in rust and is 2020 or newe...
😭
ok now
give me an example
floral ledge
i refuse because i am a liar
hot juniper
does krita even have wayland support yet
inb4 they are waiting for color management protocol or something
floral ledge
mind you this is the software being talked about
scenic hollow
apparently not i didn't look at all the patches and stuff but at least not on any of the official packages (by which i mean i've only checked the flatpak)
floral ledge
Stable since 2012!
simple groveBOT
humble mortar
@scenic hollow @floral ledge could I get a tldr of what you guys talked about
holy shit
it IS the desktop file
why tf does it not work when run from kitty
thats so misleading
so the Session docs say it should be unique and non guessable
but not if it should or shouldnt persist across runs
from the behaviour it seems that it should persist
but like idk??
Im pretty sure the portal is meant so that once an app registers a shortcut it shouldnt be allowed to change them. That falls to the de/wm via the settings app and the app listens for ShortcutsChanged to reflect those
humble mortar
from the behaviour it seems that it should persist
This is the only thing that makes sense
cause if its off appid an app can only have one shortcuts instance
actually no maybe youre supposed to change the shortcut ids then??
idfk
floral ledge
Im pretty sure the portal is meant so that once an app registers a shortcut it s...
The venbind workaround is to unregister and deregister them
we need to do that because of discord settings
simple groveBOT
floral ledge
you can unregister the binds??
Venbind does a hack where it just removes it from its internal array
and makes a new id
Think they still end up being registered though
in xdg
humble mortar
theyd still exist i think
floral ledge
yes
humble mortar
so thats a terrible implementation 😭
it should just listen for changes
it should really just create all ids without a preferred shortcut then let the user set them from the settings and use ListShortcuts to reflect the bind in discord settings
but not let them be 'changed' from there (cant anyway)
floral ledge
so thats a terrible implementation 😭
The implementation is terrible because it's not done yet
❓
floral ledge
<@339669513912057857> <@124411800681709570> could I get a tldr of what you guys ...
the kde implementation being in fact the issue
along with hyprland's implementation being even more broken than the kde implementation
floral ledge
xdg-desktop-portal hard-coded only supports appids from
- Systemd units followin...
codedived documentation
for appids
humble mortar
The implementation is terrible because it's not done yet
ah i thought you were saying thats what was final for it
floral ledge
no
venbind doesnt even have keybind released support rn
the enum is there its just never fired
floral ledge
it should really just create all ids without a preferred shortcut then let the u...
well wtf does the regular discord client do on linux
does it just read the input device directly or some garbage workaround
to having to deal with xdp
floral ledge
gg
humble mortar
heres a terrible idea
run a tiny app under xwayland to consume inputs while the main vesktop can be wayland
floral ledge
The input stuff doesnt work correctly under xwayland if i recall??
humble mortar
depends on the de
humble mortar
hyprland feeds the inputs defined in the conf to the app
honestly this is what the globalshortcuts protocol shouldve been
app tells portal what inputs it uses for binds
easy peasy
floral ledge
globalshortcuts should have been anything other than what it is right now
do any apps even use it
floral ledge
both desktop portal backend implementations that exist for it were broken
humble mortar
theres some dead prs
one on mumble
floral ledge
the hyprland one is probably still broken all i did was fix 1 part of it
im fairly sure when I am able to test it with latest xdg-desktop-portal-hyprland commit there will be the issue I predicted of session duplication
similar to kde
but for a different reason
humble mortar
the hyprland one tries to find an appid but it always fails so apps cannot have conflicting shortcut ids or it explodes
floral ledge
the hyprland one tries to find an appid but it always fails so apps cannot have ...
does not always fail!
humble mortar
oh?
floral ledge
oh you didnt see that bit of the conversation
that shitty systemd spec i mentioned?
hyprland has a recomended way/helper of launching apps with those systemd units
it is at the very bottom of the docs
floral ledge
if you launch with the uwsm app helper
it will on-the-fly generate a spec conforming systemd unit]
for the executable
and run it
humble mortar
thats some insane hacky shit
floral ledge
you can use the -a argument to configure the app name which is the same thing as app id
floral ledge
thats some insane hacky shit
its apparently.. not?
like the wholee idea of the spec is you run apps in systemd units
humble mortar
????
floral ledge
floral ledge
https://wiki.hyprland.org/Useful-Utilities/Systemd-start/#launching-applications...
"The concept of a session managed by Systemd implies also running applications as units."
systemd-managed compositor session apparently implies running apps as units
floral ledge
there wouldnt be
there would be a uhh
app-something-codium-waylanddesktop.service
or something
idfk
depends on how ur launching it
floral ledge
????
Trust me its beautiful
You either run as a systemd unit, flatpak, or snap, or else you get a literal empty string as the app id
humble mortar
but then why does it work for vscode and not from kitty
how they handle child processes?
floral ledge
hyprland is not always ran with uwsm/not always systemd-managed
floral ledge
but then why does it work for vscode and not from kitty
They spawn vscodium with the .desktop parameters
using kio I think
Try kioclient exec <vscode .desktop location>
humble mortar
nono my globalshortcuts script
running from kitty it doesnt get an appid in the settings applet
running from vscodium it does
which is why i assumed the session handle was supposed to be its appid
humble mortar
system package
floral ledge
ok
humble mortar
just like kitty
floral ledge
let me look
humble mortar
i have to assume its how they spawn their child processes
floral ledge
I imagine a child process also counts as being inside the systemd unit
xdg-desktop-portal uses sd_pid_get_user_unit on the pid
So that pid is still returning the codium user unit
Yeah ok systemd manages child processes in the unit
unless you manually specify with a directive to not manage them
Why the hell is none of this documented in an easily accessible fashion anywhere lol
Ah yes just you know "the way desktop environments should and have to launch all applications to conform with the spec and make xdg-desktop-portal and a bunch of other stuff work correctly"
humble mortar
so kitty spawns child scopes
humble mortar
so silly
floral ledge
so kitty spawns child scopes
app-kitty-4332-0.scope would work perfectlyt
not joking
floral ledge
well no
or maybe actually
it depends on if kitty implements it or if kde implements it
I would figure vs code wouldnt work properly either if kde implemented it
floral ledge
so kitty spawns child scopes
is kitty being launched with a shortcut
like a .desktop file or
floral ledge
thats some insane hacky shit
Please consult the xdg-desktop-portal spec maker as seen in this photo. You can find them at the best buy geek squad
And systemd spec maker
humble mortar
sour muralBOT
https://github.com/kovidgoyal/kitty/blob/7722ba8b8a94bcb4c940107bf525709a2e64daa...
child.py: Line 360
fast_data_types.systemd_move_pid_into_new_scope(pid, f'kitty-{ppid}-{self.id}.scope', f'kitty child process: {pid} launched by: {ppid}')
oh my god it is kitty's fault
thats hilarious
I dare you to build it with app- prefix
humble mortar
so many hours of yelling at dbus confused about the session token for this
floral ledge
wait
its just python
can you just go edit a python file
and see if it works
or do they bundle it
floral ledge
so many hours of yelling at dbus confused about the session token for this
This is me after I had to code dive for 4 hours to figure all of this out by the way
humble mortar
lets see
worn harness
@humble mortar hiii
floral ledge
ah
humble mortar
i just screenshoted that instead of scrolling up
floral ledge
this spec made me so unhappy yesterday this is why i stick to windows development
😭
even msdn is better
phd required in systemd-ology
humble mortar
nope?
floral ledge
ummm
floral ledge
nope?
u might have to build it i guess
it seems not very hard to build
no special insane requirements
floral ledge
are they on my fs and bundled in the executable
It says python is a runtime dep not a buildtime
nvm lmfao
it says its both
wtf
humble mortar
its c + python so might be funkiness with that
anyway yeah it works when built
wheres the pid parsing code
or the spec that defines the naming scheme
floral ledge
wheres the pid parsing code
gg
floral ledge
or the spec that defines the naming scheme
It fucking sucks you sure you want it hang on
heres the naming scheme spec https://systemd.io/DESKTOP_ENVIRONMENTS/
its the same thing
humble mortar
app[-<launcher>]-<ApplicationID>-<RANDOM>.scope
floral ledge
wheres the pid parsing code
https://github.com/flatpak/xdg-desktop-portal/blob/main/src/xdp-app-info-host.c Here is the HIDEOUS code
humble mortar
app[-<launcher>]-<ApplicationID>-<RANDOM>.scope
lmao
humble mortar
yea
floral ledge
thats so tragic
humble mortar
what the hell is launcher supposed to be
floral ledge
its just stored on fs for no reason
floral ledge
what the hell is launcher supposed to be
what
humble mortar
app[-<launcher>]-<ApplicationID>-<RANDOM>.scope
.
humble mortar
its just stored on fs for no reason
time to ask the packager starege
floral ledge
WAIT @humble mortar i lied
i see it
app-KDE-org.kde.okular@12345.service is an example there
so the -KDE would be a launcher'
The launcher is optional
i dont think anyone uses it
because it sucks
humble mortar
floral ledge
so there is
evidently kde doesnt use it
floral ledge
so kdes parser sees the third - and assumes the launcher is in use
How do u know
humble mortar
looking at the behaviour
floral ledge
wait what is the behavior tho
humble mortar
humble mortar
.
floral ledge
Ooooooooh my god
humble mortar
AND THAST WHY I WAS CONFUSED
floral ledge
That makes no sense
Why is that part of the appid
thats not how that works
where is this code
humble mortar
kde my beloved
humble mortar
how do you dump the globalshortcut sessions
sour muralBOT
https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/blob/master/src/session.h...
session.h: Line 188
return m_appId + m_token;
because of the one line bug
floral ledge
how do you dump the globalshortcut sessions
I don't know I was literally running xdg-desktop-portal-hyprland in a terminal window before to get the logs
and they do a deubg log whenever a session is opened
You could try a d-bus debug tool
its in arch extra
humble mortar
let me try qdbusviewer first
floral ledge
Or bustle https://gitlab.gnome.org/World/bustle https://archlinux.org/packages/extra/x86_64/bustle/ also in extra
if you cant get qdbusviewer going
You also can't see "active" sessions, what you will be able to see is the dbus createsession requests over the wire
I am suspect if you will be able to see the appid though, it depends on how these dbus viewers work
humble mortar
humble mortar
anyway
humble mortar
meaning it wont always be demoapp here
how does the app/system resend the shortcuts to the right client
in my script im doing this
which relies on the session token persisting
floral ledge
what i dont understand is if its based on the appid
Appid is supposed to be constant
The session handle should be fully unique
The appid is the one constant that is supposed to be used by the implementation to track shortcuts
The spec does not say this but it is very obvious
humble mortar
but the appid doesnt get sent over the bus
floral ledge
Because one app has its specified global shortcuts
floral ledge
but the appid doesnt get sent over the bus
Oh my sweet summer child
You're right it doesn't
humble mortar
😭
floral ledge
What happens is
It gets sent over to xdg-desktop-portal
It is then forwarded to your compositor portal backend
so xdg-desktop-portal-hypeland
floral ledge
https://github.com/flatpak/xdg-desktop-portal/blob/main/src/xdp-app-info-host.c ...
This is AFTER
humble mortar
**session.h:** Line 188
```h
return m_appId + m_token;
```
ok pretend kde didnt have the this bug
floral ledge
it has gone through this bullshit
humble mortar
ok pretend kde didnt have the this bug
how does the client reconnect and listen for the right shortcuts
floral ledge
So once it hits the xdg backend it looks like this https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.impl.portal.GlobalShortcuts.html
this is the actual d-bus implementation
Its at a different interface name
Than the client d-bus
humble mortar
yupp i used that for my impl
floral ledge
yupp i used that for my impl
what..
humble mortar
to know what to send over dbus
floral ledge
are u sure u didnt use org.freedesktop.portal.GlobalShortcuts.CreateSession
ohh
wait
show me ur createsession request
..?
humble mortar
def create_session(self):
# Create a new session
options = {
'handle_token': f'demo_1', # Spec recommends a persistent prefix & a random suffix that CANNOT clash with later handle_tokens
# Didn't bother with random impl (doesnt need to persist across runs though)
# https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Request.html
'session_handle_token': 'demoapp' # https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Session.html
}
handle = self.shortcuts_interface.CreateSession(options)
self.setup_request_handler(handle, self._handle_session_response)
def setup_request_handler(self, handle, callback):
print(f"\n{handle}\n")
request = self.bus.get_object('org.freedesktop.portal.Desktop', handle)
request_interface = dbus.Interface(request, 'org.freedesktop.portal.Request')
request_interface.connect_to_signal('Response', callback)```❌ you did not in fact use the link i sent
you used https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.GlobalShortcuts.html
Two separate pages
Same name and look the same though
floral ledge
you used https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.p...
This is the client D-Bus interface
floral ledge
So once it hits the xdg backend it looks like this https://flatpak.github.io/xdg...
This is the XDG backend D-Bus interface
humble mortar
im gonna lose it
floral ledge
see one is the .impl
humble mortar
yup
floral ledge
The backend one is used by xdg-desktop-portal-hyprland and xdg-desktop-portal-kde
They get those impl d-bus requests from xdg-desktop-portal
floral ledge
```python
def create_session(self):
# Create a new session
optio...
Xdg-desktop-portal takes in the client d-bus interface so it takes in waht is being sent here
floral ledge
This is the XDG backend D-Bus interface
It does its crap and gets the appid and stuff and then translates that and sends it to the target backend also over d-bus with this interface
So the backend interface (xdg kde, hyprland) will get the appid as acquired by xdg-desktop-portal
humble mortar
so .impl is what happens in the background
floral ledge
so .impl is what happens in the background
Yep!
The spec does not say how you should store settings/shortcuts, but I would imagine you should do this with the app id only because the session documentation page says that the session sender and token are basically always unique
It says that the "SENDER" bit is the caller's unique name
"with the initial : removed and all . replaced with _"
However it does not expound upon "unique name"
What it really means is the bus name
This is called "unique name" in the dbus spec
"Unique names are never reused for two different connections to the same bus."
Bus name is provided by the system dbus implementation
On arch with the default dbus-broker isntead of reference impl that can be found here since its provided by org.freedesktop.DBus.Hello https://github.com/bus1/dbus-broker/blob/main/src/bus/driver.c#L928-L955
sour muralBOT
On arch with the default dbus-broker isntead of reference impl that can be found...
driver.c: Lines 928-955
static int driver_method_hello(Peer *peer, const char *path, CDVar *in_v, uint32_t serial, CDVar *out_v) {
const char *unique_name;
int r;
if (_c_unlikely_(peer_is_registered(peer)))
return DRIVER_E_PEER_ALREADY_REGISTERED;
c_dvar_read(in_v, "()");
r = driver_end_read(in_v);
if (r)
return error_trace(r);
peer_register(peer);
unique_name = address_to_string(&(Address)ADDRESS_INIT_ID(peer->id));
c_dvar_write(out_v, "(s)", unique_name);
r = driver_send_reply(peer, out_v, serial);
if (r)
return error_trace(r);
r = driver_name_owner_changed(peer->bus, &peer->name_owner_changed_matches, NULL, NULL, peer);
if (r)
return error_trace(r);
return 0;
}
so if kde didnt have that 1 line bug and i correctly randomized the session handle my impl would work
and the mapping and shit would happen transparently in the background by kdes portal
floral ledge
**driver.c:** Lines 928-955
```c
static int driver_method_hello(Peer *peer, cons...
The peer->id in this is just a linearly increasing number per peer connection during the life of the dbus broker, which is what I saw with my testing on arch which lines up
So in sum: After 6 hours of research from a base level of not knowing about or never having used xdg-desktop-portal beyond just having it installed because the hyprland documentation said to, I have concluded that it is in fact KDE's bad implementation and no one else's fault
nor having used d-bus before this
floral ledge
and the mapping and shit would happen transparently in the background by kdes po...
Yes
What KDE should be doing is associating it to app id as the only unique ident
I suspect this could be an issue in cases where the app id is empty though
Which happens if you arent launching an app in a Fucking Systemd Unit
That should be worked around on KDE's side however
humble mortar
but kde would assume theyre always in a systemd unit because they handle that
floral ledge
run an app from a terminal window
it wont run in a systemd unit if the terminal wasnt running in a systemd unit
or may not run in a systemd unit at all
even if the terminal was in a systemd unit
what happens if you run codium from kitty or something
does it actually run with a vscodium .scope
I think for kitty it will just run in a new kitty child .scope
If you had a way of directly executing something outside of a systemd unit you could repro
on hyprland for example you need uwsm app -- <application> explicitly even with kitty so
Unless that changes if I run kitty in uwsm app
probably true
humble mortar
yeah its in konsole's scope here
and since kitty names their scopes wrong itd fail there
which is why you see a pure vesktop entry in the settings applet
thats one run from kitty
floral ledge
yeah its in konsole's scope here
This isn't even kde's fault lmao they get htis appid from xdg-desktop-portal
God this spec is so stupid and bad
When the spec is so bad it cant correctly identify app ids of child processes someone fucked up
"You must not launch any apps from a terminal window unless you use a helper, otherwise your app id is screwed!"
floral ledge
yeah its in konsole's scope here
I find it interesting and of note that the app id here doesnt have some random session token appended
humble mortar
I find it interesting and of note that the app id here doesnt have some random s...
it has the one i specified vesktop
floral ledge
oh I see it
humble mortar
thats due to kitty not following spec in their .scope creation
floral ledge
That was 94065 the "app name" in the .scope which is just a pid
humble mortar
so it pulls the wrong section as the appid
floral ledge
sponsored by kitty
humble mortar
yupp
floral ledge
appended with demoapp
humble mortar
which was the session_handle_token for that run
floral ledge
This is org.kde.konsole appended with vesktop session handle
How hard is it to submit a kde patch lol
humble mortar
not hard
make a kde invent account
and open a pr on their gitlab
then sign in https://invent.kde.org/users/sign_in
floral ledge
time to use github web editor to submit a patch to kitty
may not be that easy
The issue is if you want it to be even somewhat reasonable you would have to have a way of getting the actual app id of the child process being executed
You would have to implement a uwsm app equivalent
if you wanted it to be actually reasonably useful
And I doubt that's actually desirable behavior
humble mortar
kitty spawns a scope for each terminal tab
it doesnt relate to the process running in it
the scope name just needs to follow the spec for that
which would be app-tabid-kitty-ppid
the launcher in this cause is the tabid
which i think works
floral ledge
which would be app-tabid-kitty-ppid
This effectually does nothing
I think
Like your shortcuts will be uber broken and duplicate every time
I'm not sure if this is desirable behavior to have spec-conforming names because it will assign random appids to child processes
I think you're just intended to use uwsm app gioclient exec etc
floral ledge
Bad idea
floral ledge
yeah its in konsole's scope here
You'll get this crap
where its global shortcuts for "konsole"
when in reality its a child process of konsole
Only saving grace for konsole is their broken implementation
causing it to be random
But thats not actually a fix thats just a bug
humble mortar
nonono rn im just thinking about the fact that theyre spawning non spec conforming scopes for the terminal tabs
a real fix would be to spawn and kill scopes when a sub process runs
floral ledge
a real fix would be to spawn and kill scopes when a sub process runs
does stuff vanish from global shortcuts settings after the app is closed?
or session?
humble mortar
no
floral ledge
yeah so killing scopes wont fix that
humble mortar
nonooonoon thats not what im talking about
floral ledge
I know its spawning non-conforming scopes
Im saying it probably should be spawning non-conforming ones
floral ledge
yeah its in konsole's scope here
If it spawns conforming ones you get this
Once kde fixes the implementation that will just show up as org.kde.konsole
For any app executed by konsole
That will need to be fixed by konsole because that's really bad
Like world leading bad
humble mortar
a real fix would be to spawn and kill scopes when a sub process runs
which is why i said this
floral ledge
Hello yes my child processes actually just impersonate konsole because the appid is konsole
floral ledge
which is why i said this
But you'd have to spawn a child scope with a completely different appid
That completely different/random appid is also unhelpful
Because every time u open a child process it will make a new global shortcuts settings section
humble mortar
which is what the launcher section of the spec is for
floral ledge
And wont save
The launcher section of the spec doesn't fix that
You'd need a way to get the actual appid of the child process
so that it saves
floral ledge
Yeah it would be
because kitty names the scope
But to get the actual appid you'd need to generate it per how uwsm app does it
And that might not match the real app's .desktop appid
You'd have to look for a .desktop in the desktop entry locations matching the app and then if you cant find one generate one that is consistent between runs and unique to process names
Which is... a whole lot more trouble than its worth
compared to running uwsm app or kioclient exec
humble mortar
ok heres a thought
in reality are you running apps from the terminal outside of development
a user would use the desktop entry
so none of this matters
floral ledge
I don't think random appids are a desired development feature
humble mortar
yeah..
floral ledge
Free malware method: Create 1000 sessions and instantly close them all with random app ids
All with 1 shortcut
Feast upon the user's control panel
humble mortar
lol
floral ledge
😭
floral ledge
why couldnt the spec just include the appid as an arg
THAT would go against the security model
Imagine what you could do!
You could spoof being ANY app
And because the spec is not just global shortcuts: thats a problem
humble mortar
ugh
floral ledge
Global shortcuts is probably one of the least ever used parts of the spec
Rest of the spec has clipboard and camera access, screenshotting and screensharing
Hell apparently it has USB too
god usb over dbus sounds like such a fucking stupid idea
humble mortar
i think that one is meant for a sandbox env and the portal just exposes the device like normal if it has perms
floral ledge
Why did flatpak have to ruin everything
floral ledge
@brazen kite
humble mortar
💀
floral ledge
the maintainer talks in here
see from:tuxinal
the reason the github hasnt been touched is because of the issues I have spent 6 hours addressing over the past day and a half regarding that XDG pr being dead-stopped by a KDE bug
humble mortar
pause
its a cli app with no desktop entry
a gui app launched from the terminal still has its desktop entry correctly mapped
humble mortar
EXACTLY
humble mortar
there is no .scope
humble mortar
no
floral ledge
no
I am not sure how this is even possible
Either the app you executed is
- a flatpak
- a snap
- not a executable file and is a wrapper script that runs the systemd unit
- a executable shim that runs the systemd unit, installed by ???
Fairly sure KDE has no control over you directly executing from terminal it doesnt just steal the application into a systemd unit surely
humble mortar
gui apps have a resourceClass/Name
.desktop entries map to that via the desktop entry name or a StartupWMclass entry inm the .desktop
let me throw my python script in a gtk window
floral ledge
floral ledge
.desktop entries map to that via the desktop entry name or a StartupWMclass entr...
ITS ANOTHER FUCKING PROTOCOL?
Oooooh my good
Great spec freedesktop
losing it
The last time this spec was modified was 14 years ago
This spec is over 22 years old
humble mortar
which means its perfect and has no flaws
floral ledge
why do linux developers use git servers from the 90s
I can never be bothered to go git clone these I go look for a download button and there never is one
hallelujah I found the spec
the link is broken
on the actual freedesktop page
it's a X protocol
humble mortar
watching a windows dev find out about this is so funny
windows is arguably worse but its undocumented so even more terrible
floral ledge
I could never daily drive this it would be so over for me trying to make anything
Like. If the specs were a bit better documented and the implementations were complete?
This would be nicer to use than fucking windows
humble mortar
wayland is still very insane
floral ledge
Instead its fucking terrible garbage because the specs are slightly bad and there is 0 documentation
and only wizards who work on it daily know how it works
no one else
humble mortar
be the change you want to see
learn about it all with the intent to improve the docs
then dont and become one of the wizards
floral ledge
Someone has to document things but its not gonna be me because fuuck that
disaster
they should have documented it properly when they wrote it 😭
why does the systemd desktop environments "spec" have like
10 TODO: markers on it
just in the spec
when were those TODOs put there they are never getting finished
thats not todo that's never happening
humble mortar
5 years to merge a single protocol you think this will be normal
floral ledge
First release of xdg desktop portal
2016
Global shortcuts proposed
Sep 2021
PR? Feb 2022
Somehow took all the way until Sep 2022 to be merged
humble mortar
you have NO idea
floral ledge
2 years and 4 months later and not a single app has used it
Beyond a fucking mumble pr
That went nowhere
It's just still open
Sat there for like 2 years
How has no one bothered fixing any of this
Is it primarily because of the difficulty of requiring 1 solid day of codediving to figure out how a single protocol works
floral ledge
Like its just crazy how many developers there are yet none of it has been fixed
its just a giant clusterfuck
I've seen developers complain about wayland anything before and I thought it was just overexaggeration/unwillingness to learn new things
Dead wrong
The uiohook guy actually gave up on wayland
"Wayland was a nice idea created by a bunch of academics who have spent more than a decade solving a problem no one had."
floral ledge
watching a windows dev find out about this is so funny
I had no idea it was this maddening
Was left wordless by this pr https://github.com/hyprwm/xdg-desktop-portal-hyprland/pull/310
Okay I took another look
Hyprland implementation is in fact actually fine
Because what it does is it will register the shortcuts once for an appid, then when u reopen that app it will make a new session in m_vSessions
getShortcutById will find the old shortcuts but it changes the shortcut session to the current one in registerShortcut
It would have broke before but it was fixed earlier this year in a pr https://github.com/hyprwm/xdg-desktop-portal-hyprland/pull/241
So hyprland should work now with the listshortcuts change
simple groveBOT
scenic hollow
okay i think i'll make a pr for the kde portal and then i'll start merging things tomorrow
floral ledge
Should just rename venbind and have it be a general purpose Electron-compatible rust api for any app to use for global shortcuts because doesnt seem like theres any alternatives at all with X11, Wayland, Darwin, and Windows support
floral ledge
okay i think i'll make a pr for the kde portal and then i'll start merging thing...
I was gonna do it tbh I made a stupid kde identity account
floral ledge
Should just rename venbind and have it be a general purpose Electron-compatible ...
solve the issue for anyone in the future so that no one has to deal with a bunch of crap ever again??
advent of the linux global shortcuts sponsored by vencord
humble mortar
honestly why not just pr this shit into tauri's global_hotkey
floral ledge
Stupid amount of work
humble mortar
already does x11 windows and macos
floral ledge
venbind windows is going to need more annoying work too
for some reason uiohook's windows input hook keeps firing key triggered when you hold it down
as if you were typing
i'll either have to store the active keybinds in thread local and compare
and also have to loop over all keybinds or have active keybinds in thread local storage for releasing a keybind
because you have to check if the last key or any of the modifiers have been released
which is awesome
scenic hollow
venbind windows is going to need more annoying work too
not to mention all the compiling issues with node bindgen guhh
floral ledge
not to mention all the compiling issues with node bindgen guhh
That is solely the CI
Because u have nix insanity on it
I dont know whats going on with that garbage cmake error
scenic hollow
yeahh we should maybe change that..
humble mortar
for some reason uiohook's windows input hook keeps firing key triggered when you...
GLobalShortcuts does this by default too
floral ledge
Because it has a working gcc install
floral ledge
GLobalShortcuts does this by default too
humble mortar
GLobalShortcuts does this by default too
does ashdpd have built in debounce?
floral ledge
my face
ashpd is literally about as good as a raw wrapper
it is just a wrapper over the dbus interface
definitely not
humble mortar
yeah
but more bloated
it doesnt even do dbus itself it uses zbus
so like use that directly and skip the ashpd step
simple groveBOT
Discord Account
No response
Motivation
When you start streaming discord can send a notification to other people and there is no way to disable/enable that on vesktop
Solution
the option below to be included in vesktops streaming menu
Alternatives
this should be a feature of vesktop
Additional context
discords stream menu
vekstops stream menu
brazen kite
<@602104493034831872>
I can talk in here now
floral ledge
👋
brazen kite
I had no idea there was a channel in here like this
apologies for the confusion
lol
floral ledge
Its literally accurate
Worst spec I have ever read
It's less a spec and more of a shit guideline
No one implements it correctly
brazen kite
I think that's what vaxry was talking about too
floral ledge
yes
floral ledge
Also heres the Official™️ year of the linux desktop developer response for why n...
see here
"it fucking sucks" basically
brazen kite
Please consult the xdg-desktop-portal spec maker as seen in this photo. You can ...
LOL
I joined here hoping I could somehow help with this but I think it might be above my pay grade
brazen kite
https://wayland.app/protocols/input-method-unstable-v2
if I'm not mistaken, I think this one is used by like IMEs and such
floral ledge
if I'm not mistaken, I think this one is used by like IMEs and such
probably
floral ledge
https://ideas.obsproject.com/posts/2066/implement-globalshortcuts-portal
so stupid
brazen kite
I know this is really stupid, but an alternative approach is to just support each desktop's implementation of global shortcuts if the xdg one is just so inconceivably terrible...
I found this for KDE and I know someone linked the hyprland one somewhere in here
this one
brazen kite
oh...
humble mortar
the portal isnt inconceivably terrible as well
its just wayland moves very slow so implementations are basically non existent
brazen kite
vesktop pioneering wayland development!
humble mortar
so many bugs exist in the portals that implement it
brazen kite
it's just a shame that vesktop is the first to step on this field of landmines
humble mortar
@scenic hollow @floral ledge is one of you gonna pr to kdes portal
humble mortar
it's just a shame that vesktop is the first to step on this field of landmines
we arent
scenic hollow
<@339669513912057857> <@124411800681709570> is one of you gonna pr to kdes porta...
i'm working on it yup
humble mortar
just the only one that is continuing (slowly) instead of giving up
send me the patch to test before u pr
brazen kite
I found [this](https://api.kde.org/frameworks/kglobalaccel/html/index.html) for ...
it looks like the framework implementation takes advantage of the org.kde.kglobalaccel dbus interface?
scenic hollow
send me the patch to test before u pr
diff --git a/src/session.h b/src/session.h
index 674f3ee4..7d7dedec 100644
--- a/src/session.h
+++ b/src/session.h
@@ -185,7 +185,7 @@ public:
}
QString componentName() const
{
- return m_appId + m_token;
+ return m_appId;
}
Q_SIGNALS:
i'm in the process of testing it. struggling to compile because nix 
brazen kite
it looks like the framework implementation takes advantage of the `org.kde.kglob...
oh it's completely undocumented 👍
humble mortar
wtaf it automatically creates sub request interfaces if the token is the same and the interface request is the same
humble mortar
```diff
diff --git a/src/session.h b/src/session.h
index 674f3ee4..7d7dedec 1006...
horrorifying
wait nix builds everything on your system
can you not just add a patch thing
scenic hollow
wait nix builds everything on your system
it doesn't it has a binary cache
i mean it can but that's what you'd usually want to use
but it's a bit more complicated than that idk there is probably an easier way to do it
humble mortar
@scenic hollow @floral ledge
the settings kcm needs to be updated to pull the name from the .desktop & a case needs to be added for if theres no appid
floral ledge
I found [this](https://api.kde.org/frameworks/kglobalaccel/html/index.html) for ...
Bad news! It doesn't work on wayland
humble mortar
also in the pr mention starting from konsole it takes konsoles appid
floral ledge
KGlobalAccel oonly works on wayland through xwayland magic
and the kde legacy shortcuts support
from what I had found before
floral ledge
<@339669513912057857> <@124411800681709570> is one of you gonna pr to kdes porta...
Yeah once i finish work
floral ledge
```diff
diff --git a/src/session.h b/src/session.h
index 674f3ee4..7d7dedec 1006...
nevermind!
unless tux hasnt pr'd this by the time i finish working
humble mortar
they wont accept the pr with the issues i mentioned
scenic hollow
the settings kcm needs to be updated to pull the name from the .desktop & a case...
ok yeah that's probably actually important
sly cairn
humble mortar
i think i just corrupted my shortcuts in the settings kcm
lmfaoo
oh nvm
it just crashed
yeah its def corrupted
lMAo
uhh
ok so dont use that patch and start an app without an appid
how do i fix this lmao
how do i manually wipe the portal entries
ok restarting plasma fixed it
guess they have a failsafe thingy
floral ledge
the settings kcm needs to be updated to pull the name from the .desktop & a case...
hyprland handles the no appid case by just not relying on the appid
humble mortar
i was thinking just return m_token if m_appId is empty/null
which is effectively the current behaviour
floral ledge
i was thinking just return m_token if m_appId is empty/null
yeah that was my thoughts for an easy fix
scenic hollow
diff --git a/src/session.h b/src/session.h
index 2f03c994..f04d69ad 100644
--- a/src/session.h
+++ b/src/session.h
@@ -180,7 +180,10 @@ public:
}
QString componentName() const
{
- return m_appId + m_token;
+ if (m_appId.isEmpty()) {
+ return m_token;
+ }
+ return m_appId;
}
Q_SIGNALS:
this should be enough i think. i still haven't managed to get it to run for some reason please do test
humble mortar
it should also have a prefix so it cant possibly accidentally or intentionally end up as a valid appid
QString componentName() const
{
// return m_token if m_appId is empty. This can happen if the app/process
// is launched without a systemd scope/service (without this it could return nothing)
// prefix m_token so that apps cannot accidentally or intentionally create an entry
// that has the same appid as a propper app
return m_appId.isEmpty() ? QString("token_") + m_token : m_appId;
}
works
where the hell is the source code for the shortcuts ui
found it
scenic hollow
does this sound completely incohesive it's 3am i can't tell
humble mortar
you shouldnt specify 'wrapping libraries' say thats what the spec says
also make sure to mention the settings kcm needs to be updated to pull the name from the desktop entry instead of using the appid
scenic hollow
do you think this is of any use in that regard https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/blob/master/src/session.cpp?ref_type=heads#L407
sour muralBOT
do you think this is of any use in that regard https://invent.kde.org/plasma/xdg...
session.cpp: Line 407
action->setProperty("componentDisplayName", componentName());
here they've set the display name to be the same as the component name maybe they should change that instead
humble mortar
**session.cpp:** Line 407
```cpp
action->setProperty("componentDisplayName", com...
idk
where does it pull the desktop icon
i'd assume thats where the name stuff should be done
scenic hollow
also make sure to mention the settings kcm needs to be updated to pull the name ...
should i still add that or
humble mortar
well the pr makes the portal actually usable and if its not displayed correctly to the user that also makes it unusable in a way
just add it as a note
like "Currently the settings kcm displays the name of the app as the appid. It should use the name defined in the .desktop entry no?"
it does for manually added apps from the kcm so i see no reason for portal entries not to
scenic hollow
ok done and now we wait and i go to bed gn yall
humble mortar
Nicolas Fella
floral ledge
@scenic hollow mind if i just update all the deps in the windows pr as well
ran cargo update but a lot of these deps have newer major versions
i want to swap to napi-rs too but can save it for a new pr maybe?
humble mortar
dep updates in prs make insane merge conflicts
floral ledge
dep updates in prs make insane merge conflicts
not really
well
in a bigger project - yes
in a project with 2 prs, both of which are tiny - no
i dont even know if either pr uses a dependency in a incompatible way with the updates
floral ledge
ok done and now we wait and i go to bed gn yall
Also you got a reply from a maintainer with a review change and a commit name change
so should be a pretty swift merge after that 5 minutes of work
humble mortar
<@339669513912057857>
also this
humble mortar
idk I dont think it should be separate
feels completely in scope with the existing one
floral ledge
idk I dont think it should be separate
eh
scenic hollow
yeah i was about to do that
floral ledge
are you able to just change the merge request name or do you have to use git and rewrite the commit name
scenic hollow
i'm honestly not quite sure what they meant by that i think if just put it in the description and set it to squash it will have the same effect?
floral ledge
_i'm honestly not quite sure what they meant by that_ i think if just put it in ...
no I think they want it in the commit name
so squash it and change the commit name
floral ledge
_i'm honestly not quite sure what they meant by that_ i think if just put it in ...
ok nice
floral ledge
_i'm honestly not quite sure what they meant by that_ i think if just put it in ...
Maybe change the commit message a bit more to also highlight that it's adding the .desktop display name??
since not in merge request title/description
I predict maintainer will ask you to do that
okay ur commit msg is a bit cooked
technically works
scenic hollow
oh yeah i just noticed
floral ledge
I love how gitlab doesnt just show a force push it shows this ugly crap
scenic hollow
Maybe change the commit message a bit more to also highlight that it's adding th...
but it's technically already there
floral ledge
but it's technically already there
if they actually care about adding the BUG: tag to the commit msg I am going to bet they would care about the "apply 1 suggestions"
might be annoying for it to get reviewed then go have to remove that bit is all
scenic hollow
i mean the bug tag is related to their bugzilla workflow i don't think they would care if the apply is there idk
i'll remove it sure
floral ledge
i'll remove it sure
okay cool there should be a 0% probability it needs another suggestion in review
unless they hate ternaries or something
😭
humble mortar
you love git squash spam
simple groveBOT
simple groveBOT
humble mortar
guh found another bug in kdes impl
if you create a shortcut and the preferred trigger is already taken itll report that the trigger belongs to you even though it doesnt
restarting session will fix it but bleh
simple groveBOT
simple groveBOT
floral ledge
if you create a shortcut and the preferred trigger is already taken itll report ...
no way
Have not tested but I think hyprland doesnt even register a shortcut
or well. it does but it doesnt register input for it until u add it to the cfg file
from what i saw
humble mortar
Have not tested but I think hyprland doesnt even register a shortcut
that seems fine if it returns no bind
floral ledge
it does return the bind
because it is "registered" in hyprland
it just wont receive input events
humble mortar
oh 😭
floral ledge
i think
humble mortar
it should completely disregard the preferred shortcut entry since its entirely config based
floral ledge
basically you run the program. then you run hyperctl globalshortcuts to get the list
then you can put that in your hyprland config
humble mortar
it should completely disregard the preferred shortcut entry since its entirely c...
who implemented that 😭
floral ledge
all shortcuts in hyprland are done with config file
humble mortar
so if you register a shortcut then call ListShortcuts it'll return a keybind that it has?
even if you dont define it in the config?
floral ledge
Because it's "registered"
It doesn't receive input events
It is "registered"
If you add it to the config file it will receive input
But i could be wrong
humble mortar
registered and having a bind are different things
humble mortar
ListShortcuts returns an array of the id description and a text string of the binds it has
if hyprland is returning values in the bind list even if there isnt anything in the config thats an issue
floral ledge
humble mortar
I'll check later
sour muralBOT
https://github.com/hyprwm/Hyprland/blob/main/src/protocols/GlobalShortcuts.cpp
h...
KeybindManager.cpp: Line 641
for (auto& k : m_vKeybinds) {
Please enjoy the code
The shortcut is registered in the portal
It is registered through hyprland's wayland protocol extension
That extension does not add it to m_vKeybinds
That is only filled by the hyprland config
ergo the input event handler will never pass it to the global dispatcher
humble mortar
ok thats fine then
floral ledge
unless it is defined in the hyprland config as a keybind
humble mortar
the bind field is optional meaning the portal doesnt have to listen to what the app says it wants as the bind
KDE reports the wrong info though which is the issue
floral ledge
Yeah kde is separate issue]
floral ledge
the bind field is optional meaning the portal doesnt have to listen to what the ...
what i am saying is
the global shortcut will do NOTHING
not work
it will be registered in hyprland and in the portal
it will just receive 0 input
until you do this thing
humble mortar
yeah thats expected
same thing happens on KDE if the bind the app requests conflicts
floral ledge
so preferred bind does not matter on hyprland basically
humble mortar
same thing happens on KDE if the bind the app requests conflicts
but KDE still tells the app the bind is in action and belongs to that shortcut which is the issue
floral ledge
yeah thats a separate issue
humble mortar
so preferred bind does not matter on hyprland basically
yep perfectly fine impl that makes sense for a config based thing
floral ledge
if you create a shortcut and the preferred trigger is already taken itll report ...
so "trigger" as in just a preferred key right
so one app requesting/registering a preferred key and then another requests it and kde reports this as Fine And Working
Did anyone working on kde or hyprland actually try these implementations before adding them in
humble mortar
floral ledge
Because it really seems like they havent even been tested beyond bare basics
The hyprland listshortcuts issue is a prime example
That would not have survived any call of it
Even if you fuck up implementing the spec in your test app then the other functions in that file wouldnt have worked
All the KDE issues would have been found in 5 minutes with a test app
The hyprland one was like "Tested this on the mumble pr" before adding it in but the mumble pr uses listshortcuts and it would not have worked correctly at all and not only that it spits a very obvious message telling you its not working into the xdg-desktop-portal-hyprland log
humble mortar
so one app requesting/registering a preferred key and then another requests it a...
App 1 has shortcut a. its bound to ctrl 1
App 2 Spawns in and tries to register shortcut b for the first time with a preferred bind of ctrl 1. kde says oh ok and tells App 2 ctrl 1 belongs to shortcut b. (in reality it doesnt)
App 2 closes and reopens with a new session. it calls ListShortcuts and now sees shortcut b correctly doesnt have a bind (ctrl 1)
floral ledge
App 1 has shortcut a. its bound to ctrl 1
App 2 Spawns in and tries to register...
yeah thats what i thought
The hilarious part is
Hyprland just CRASHED before if you did a duplicate shortcut
hyprland now correctly handles the duplicate shortcuts by not registering them
humble mortar
App 1 has shortcut a. its bound to ctrl 1
App 2 Spawns in and tries to register...
the entire first app 2 session is tainted with this bad shortcut b info unless a ShortcutsChanged signal is emitted
I dont even know where to begin looking for the issue in the code cause 2 different sessions should still be pulling the same data
floral ledge
oh my god