I guess flatpak Prompt uses gsettings keyfile in glib-2.0 folder instead of dconf
I guess flatpak Prompt uses gsettings keyfile in glib-2.0 folder instead of dconf
Fjust to note in case you want to switch to flatpak some day & want those modifications
Joooh can you dump the settings somewhere? I wanna see if we can make modifications
FYou can fiddle with Prompt settings by hand, it will automatically write changes to these. Just refresh open file again.
It's similar to
Location should be
"$HOME"/.var/app/prompt.flatpak.name/config/glib-2.0/settings/keyfile
I read the older post that they added support for that in flatpaks
+ custom keyfile defaults, just like in dconf (but I can't find the documentation for that so I just manually remove keyfile & apply my changes to new keyfile)
https://blogs.gnome.org/mclasen/2019/07/12/settings-in-a-sandbox-world/
It's similar to
dconf watch /Location should be
"$HOME"/.var/app/prompt.flatpak.name/config/glib-2.0/settings/keyfile
I read the older post that they added support for that in flatpaks
+ custom keyfile defaults, just like in dconf (but I can't find the documentation for that so I just manually remove keyfile & apply my changes to new keyfile)
https://blogs.gnome.org/mclasen/2019/07/12/settings-in-a-sandbox-world/
Joh awesome, thank you this is very helpful
RQuick question for people with bazzite-deck-gnome:testing on OLED. What happens when you try to open Steam's touch keyboard (Steam key + X) while in the overwiev/app grid? Does everything work correctly or does screen freeze completely until you 'close' the keyboard (with B button)?
RBecause I'm having the latter.
KHow long until the new AMD raytracing stuff hits stable, roughly? I saw that there was a commit for it already I think?
DNvm
DIt should be in mesa 24
DBut ray tracing is already working with the current version of mesa
Kyeah, I think @Kyle Gospo said something about pushing a commit to testing for improved AMD raytracing performance, I was just wondering about the lead time from testing to stable (since I'm a wimp and am not willing to rebase to testing)
JIs there any interest in adding
keyd to the bazzite images? It provides much more flexibility in key remapping than what is provided in GNOME or KDE. Also, as Wine doesn't allow for key remapping, keyd could be used for swapping CapsLock with Control or to turn Alt-F4 into a no-op.J
TI dug into this menu the other day
Jhttps://github.com/semakusut/SBP-ROG-Ally found something cool
GitHub
ROG Ally Controller Theme. Contribute to semakusut/SBP-ROG-Ally development by creating an account on GitHub.
COk holy shit what the fuck are they putting into Ksnip to make it so fast?
KI need to look into it more, but I'm open to it
CI know @Craftidore uses it
CYup; can confirm. My config:
CIntriguing
CIt just runs as a service.
FCan this by chance make caps-lock react instantly?
C? It always should
Fit's not instant
Fit's delayed.
FI talked about this in #
bluefin
bluefinCI would be shocked if that is not an issue with your individual keyboard
FNo, it's a global issue
CMine has always worked instantly on every keyboard, computer, and operating system I have ever used
FHere's full conversation
https://discord.com/channels/1072614816579063828/1087140903031943178/1189304350925930516
https://discord.com/channels/1072614816579063828/1087140903031943178/1189304350925930516
CYou mean that its on keyup instead of keydown?
Fyes
CAh. "Delay" is both technically and semantically the wrong word for that
CBut I see you did link receipts verifying that it releases capslock on key-up, which is something I would not have noticed happening
CI don't see anything in the docs about that. You might be able to do something like have it act like shift while held down, but on release have it switch the capslock modifier like normal
CMy capslock outputs alt+space at the firmware level, and through Gnome configs I have double-shift output capslock
CI just tested it, and double-shift releases capslock on key(s)-down
FWill try, thanks
FI already use some xkb workaround which makes this issue slightly less apparent
FI type with Caps Lock for capital letters, that's why I notice it
CBut shift
FMuch worse ergonomics for typing to me
CThen bind shift to capslock
CThere have definitely been times where I wanted to define very specific key-up vs key-down behavior, so I get it
Fidk if it will behave as release as caps-lock, or just press
Fbut worth a try
CWorth a shot, yeah. Especially since double-shift does it on press for me
CIf your issue is with the ergonomics of pressing the shift key, putting shift's behavior on capslock seems the simplist solution, so you don't have to deal with the ergonomics of pressing shift.
You seem to want capslock to act like shift, with the exception that you have to turn it off afterward. It's fine if you want that, and are willing to work to have that, but to me it seems like a weird extra step to have to turn it off afterward, so why have that step entirely.
You seem to want capslock to act like shift, with the exception that you have to turn it off afterward. It's fine if you want that, and are willing to work to have that, but to me it seems like a weird extra step to have to turn it off afterward, so why have that step entirely.
CIf you just rebind caps to shift, it won't act like caps anymore. I think there may be a way with keyd to get it to act like both, but I'm not confident about that.
CI believe there is a way to make it behave like both with Gnome/KDE tweaks
