01:37 <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

01:42 <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.

01:42 <edrex> Thinking just a visual representation of the view stack data structure: namespace, list of views, which are in main area

01:43 <edrex> anyway, it would be cool if full were still in default river. it's actually brilliant, fullscreen but with cycling

01:44 <edrex> first thing I did was turn off padding. precious pixels! :D

01:44 <edrex> +1px border

01:46 <edrex> so, is it correct that layouts can't hint the stacking order? the compositor manages order?

01:46 <leon-p> true

01:47 <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

01:48 <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.

01:48 <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?

01:49 <leon-p> that is the way those protocols are currently set up.

01:49 <leon-p> May change in the future, depending on how other common protocols will hold up

01:50 <leon-p> to get a list of all views you have to use foreign-toplevel though, the river internal protos don't do that

01:52 <edrex> how about all views in the current stack?

01:52 <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

01:53 <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.

01:53 <edrex> you mean atomic updates to view tags/order?

01:53 <edrex> yes, i read that bit of output code

01:54 <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

01:55 <leon-p> for getting information about views, your best bet is currently foreign-toplevel, so I suggest you investigate that proto.

01:55 <edrex> what happens if the client sits there and doesn't commit?

01:55 <edrex> thanks, will do

01:55 <leon-p> nothing.

01:55 <leon-p> everything will work fine

01:55 <edrex> so it's not really a transaction, just a queue of commands. got it.

01:56 <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

01:56 <leon-p> in other words, it should be impossible for any arbitrary client to hang river

01:58 <edrex> Should I write status thingy in Zig?

01:58 <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%

02:00 <edrex> Oh, and there was some Scala and Haskell mixed in there too lol

02:01 <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.

02:01 <leon-p> checkout ziglearn.org for that.

02:01 <leon-p> but beware that the river-status protocol may not survive for much longer

02:01 <leon-p> so first I recommend trying other protocols

02:03 <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

02:04 <edrex> it's really good to see wlroots fulfilling its' aim

02:06 <leon-p> totally. without wlroots we'd all be using X WMs like barbarians :D

04:57 <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.

04:57 <edrex> https://github.com/edrex/dotfiles/blob/master/bin/exec-with-pwd

09:45 <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

09:46 <ifreund> that would be the best chance of getting it available in a compositor-agnostic protocol

09:57 <travankor> edrex: +1

11:24 <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

11:25 <ifreund> then main count/factor, padding, etc could all just be (standardized) options in this store and layouts generators could inspect them

11:26 <ifreund> this would also allow users to script custom interaction with protocols by setting an option

11:27 <ifreund> we would likely need a way for clients to "subscribe" to an option and automatically receive events whenever it is updated

11:29 <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

11:53 <ifreund> we could solve that with a separate store for each output/seat, falling back to the global store

11:55 <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

11:55 <ifreund> I've just about convinced myself this would be a good idea, would love to hear your thoughts though

13:02 <ifreund> this will be very nice to have for zig-wayland and river: https://github.com/ziglang/zig/issues/7769

14:51 <leon-p> ifreund: Are the values whih can be stored in the key value store arbitrary? Can set values unrelated to river?

14:52 <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

14:52 <leon-p> I propose that to be a standalone protocol though and not part of river-control.

14:53 <leon-p> That is the kind of protocol that could theorectically even be standardized

14:54 <ifreund> Yeah definitely a new protocol, I was thinking to call it river-config

14:55 <ifreund> there would be a way for client to declare new options, so yes they could use it for things unrelated to river

14:55 <leon-p> Cool, so we would be the better dconf :D

14:56 <leon-p> But isn't that going to be expensive, considering values would have to be identified by a string of sorts?

14:56 <ifreund> Expensive as in memory usage? I don't think it would be too bad

14:57 <ifreund> and yeah the idea would be a map from a string to a tagged enum of wayland arg types

14:58 <ifreund> possibly excluding arrays and fds though

14:58 <leon-p> what types do we want to offer? int, fixed, string?

14:59 <ifreund> int, uint, fixed, and string at the minimum yeah

14:59 <ifreund> I don't have a use case for storing objects yet, but that would be possible

15:00 <leon-p> that would definitely solve the problem of sending arbitrary information to layouts

15:01 <leon-p> and we would remove the concept of the main views from river, making things a bit simpler

15:01 <leon-p> so that's a +1 from me.

15:02 <ifreund> If we allowed arrays we could use it for e.g. float-filter and csd-filter as well

15:02 <ifreund> not sure if that's worth the complexity though

15:02 <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

15:02 <ifreund> agreed

15:03 <ifreund> I'd also use this for the background/border color config

15:03 <ifreund> basically everything we can use it for

15:03 <leon-p> yes, every user configurable value

15:03 <ifreund> which would be great, because then river-control is really just about control not config

15:04 <leon-p> also: making every option querry-able, we make it possible for graphical configuration clients. Some users like those kind of things

15:04 <ifreund> indeed, more power to the users!

15:04 <ifreund> and probably simpler code for us as well

15:05 <ifreund> well, more generic code at least

15:05 <ifreund> we aren't dwm after all :D

15:05 <leon-p> and arbitrary river-related clients would no longer need to implement their own config system

15:05 <ifreund> exactly

15:05 <leon-p> this is pretty exciting

15:06 <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.

15:06 <ifreund> Indeed, I feel like we're making really good progress in the design space for river recently :)

15:06 <leon-p> the gnome guys will block it, but I can imagine the other involved parties being interested

15:07 <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

15:07 <leon-p> sounds good

15:08 <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?

15:09 <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

15:10 <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

15:10 <ifreund> we'll see

15:11 <leon-p> yeah, I also won't have much time in the coming month.

15:15 <leon-p> anyway, we need a github issue to collect the ideas and potentially a draft

15:17 <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

15:21 <ifreund> if we want to allow arrays of strings we can't really use wayland's arrays for that

15:22 <ifreund> we could handle them specially in the protocol, but I'm thinking that's an unecessary complication at the current stage

15:22 <ifreund> I'll stick to int/uint/fixed/string values for the first draft

15:32 <leon-p> +1

15:38 <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...

15:38 <ifreund> mmap is a syscall...

15:50 <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...

17:13 <ifreund> leon-p: well, got a fairly barebones draft of the protocol up. Probably could be made cleaner somehow

19:58 <edrex> ifreund: is foreign_toplevel_info meant to, together with some future control protocol, meant to replace -_management, or go alongside it?

20:01 <ifreund> edrex: with the other MR I have open for ext-foreign-toplevel-management it will replace the wlr protocol completely

20:11 <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?

20:12 <edrex> has anyone worked on some kind of general purpose client for poking at wayland protocols?

20:14 <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

20:14 <edrex> thinking of various grpc clients that you hand a .proto definition

20:15 <ifreund> I don't know of any kind of client like that, but it's pretty easy to hack together a simple client quickly

20:15 <ifreund> there's also all the wlroots and weston example clients

20:16 <ifreund> e.g. https://github.com/swaywm/wlroots/blob/master/examples/foreign-toplevel.c

20:17 <edrex> thinking of something like swaymsg for ppl writing shell scripts

20:18 <edrex> wouldn't have to be able to handle novel protocols, just cover the ones that are useful for scripting

20:18 <edrex> anyway, just thinking out loud :)

20:20 <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

21:14 <edrex> ifreund: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/59#note_765526 did. don't want it to be a distraction tho

21:19 <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 :)

22:38 <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

22:39 <ifreund> could then use the seat name or xdg_output name for example, or anything else we might not have thought of yet

23:33 <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.

23:34 <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

23:36 <leon-p> so my idea is to have a `struct { key: []const u8, seat: ?*wl.Seat, output: ?*wl.Output, value: union { ... }, };`

23:37 <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.

23:39 <leon-p> As an example, the main factor would have an output pointer, but seat == null.

23:39 <leon-p> While the keymap would have a seat pointer, with output == null

23:42 <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.)

23:48 <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)