10:22 <Anderson-D> novakane: do you run spotify as xwayland or wayland btw?

10:22 <Anderson-D> I can see it running just fine with "--enable-features=UseOzonePlatform --ozone-platform=wayland" but then the ugly black XWayland window appears in addition to the wayland native one

10:24 <Anderson-D> I tried unsetting DISPLAY to prevent it from appearing but then spotify simply crashes

10:25 <Anderson-D> I think the version of electron they use simply does not handle wayland properly

10:26 <Anderson-D> And their support totally sucks. There's a ticket for missing MPRIS functionality and it's been ignored for years

10:27 <Anderson-D> I tried several othet unofficial clients but unfortunately they all are pretty unstable since they rely on web api

10:55 <Anderson-D> Another question: I'm trying to edit some code for river but any `std.debug.print` calls I add are not visible when executed from a tty. I can see them when I launch river from within river though. -log-level is debug. Any ideas of WAIDW?

11:13 <novakane> Anderson-D: xwayland, just to shitty with wayland for now :/

11:14 <novakane> you sebug.print are probably print to the STDERR so maybe try redirect it to a file

11:31 <Anderson-D> I tried debug.print, log.crit, log.info - no output on tty whatsoever

11:32 <Anderson-D> Only 2 log messages from wlroots, nothing from river

11:33 <Anderson-D> Weird, I redirected stderr to file and now I can see it

11:34 <novakane> how do you start river? you need `river -log-level debug` or to redirect to a file use `river -log-level debug >river.log 2>&1`

11:36 <novakane> use a debug build too

11:41 <Anderson-D> Yeah, works now! Thanks

11:42 <novakane> np

11:42 <Anderson-D> ifreund: Do you think `unfloat-filter-add`/`unfloat-filter-remove` is something that I could add? It would allow to override size_hints from certain windows and prevent them from floating

11:51 <Anderson-D> Something like http://ix.io/3IKb/diff

11:53 <Anderson-D> I've just tested and was able to get spotify appear non-floating

16:19 <leon-p> Anderson-D: the problem with such a patch is that in the near-ish future river will outsource /all/ window management to an external client, so I honestly don't think it makes a lot of sense to spend time fine tuning rivers current window management.

18:21 <snakedye> I will finally have my river shell/vm configured in dconf and dbus

19:04 <novakane> that sounds scary

19:12 <leon-p> both dbus and dconf are things that make sense in theory. A universal way for IPC and configuration management? Yes please! It's just held back by the implementation.

19:21 <novakane> agreed, curious to see how snakedye did this though

19:22 <leon-p> FWIW I'll also need to do some DBUS black magic when I eventually have time to work on my desktop project, although I'll probably put it into a separate helper program

19:26 <novakane> I just stop at using dbus-run-session river, that's enough dbus for me :P

19:55 <snakedye> novakane: did or will do?

20:03 <novakane> snakedye: ah, I misread, thought you already did so will do then

20:09 <snakedye> I did some dbus stuff with zbus (rust implementation) when I was experimenting with a notification deamon. It was pretty straightforward once but now I'm not so sure how things will be organized since I'm not just waiting for events.

20:12 <novakane> well good luck

20:12 <novakane> why do you want to do this?

20:29 <snakedye> You need some way to communicate information across all components of a shell if you want something that feels integrated. Dbus is seemingly the most convenient way

20:35 <novakane> fair enough

22:03 <snakedye> leon-p: will the view management protocol let clients unmap/remap windows and let them handle tags or workspaces on their own?

22:36 <leon-p> snakedye: yes, tags will be an implementation detail of the window management clients