01:48 wlb: wayland Issue #346 opened by M. Stoeckl (mstoeckl) tests/fixed-benchmark.c is misleading / hides some of the cost of wl_fixed_to_double https://gitlab.freedesktop.org/wayland/wayland/-/issues/346
03:06 smallville7123: wayland works in android, right?
03:06 smallville7123: cus im just assuming wayland will work for both linux and android
03:07 i509vcb: it can work, given Android runs a modified Linux userspace
03:07 smallville7123: can it work on Android OS itself
03:07 i509vcb: Although integrating fully into the Android userspace is a different question
03:07 smallville7123: eg as a custom app
03:08 smallville7123: and not like, replacing the systemui/surfaceflinger
03:10 smallville7123: eg, wayland_test.apk { contains libwayland.so, wayland_client, wayland_server.so (executes and renders inside GLSurfaceView) }
03:10 smallville7123: im just assuming the above would work
03:10 i509vcb: yes you could implement a compositor which presents to the system ui
03:10 smallville7123: nice
03:10 i509vcb: someone actually experimented with that and got smithay's test compositor, Anvil to work
03:11 smallville7123: :)
03:12 smallville7123: is signal.h used by libwayland itself or is it only used in tests/ ?
03:13 smallville7123: as posix signals doesn't exactly have a step-by-step guide on how to implement its api
04:15 smallville7123: might abandon wayland for windows as it seems like, in windows, a nested window can be created using WS_CHILD when creating the window
04:21 smallville7123: [13:10] <i509vcb> someone actually experimented with that and got smithay's test compositor, Anvil to work
04:21 smallville7123: is the source available anywhere?
04:22 i509vcb: yes
04:22 i509vcb: https://github.com/Smithay/smithay/pull/711
04:23 i509vcb: do beware it is probably not fully baked
04:24 smallville7123: wait no... "WS_CHILD" might not apply to an actual seperated process
04:25 smallville7123: eg proc 1 might not be able to use WS_CHILD to reparent itself to window of proc 0
04:26 smallville7123: hmm https://devblogs.microsoft.com/oldnewthing/20130412-00/?p=4683
04:46 smallville7123: so, for windows, it seems like i can just use windows native window manager to implement a cross-process window-manager
04:46 smallville7123: and for linux and android, i will need to use wayland
09:34 smallville7123: welp, sadly it is in rust
09:35 smallville7123: and python doesnt seem to have any stable cross-platform support
09:35 smallville7123: and python doesnt seem to have any stable cross-platform GUI support *
17:25 Soni: can we have DOM?
17:26 Soni: just, bake DOM right into the protocol?
17:26 Soni: (well, DOM and styling really)
17:27 Soni: it'd be kinda awesome for screen reader support, both for daily use and screenshots (as in, screenshots that come with built-in screen reader support without the strict need for alt text)
17:31 ManMower: no
17:34 Soni: why not?
17:35 daniels: because at the point where the protocol contains 'the DOM', it contains the complete capability set of every client toolkit
17:35 i509vcb: There are some complicated questions around how it would be implemented or adopted.
17:35 i509vcb: How do you transport the DOM, it's too much data for the wire so you'd need a side channel
17:35 i509vcb: Servers would effectively need to implement a web view to actually work with the protocol
17:36 i509vcb: And on Linux your only reasonable choices would be WPEWebKit or fork Chromium
17:36 i509vcb: And then security implications could exist around pulling in an entire web browser framework
17:37 daniels: (as well as keeping up with that particular treadmill)
17:37 Soni: if every client's purpose is to render the fucking DOM then why do we need *Every Client* to have ITS OWN DOM RENDERER
17:37 Soni: sooo much RAM WASTED on DOM RENDERERS
17:37 daniels: because terminals and other native clients and games also exist?
17:38 Soni: i509vcb: it's not too much data for the wire, we've been doing it for decades. it's usually called HTML.
17:38 daniels: ChromiumOS does exist if you want a platform that is designed around displaying web content and nothing else
17:38 i509vcb: Wayland as a protocol kind of struggles when you give it huge strings over the wire
17:38 Soni: i509vcb: okay, so don't
17:38 daniels: (because it's not designed to transport massive strings, it's designed to display pixel content given to it by clients)
17:38 ManMower: if your goal is to save that ram, I guess the move would be to write a single DOM RENDERER that's better than all the others in all ways for every use case and make everyone use it. this isn't really a wayland problem though. :)
17:39 Soni: expose the DOM API, but no way to load a DOM
17:39 daniels: Soni: you're describing a web browser
17:39 Soni: daniels: no, there's no JS involved for it to be a browser
17:39 Soni: no JS, no navigation, no any of that stuff
17:39 Soni: just DOM and styling
17:39 daniels: you're describing a very large subset of a web browser
17:40 i509vcb: Even the most embeddable option I can think of, Servo is probably not good enough for production use
17:40 Soni: daniels: so yeet it out of the browser so we can have browsers that aren't a whole OS
17:40 daniels: either way, that's not what Wayland is - Wayland is designed to display graphical content given to it by clients, and give input events back to those clients. it's not a toolkit, it's not a web browser, etc. you can go design one of those systems, but that system isn't Wayland.
17:40 Soni: daniels: yes, so is the DOM
17:40 Soni: see, the DOM (with styles) is semantic graphical content
17:40 Soni: and it has events
17:41 daniels: you're making a semantic argument with no relevance to the discussion
17:41 Soni: so the client gives the DOM to the display server to render, and the display server gives the client DOM events
17:41 daniels: I understand the concept you're describing. I'm telling you that this concept is not Wayland. if you want to go make a project around that concept, then please do start one.
17:42 Soni: it should be in wayland so it can benefit from composition
17:42 daniels: that's your opinion, and not one shared by anyone else here
17:43 Soni: also, DOM has canvas, shove your OpenGL in there
17:43 daniels: Wayland also doesn't transport OpenGL
17:43 Soni: DOM is like the perfect display server protocol
17:43 Soni: except it isn't a protocol
17:43 daniels: sure, but it's not our display server protocol
17:43 daniels: and it won't be our display server protocol
17:43 daniels: please create a repository somewhere and start hacking on it
17:43 daniels: but Wayland is not going to be the (radically conceptually different) thing you're describing
17:46 Soni: every vendor is trying to kill the browser, meanwhile google is trying to be the browser
17:46 Soni: if freedesktop had parts of a browser, it would change that
17:46 daniels: that isn't going to happen
17:47 daniels: but there are projects like Firefox and NetSurf and others that you could contribute to
17:48 Soni: that's the thing they're too big
17:48 Soni: breaking them apart enables more ppl to contribute
17:48 Soni: also it'd be nice to see cluster computing on the desktop
17:49 Soni: like let's say you wanna run discord. well, you have a cluster for a desktop, so you just run the discord process in one node, and the DOM in another.
17:50 Soni: they have their own RAM, their own CPU, and the discord isn't gonna lag the rest of your system
17:50 emersion: sorry, but this is off-topic
17:50 Soni: which is another reason wayland (or X11) should have DOM in the protocol
17:50 daniels: extremely
17:50 emersion: please find another channel to dicsuss this
17:50 daniels: ^
17:50 daniels: probably something related to Plan9, since that sounds the most similar to the system you're describing
17:51 Soni: freedesktop more like lagmachines
17:51 Soni: eh, enjoy your lag
18:55 wlb: wayland-protocols Issue #127 opened by i509VCB (i509VCB) xdg-toplevel states should define a starting value for externally defined states https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/127
19:56 daniels: mvlad: thanks for revving the XCB bits!
22:24 kennylevinsen:squints at the idea of stuffing a browser DOM and style engine into wayland
22:28 bl4ckb0ne: the horror
22:32 bl4ckb0ne: it is certainly an idea but i doubt its a good one
22:37 zamundaaa[m]: It's certainly one of the ideas of all time