<Nulo>
How can I enable Sticky Keys? Nothing seems to work.
<leon-p>
Nulo: If it's not in the docs, it does not exist.
<Nulo>
Thanks, I will go cry myself to sleep now. /j
<Nulo>
It seems no one ever needed this on Sway either
<leon-p>
It's a common problem with accessability features: The people that need them stay on the software that has them, so other software rarely gets them.
snakedye has quit [Read error: Connection reset by peer]
snakedye has joined #river
ext0l has quit [Ping timeout: 260 seconds]
leon-p_ has joined #river
leon-p has quit [Ping timeout: 252 seconds]
snakedye has quit [Ping timeout: 252 seconds]
novakane has joined #river
anb has quit [Ping timeout: 252 seconds]
anb has joined #river
leon-p_ is now known as leon-p
ext0l has joined #river
snakedye has joined #river
<leon-p>
I wonder if we should stop sending key release events to clients for keys which had a keymap on press.
<leon-p>
some clients (looking at you, firefox) also handle release events even if they never got the press event, which gets a bit awkward
<emersion>
you mean when switching keymap?
<leon-p>
no, "keymap" is rivers word for "keybind"
<emersion>
eh that's confusing :P
<leon-p>
my specific problem: I have something bound to Mod4+Escape and when I watch videos fullscreen in firefox, FF leaves fullscreen when just receiving the "release" event from the bind
<emersion>
but yeah, if you eat the press event, i think it's a good thing to also eat the release event
<dnkl>
Second that
<leon-p>
who wants to open the issue? :P
<novakane>
well you're the “collaborator” so :P
<ifreund>
leon-p: we call it a mapping not a keymap no?
<ifreund>
skipping the release event if river eats the press makes sense. We can't really do the same the other way around thoug
<ifreund>
that is, we can't skip the press event if river eats the release do to a mapping
pkap has joined #river
<leon-p>
why not? When a press event is handled river can find out if there is a release mapping
<leon-p>
it only gets messy when the order in which keys get released is different then the press order, but that is for both cases
<leon-p>
f.e. a user presses Super, Alt, j, then releases Alt, j, super. We can not just block a Mod4+Mod1+j release being send, as it would be a Mod4+j release. We would need to block all j releases.
<ifreund>
ok yeah forget what I said, though it's technically possible for mappings to change between press and release
<pkap>
I observed that with the latest commit, floating views are also resized to full when moved to another output. I guess this isn't intentional?
<ifreund>
uh, yeah fix incoming
<pkap>
I think they are not "real" fullscreen but floating resized to the output's resolution.
<ifreund>
indeed, I just forgot an if statement
<ifreund>
pkap: fixed :)
<novakane>
so is there a way to get toplevel per tags? How can this be implemented, I can't find anything to help me
pkap has quit [Ping timeout: 256 seconds]
<ifreund>
novakane: you mean from a client using the currently available protocols? no
<ifreund>
assuming I understand what you mean correctly that is
<novakane>
ifreund: yes, with a client only getting toplevels from the focused tag instead of all toplevels
<novakane>
is that something planned for river-toplevel protocol?
<ifreund>
yeah that's something that I would like to be possible eventually, no concrete plans on how/when though
<leon-p>
novakane: a tag <-> client relationship is something clients currently can not know. However, if you are only interested in the clients of the currently focused tags, just use the active state of foreign toplevel
<leon-p>
(it will probably not be frame-perfect though)
<novakane>
leon-p: but I would only have one toplevel max per tag with the active state no?
<leon-p>
novakane: true
<leon-p>
confused it with a non-existing "is visible" state
<leon-p>
maybe if river advertised non-visible clients as "minimized" via foreign-toplevel, but I am not sure if that is a good idea
<novakane>
yeah what I mean is for something like that I would display only the toplevel from the focused tags https://0x0.st/-gaO.png
<novakane>
could be adding bug elsewhere I guess with minimized
<snakedye>
Ig the generally meaning of minimized is not drawn and I don't think it would create conflict anywhere. I think it would be the opposite. It's more meaningful information.
<leon-p>
I tend to agree
<emersion>
minimized != hidden
<leon-p>
what's the practical difference?
<emersion>
minimized is something the user has chosen (click minimize), hidden is when you don't need to render
<emersion>
hidden has many different variations: partially hidden, hidden behind a semi-transparent window, etc
<emersion>
minimize is policy, hidden is much more low-level
<leon-p>
Ah, I see what mean
<emersion>
but i'm maybe missing context
<leon-p>
in that case I'd argue that a user focusing a different tag/workspace is minimizing, not just hiding.
<emersion>
foreign-toplevel's definition of "minimized" is really "click on minimize button", not hidden
<snakedye>
Focusing a tag is choosing what you want to see so I don't really see a conflict there
<emersion>
as in, xdg-shell's set_minimized
<leon-p>
emersion: but even in traditional desktops there are other ways to minimize a window, for example clicking on it in the task switcher widget in the panel. Would that count? Because that is also not something the client does itself.
<emersion>
yeah, everything that has the same effect as set_minimized
<emersion>
but yeah, for compositors which don't have a concept of minimizing… the line is blurred
<ifreund>
river doesn't honor set_minimize requests, therefore I don't think it should ever set the minimized state
<leon-p>
I am think we can still set a state even if we ignore the clients requests to change it
<leon-p>
s/am//
<emersion>
that's a bit inconsistent
<emersion>
taskbars may have a "unminimize" button for minimized windows
<emersion>
and it would do nothing
<leon-p>
taskbars also have a "focus" button and that also does nothing (currently)
<emersion>
you don't implement focus?
<leon-p>
and even if we don't ever set the minimized state, the existence of those request in the protocol already implies the existence of the state
<leon-p>
emersion: not currently.
<ifreund>
activation works if the given output is already focused
<emersion>
but it should be pretty easy to add, no?
<emersion>
whereas implementing minimize/unminimize would be fundamentally not possible?
<ifreund>
exactly
<leon-p>
but what should it do? Add the view to the current tag(s)? Add the tags of the view to the outputs tags? that's the problem
<emersion>
what problem are you trying to solve exactly?
<ifreund>
the latter
<emersion>
yeah, xdg-shell has some gnome-y assumptions
<emersion>
would be nice to add a "supported states" event
<ifreund>
indeed, and foreign-toplevel management as well by extension
<leon-p>
emersion: you mean wrt the minimize thing? I think it would be nice to use that state to know which views are currently visible.
<ifreund>
I think that would be an abuse of the protocol
<emersion>
how do you define "visible"?
<leon-p>
(view_tags & output_tags) > 0
* emersion
should try river
<leon-p>
in sway terms I would define visible as "this view is on the currently focused workspace".
<emersion>
yeah, sounds like an abuse
<leon-p>
TBH I still don't see why
<emersion>
the taskbar will assume that it can toggle the minimized state
<emersion>
it's just inconsistent to half-support minimized
<ifreund>
river doesn't have any concept that corresponds to the GNOME/xdg-shell minimized concept
<emersion>
^
<leon-p>
since the existence of the minimized state is already implied, a taskbar will expect that anyway, won't it?
<ifreund>
therefore we should never set that state
<snakedye>
Should the protocol be adapted to be more flexible?
<emersion>
no, instead, we should teach xdg-shell to indicate minimized isn't supported
<emersion>
then apps can hide the minimize button in their client decorations
<emersion>
and taskbars can hide it too
<snakedye>
I idea of hidden is still significantly more common than minimize. If the concept would be replaced, compositors would have more leeway
<leon-p>
so by your definition minimized is "hidden, but individually toggle-able"?
<emersion>
"hidden" is very vague
<emersion>
if i place a floating window on top of a tiled window in sway, is it hidden?
<emersion>
(the tiled one0
<emersion>
)
<snakedye>
Not drawn/unmapped/surface=nul
<emersion>
no, minimized is an on/off knob the user can toggle
<leon-p>
well, from /that/ perspective, if I click minimize on a trad. deskop, the window is gone. But if I focus a different tag on river, the window is gone too. In _some_ way they are similar
<emersion>
if you switch to a different workspace on GNOME Shell, the rest of the windows aren't minimized
<ifreund>
yeah, GNOME has workspaces too
<ifreund>
there is a ext-workspaces protocol up for review that aims to address this use-case
<leon-p>
I'll be honest. I still think that is a totally arbitrary distinciton and it really does not make much sense ot me...
<ifreund>
it would be far more complex to implement for both river and clients than the current river-status though
<snakedye>
Minimizing a group of windows and unminimizing another set effectively acheives the same thing as changing workspaces
<snakedye>
Desktops like Windows and KDE have this idea of minimizing multiple windows
<leon-p>
can we also have wayland-terms-explained.org? pretty please?
<novakane>
+1
<snakedye>
I also find it problematic that the definition of minimize implies the window is reduced to a taskbar button which is straight up not what happens in GNOME
<snakedye>
So even them don't respect the definition of minimize
<ecocode__>
I currently use swayidle to turn the display to black when idle. However I'd like to turn the display complete off (disable), so to be a bit more ecological. I can do it by using ```wlr-randr --off``` but then all views on the display get ported to the primary display. Is there a way to make river just ignore displays getting on and off when getting in and out of idle sleep ?
<leon-p>
also nowhere in the xdg-shell protocol does it say that the concept of minimization is tied to the user being able to toggle it individually per window, as seems to be the consensus here. Since some people apparently don't think that is implied, it should be explicitly added into the protocol.
<ifreund>
ecocode__: you can use a client implementing the output power management protocol for that, for example https://git.sr.ht/~leon_plickat/wlopm/
<ifreund>
wlr-randr doesn't implement power management, only configuration
<ifreund>
now I just need to spend some time with valgrind to make sure I didn't screw anything up
<leon-p>
I wonder if it makes sense to compile a general test suite for both X and XDG-shell clients…
<ifreund>
I want automated fuzz testing that we can run on CI eventually
<leon-p>
neat
<ifreund>
I sadly don't have that much time yet though
<leon-p>
although I suppose a lot of testing can't be automated since it requires someone to stare at a screen and decide whether something looks right
<ifreund>
the point would mostly be to catch crashes
<novakane>
I can be paid to stare at a screen if you want :P
snakedye has quit [Remote host closed the connection]
snakedye has joined #river
<Nulo>
I got sticky keys working!!
<Nulo>
I had it mostly done since the start but I was f-ing up the XKB_* variables
<Nulo>
Is there a way to reload a keyboard layout without restarting river
<Nulo>
?
<ecocode__>
ifreund: thx for solving the xwayland dialog bug !
<ifreund>
no problem!
<ecocode__>
river is pretty stable here
<ecocode__>
xwayland is a bit more prone to bugs
<ecocode__>
but the problems I still have are common to river / sway / gnome , so it is clearly xwayland stuff.
<ecocode__>
I love that river handels super+keys even when in a virt-viewer window. awesomewm sucked at this
leon-p has quit [Ping timeout: 252 seconds]
<ecocode__>
ifreund: I know window opacity is a considered a eyecandy feature, which I totally agree with. with awesomewm I used picom to make inactive windows slightly dimmed. it increases active window detection for the eye. would you consider this eyecandy too?
<ecocode__>
s/window opacity/window transparancy/
<ifreund>
ecocode__: river had that feature for a while but I removed it for simplicity while the core functionality matures. I'll likely re-add a way to set the opacity of windows in a more flexible way in the future
leon-p has joined #river
<ifreund>
but I wouldn't merge that feature right now, there are other things that need to get done first
<ecocode__>
this is not about transparancy, although maybe related. just about dimming (=darkening a window)
<ecocode__>
but yes, it is not an urgent feature ;)
<ifreund>
same thing really. The actual implementation isn't that hard, it's making it configurable and flexible that's tricky
<ecocode__>
oh ok :)
<ifreund>
and there are some more basic questions about how river is going to support better programability going forward that need to be solved first
<ecocode__>
👍
<ecocode__>
I now have 2 monitors connected to my laptop. one normal and the other hidpi. the laptop's screen is also hidpi. river is rock solid _and_ beautiful on this setup!
<leon-p>
regarding eye-candy, once river is a bit more stable I'd like to investigate the possibility of user shaders and stuff like that. Generally I feel eye candy has its place, especially since it sometimes can help with accessibility, but doing it right is not always trivial
<novakane>
I was reading git log, new domain ifreund?
<leon-p>
ifreund: btw, I think you forgot to change your mail adress on your website
<ifreund>
it sucks that the world is this way, but I guess I'm not idealistic enough to take a stand against it. isaacfreund.com is a bit more professional too
<ifreund>
leon-p: thanks, I hadn't updated my email dns stuff when I made the inital website migration
<novakane>
ah damn here I am with a .xyz too, but then it's not really professional and almost only used for git forge
<leon-p>
I personally gave up on having a domain, it's not really worth it. Espcecially since search engines index my github profile higher than it anyway. (also by not having a domain I can kinda cheat the law and not have an Impressum, which also nice)
<novakane>
ifreund: out of curiosity where did you buy your domain name?
<ifreund>
novakane: namecheap
<novakane>
leon-p: yeah well it was cool when I had a server on rasberry pi but now I almost only use to have a better mail name...
<ifreund>
novakane: yeah there's nothing totally horrible with a .xyz domain and it worked fine for me for quite a while, I just decided that since there are some advantages to isaacfreund.com it would be better to make the change now or never
<ifreund>
and I chose now
<leon-p>
just be sure to always renew it. There are some weird companies that buy name domains that have been in use for some time, probably because they suspect the person with the name will eventually want to buy them back. Technically you can sue for a domain with your name, but realistically it's not worth the effort and they know that.
<novakane>
ifreund: ah yeah I almost take mine with them but go with namesilo instead
<ifreund>
leon-p: yeah, I've got auto-renew set up
<novakane>
ifreund: I get you, probably depends on what you want, I don't need a website so I don't care but for blog, portfolio things linke that isaacfreund.com is cool
<leon-p>
having a personal website always intrigued me, I have a lot of stuff I wanted to share, like massive amounts of pictures f.e.. But renting a server is expensive and having my own is awkward with consumer-grade internet, so text-only it is for now. Also German law makes running personal websites annoying when you have a toplevel domain. No wonder social media killed personal websites.
<novakane>
what's wrong with German law?
<leon-p>
novakane: Basically when you run a website, you must have up to date contact information, including adress or PO box, on the site, unless it is strictly personal. But "strictly personal" is defined in a way that my little blog thing would not count, as I talk about things other than myself. Technically no one in law enforcement actually cares, but there are some law firms that threaten to sue people to black mail them into
<leon-p>
paying massive amount of money.
<ifreund>
I just use github pages for mine, which is free and fine for static content
<leon-p>
yeah, I use sourcehut pages, which is basically the same.
<novakane>
leon-p: oh yeah ok, address sucks :/
<leon-p>
novakane: yeah. My mother runs a buisness and eventually wants to get a PO box, so when she has I can add that, but until then I just don't have a toplevel domain
<novakane>
I understand, it would pissed me off to put my adress like that online, that's weird
<snakedye>
You can have a blog but first doxx yourself 😎👍