ifreund changed the topic of #river to: river - a dynamic tiling wayland compositor - https://github.com/ifreund/river - channel logs: https://freenode.irclog.whitequark.org/river/
<edrex> ifreund, leon-p RE: full layout in rivertile: i just hopped on to say that since I found the full layout, I am no longer missing Sway's tabbed/stacked layouts lol
<edrex> the only thing it's missing is some visual indicator of the layout contents. I was thinking I might take a crack at implementing a layout HUD and figure out how to show it temporarily over everything with layer shell on focus change or similar. I have been following wayland/low level graphics stuff for awhile and haven't written anything, and I think that would be a good size to get my toes wet.
<edrex> Thinking just a visual representation of the view stack data structure: namespace, list of views, which are in main area
<edrex> anyway, it would be cool if full were still in default river. it's actually brilliant, fullscreen but with cycling
<edrex> first thing I did was turn off padding. precious pixels! :D
<edrex> +1px border
<edrex> so, is it correct that layouts can't hint the stacking order? the compositor manages order?
<leon-p> true
<leon-p> however an update for river-control is planned which may mke ti possible for clients to move arbitrary views around in the stack
<leon-p> by the way, regarding your earlier message about soe sort of layout indicator: Layouts can set a name, which could be displayed on soemthing like a status bar in the future.
<edrex> something like swaymsg -t get_tree is already available in one of the protocols? is river-control purely C->S and river-status purely S->C?
<leon-p> that is the way those protocols are currently set up.
<leon-p> May change in the future, depending on how other common protocols will hold up
<leon-p> to get a list of all views you have to use foreign-toplevel though, the river internal protos don't do that
<edrex> how about all views in the current stack?
<leon-p> however what will be in the next river-control has not been decided yet. All we know is that we want to allow atomic updates to arbitrary views
<leon-p> the "current stack" is always all views on an output. River just decides which to skip when rendering/using a layout/focusing based on tags.
<edrex> you mean atomic updates to view tags/order?
<edrex> yes, i read that bit of output code
<leon-p> yes. the idea is to basically queue up a bunch of command like "set tags to 001101", "move to other screen", "move down", "focus" and then finally send a "commit" which makes them all happen at once. That is more wayland idiomatic than non-atomic
<leon-p> for getting information about views, your best bet is currently foreign-toplevel, so I suggest you investigate that proto.
<edrex> what happens if the client sits there and doesn't commit?
<edrex> thanks, will do
<leon-p> nothing.
<leon-p> everything will work fine
<edrex> so it's not really a transaction, just a queue of commands. got it.
<leon-p> exactly. if a client does not commit, all we do is keep sitting on a stack of commands. Maybe we should have a timeout, but idk for sure
<leon-p> in other words, it should be impossible for any arbitrary client to hang river
<edrex> Should I write status thingy in Zig?
<edrex> I'm a high level language refugee. Last job Go, before that lots of Python, Ruby, PHP etc. i know C but have hardly written anything in it in the past 18+ years. Picking up Zig doesn't seem substantially harder than getting back into C headspace, and it sounds like the interop is ~100%
<edrex> Oh, and there was some Scala and Haskell mixed in there too lol
<leon-p> I went from C to Zig. Pretty great experience. Just the right amount of OO, small enough so that you can learn the basics on a weekend.
<leon-p> checkout ziglearn.org for that.
<leon-p> but beware that the river-status protocol may not survive for much longer
<leon-p> so first I recommend trying other protocols
<edrex> k, thanks for the heads up. I am getting a good feeling about river. It already feels more natural to me than sway, and it sounds like better scriptability is on the way. I have a lot of interesting use cases that may help exercise the protocols
<edrex> it's really good to see wlroots fulfilling its' aim
<leon-p> totally. without wlroots we'd all be using X WMs like barbarians :D
<edrex> just read https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-foreign-toplevel-management-unstable-v1.xml, interesting. Seems PID isn't exposed, too bad. I was hoping I could use it to make my little sway script to spawn a new command with the active window process PID work with other wlroots compositors.
waleee-cl has quit [Quit: Connection closed for inactivity]
travankor has joined #river
travankor has quit [Remote host closed the connection]
travankor has joined #river
trav45343 has joined #river
travankor has quit [Remote host closed the connection]
Bonicgamer[m] has quit [Quit: Idle for 30+ days]
trav45343 has quit [Remote host closed the connection]
travankor has joined #river
<ifreund> edrex: You could comment here with your use-case for exposing the pid if you want: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/59
<ifreund> that would be the best chance of getting it available in a compositor-agnostic protocol
<travankor> edrex: +1
<ifreund> leon-p: possibly out-there idea: What if we exposed a generic key-value store for options which allows users to set and retrive options over a wayland protocol
<ifreund> then main count/factor, padding, etc could all just be (standardized) options in this store and layouts generators could inspect them
<ifreund> this would also allow users to script custom interaction with protocols by setting an option
<ifreund> we would likely need a way for clients to "subscribe" to an option and automatically receive events whenever it is updated
<ifreund> one issue with this is that there are several cases in which we'd like options to be output/seat specific instead of global
<ifreund> we could solve that with a separate store for each output/seat, falling back to the global store
<ifreund> What I'm describing is actually very similar to what kakoune does, which is probably what inspiried this idea I guess: https://github.com/mawww/kakoune/blob/master/doc/pages/options.asciidoc
<ifreund> I've just about convinced myself this would be a good idea, would love to hear your thoughts though
travankor has quit [Ping timeout: 240 seconds]
<ifreund> this will be very nice to have for zig-wayland and river: https://github.com/ziglang/zig/issues/7769
dnkl has quit [Ping timeout: 240 seconds]
dnkl has joined #river
dnkl has quit [Remote host closed the connection]
dnkl has joined #river
dnkl has quit [Client Quit]
dnkl has joined #river
waleee-cl has joined #river
<leon-p> ifreund: Are the values whih can be stored in the key value store arbitrary? Can set values unrelated to river?
<leon-p> I like the idea in theory, we just have to ensure we send those events before any other events, such as a layout demand, to ensure they are being correctly used
<leon-p> I propose that to be a standalone protocol though and not part of river-control.
<leon-p> That is the kind of protocol that could theorectically even be standardized
<ifreund> Yeah definitely a new protocol, I was thinking to call it river-config
<ifreund> there would be a way for client to declare new options, so yes they could use it for things unrelated to river
<leon-p> Cool, so we would be the better dconf :D
<leon-p> But isn't that going to be expensive, considering values would have to be identified by a string of sorts?
<ifreund> Expensive as in memory usage? I don't think it would be too bad
<ifreund> and yeah the idea would be a map from a string to a tagged enum of wayland arg types
<ifreund> possibly excluding arrays and fds though
<leon-p> what types do we want to offer? int, fixed, string?
<ifreund> int, uint, fixed, and string at the minimum yeah
<ifreund> I don't have a use case for storing objects yet, but that would be possible
<leon-p> that would definitely solve the problem of sending arbitrary information to layouts
<leon-p> and we would remove the concept of the main views from river, making things a bit simpler
<leon-p> so that's a +1 from me.
<ifreund> If we allowed arrays we could use it for e.g. float-filter and csd-filter as well
<ifreund> not sure if that's worth the complexity though
<leon-p> We just need to be careful (and should probably write it into the proto) that the "value changed" events will always be received before any other events where the client may want thtat info
<ifreund> agreed
<ifreund> I'd also use this for the background/border color config
<ifreund> basically everything we can use it for
<leon-p> yes, every user configurable value
<ifreund> which would be great, because then river-control is really just about control not config
<leon-p> also: making every option querry-able, we make it possible for graphical configuration clients. Some users like those kind of things
<ifreund> indeed, more power to the users!
<ifreund> and probably simpler code for us as well
<ifreund> well, more generic code at least
<ifreund> we aren't dwm after all :D
<leon-p> and arbitrary river-related clients would no longer need to implement their own config system
<ifreund> exactly
<leon-p> this is pretty exciting
<leon-p> although I'd argue that maybe there is some value in trying to standardize such a thing. It's generic enough for that.
<ifreund> Indeed, I feel like we're making really good progress in the design space for river recently :)
<leon-p> the gnome guys will block it, but I can imagine the other involved parties being interested
<ifreund> I'd like to draft it up first and see what we get, but yeah I think this is something I'd propose to wayland-protocols
<leon-p> sounds good
<leon-p> Should my PR be finished before that proto and we make the changes afterwards, or should I put my work on hold until the new proto is implemented?
<ifreund> I'm not sure, I unfortunaetly have a lot going on IRL and also need to record my fosdem talk this week so I don't know when I'll be able to implement this or help you finsh up the layout PR
<ifreund> I might just have to implement it real fast so I can get it out of my head and focus on other things though
<ifreund> we'll see
<leon-p> yeah, I also won't have much time in the coming month.
<leon-p> anyway, we need a github issue to collect the ideas and potentially a draft
<leon-p> For the protocol we probably don't need more than 1) a way to set specific values and 2) a way to subscribe to specific values
<ifreund> if we want to allow arrays of strings we can't really use wayland's arrays for that
<ifreund> we could handle them specially in the protocol, but I'm thinking that's an unecessary complication at the current stage
<ifreund> I'll stick to int/uint/fixed/string values for the first draft
<leon-p> +1
<ifreund> > Reads are performed by direct access (via mmap) to the on-disk database which is essentially a hashtable. For this reason, dconf reads typically involve zero system calls...
<ifreund> mmap is a syscall...
<leon-p> maybe they exclude the initial mmap and mean to syscalls after that? it's a stretch, but dconf is frmo the same people who came up with GObject, so...
<ifreund> leon-p: well, got a fairly barebones draft of the protocol up. Probably could be made cleaner somehow
<edrex> ifreund: is foreign_toplevel_info meant to, together with some future control protocol, meant to replace -_management, or go alongside it?
<ifreund> edrex: with the other MR I have open for ext-foreign-toplevel-management it will replace the wlr protocol completely
<edrex> ifreund: oh, nice! So you can grant just read only. I recall sway had some fine grained security policy mechanism for protocol access. That's a wayland thing right?
<edrex> has anyone worked on some kind of general purpose client for poking at wayland protocols?
<ifreund> edrex: afaik no compositor has a real security policy for priviledged protocols implemented yet. You'll find discussion on the topic here: https://gitlab.freedesktop.org/wayland/weston/-/issues/206
<edrex> thinking of various grpc clients that you hand a .proto definition
<ifreund> I don't know of any kind of client like that, but it's pretty easy to hack together a simple client quickly
<ifreund> there's also all the wlroots and weston example clients
<edrex> thinking of something like swaymsg for ppl writing shell scripts
<edrex> wouldn't have to be able to handle novel protocols, just cover the ones that are useful for scripting
<edrex> anyway, just thinking out loud :)
<ifreund> that's pretty much what I want riverctl to be for river-specific stuff eventually, but we need to get the protocols worked out first
sfreimuth has joined #river
travankor has joined #river
<edrex> ifreund: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/59#note_765526 did. don't want it to be a distraction tho
travankor has quit [Remote host closed the connection]
<edrex> yeah, just the more shared protocols the better for portability of tools across the ecosystem, and it would be cool if more shell scripts could work across different compositors too. There're plenty of time for downstream tooling once protocols land tho :)
travankor has joined #river
<ifreund> leon-p: should we perhaps do namespacing under an arbitrary string rather than wl_output or wl_seat object? It would be a lot more flexible
<ifreund> could then use the seat name or xdg_output name for example, or anything else we might not have thought of yet
travankor has quit [Ping timeout: 240 seconds]
<leon-p> hmm... not sure tbh. Spontaniously I'd say it needs to be output and seat bound. But it could still be a global list, where each entry simply has a wl_object and a wl_seat pointer, which could be NULL.
<leon-p> I'd generally prefer to have as little string operations as possible. If we use the xdg-output name as a string, clients would need to allocate a buffer with it
<leon-p> so my idea is to have a `struct { key: []const u8, seat: ?*wl.Seat, output: ?*wl.Output, value: union { ... }, };`
<leon-p> that would be the most flexible IMO, as it allows clients to have a key-value-pair be bound to either/or/and/none of the output and seat.
<leon-p> As an example, the main factor would have an output pointer, but seat == null.
<leon-p> While the keymap would have a seat pointer, with output == null
<leon-p> (I wonder if we can get other wayland clients to support this protocol. It would enable neat things such as a global theme switcher that does not rely on ugly hacks such as rewriting the config and restarting the program.)
<leon-p> (oh, and by the way thanks for indirectly recommending to try out kakoune. Neat editor. Not sure I agree with all of its design decissions, but I'll try it for a bit)