leopoldek has quit [Remote host closed the connection]
leviathan has quit [Quit: Client closed]
angry_vincent has quit [Read error: Connection reset by peer]
pfr has joined #river
maralorn has joined #river
waleee has joined #river
maralorn has quit [Ping timeout: 250 seconds]
pfr has quit [Quit: Quit]
angry_vincent has joined #river
Szadek36 has quit [Quit: off]
Szadek36 has joined #river
leopoldek has joined #river
<leon-p>
my river-wishlist is suddenly really small: "just" the WM protocol, an xdg-foreign implementation and some UI/UX stuff to allow manipulating views via touch / tablet (but I suppose that could be rolled into the WM protocol)
<leon-p>
Also flicker-free startup, but that's more a wlroots thing
<leon-p>
maybe a protocol for dock-apps, but that's stretching it
<leon-p>
(also I would probably never get that into wayland-protocols anyway...)
<lordmzte>
WM protocol? You mean a protocol that can control windows?
<lordmzte>
also what's a dock app?
<lordmzte>
and what's flicker-free startup? :P
<leon-p>
RE flicker-free startup: When you turn on your computer, do you notice how at multiple times during boot the screen modesets? I.e. sdeemingly turns off and on again? That can be avoided (most "user friendly" distributions do that by default). F.e. by using systemd-boot for UEFI, plymouth for a boot-splash and LUKS prompt and greetd for automatic log-in. Right now wlroots does not support the hand-off so there is still one superflous modeset in my boot when ri
<leon-p>
ver starts, but until that point it's flicker-free
<lordmzte>
Oh so going from TTY to WLR without modesetting again?
<leon-p>
and dock-apps are small, usually square, widgets for your desktop that provide some useful feature (i.e. status monitor) or something fun (there was one that showed battery percentage as the water level in a duck pond). They are currently hard to do right in wayland because the layer-shell does not support the usecase very well because it requires applications to decide their own decision and no compositor I know off implements any sort of stacking mechanism
<leon-p>
for layer surfaces that do not take up the entire output-edge.
<leon-p>
lordmzte: actually skipping the TTY entirely
<leon-p>
you replace that with a boot splash
<FireFly>
heh, I just start river from tty manually like a barbarian but maybe someday I'll set up an actual DM
<lordmzte>
I have my own login shell/launch menu/system daemon/environment loader/future service manager running on the TTY before river soooo...
<lordmzte>
I treat the TTY as the "default mode" of the system with the option to go to a graphical environment if needed.
<leon-p>
I treat the TTY as "can somebody please remothe this from the kernel? thanks"
<leon-p>
*remove
<leon-p>
it's a kernel built-in terminal emulator with an fbdev backend... *shudders*
<lordmzte>
hmm aren't these dockapps just libappindicator lol?
<leon-p>
nope
<leon-p>
they are proper little widgets you can interact with. They can f.e. also include little buttons and stuff
<lordmzte>
I like my TTY but I somewhat understand wanting to disable it... very slightly.
<leon-p>
you can have it back as a dedicated user-space program
<leon-p>
and just nuke the entire TTY layer in the kernel. Interpreting a text prompt and launching programs really does not need to be routed through the kernel...
<FireFly>
it's nice for recovery
<lordmzte>
eh good point
<FireFly>
but yeah I guess I see where you're coming from
<lordmzte>
I still see the TTY as the standard user interface for a computer, but that doesn't conflict with what you're saying :D
<leon-p>
it really doesn't. It can just be a dedicated daemon that renders it and interprets your commands / sends them to the shell
<leon-p>
you could even improve uppon what we have now, like displaying images and nicer colours
<leon-p>
or better fonts...
<lordmzte>
IIRC that was actually a thing that exists right now
<lordmzte>
an fbdev terminal emulator that's somewhat fancy
<leon-p>
there are projects like that, but IIRC they are all somewhat abandoned
<leon-p>
(foot in cage is a decent replacement though)
<FireFly>
I wouldn't mind the tty emulation running in userspace (and kinda agree with you there); as long as it's rock solid and dependable enough for recovery/fallback
<leon-p>
you already depend on a bunch of userspace code, even if booting into single-user recovery mode, so it should be perfectly possible
<leon-p>
what I really want is basically just a microkernel
<leon-p>
but less gimmicky than The Hurd
<FireFly>
yeah
<FireFly>
same honestly, but I don't see it happening with linux anytime soon
<FireFly>
(well, ever)
<FireFly>
and anything else is going to have a hard time with hardware support at the very least
<leon-p>
nope, not really. One could argue that linux+systemd is kinda like a microkernel, however with a base kernel that has many redundant features. And if kernel-dbus ever becomes a thing, there'd even be a unified IPC layer
<FireFly>
mmm
<leon-p>
but I think it's best to not dwell on these things
<leon-p>
after all, all computers suck and the only good system is a sound system :]
<lordmzte>
the more you learn about how computers work, the less you want to have to do with them
<FireFly>
mood
<lordmzte>
I'm not sure who to blame for this, but some strange behavior I've experienced with waybar on river is that waybar, when stuff in it gets too long to fit, overflows onto the monitor on the right of it
<lordmzte>
The bar gets wider than the monitor and shows on the neighboring monitor
<ifreund>
lordmzte: we should crop it in river, feel free to open an issue and ill fix it beforw 0.3.0
<lordmzte>
will do
<ifreund>
waybar should also commit buffers of the right size of course, but we cant let broken clients get a way with things like that :D
<lordmzte>
honestly I think we should blame GTK (or gtk-layer-shell) here, which is always satisfying.