ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
bodiccea has joined #wayland
Seirdy has quit [Quit: exiting 3.2]
columbarius has joined #wayland
Seirdy has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
Doraemon has quit [Remote host closed the connection]
Fulljab has joined #wayland
Fulljab has quit []
Fulljab has joined #wayland
yoslin_ has quit []
columbarius has quit [Ping timeout: 480 seconds]
yoslin has joined #wayland
eruditehermit has quit [Ping timeout: 480 seconds]
MatrixTravelerbot[m] has joined #wayland
doras has joined #wayland
columbarius has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
psydroid has joined #wayland
unrelentingtech has joined #wayland
bdaase[m] has joined #wayland
___nick___ has joined #wayland
botiapa[m] has joined #wayland
Fulljab has quit []
Fulljab has joined #wayland
enick_930 has joined #wayland
FbioPacheco[m] has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
digitalshethey[m] has joined #wayland
Fulljab has quit []
Fulljab has joined #wayland
rails[m] has joined #wayland
Fulljab has quit []
Fulljab has joined #wayland
alexmitchellmus has quit [Read error: Connection reset by peer]
<DemiMarieObenour[m]>
Can anyone see this message?
<DemiMarieObenour[m]>
(from IRC, that is)
<SardemFF7>
DemiMarieObenour[m]: yes
<DemiMarieObenour[m]>
SardemFF7: Can you see the message containing “confusing message from NickServ.”?
<SardemFF7>
don’t think so
<DemiMarieObenour[m]>
When it comes to `wl_fixes`, I would like to start with the `wl_registry` destructor. Not because this is the most important fix to make, but because it is the simplest to implement, and can serve as a proof of concept.
<DemiMarieObenour[m]>
That would include changing `wl_registry_destroy` so that it actually sent an event if `wl_fixes` is present.
inkbottle[m] has joined #wayland
<SardemFF7>
how about a little less invasively magic: wl_fixes_release_registry(registry) ?
<DemiMarieObenour[m]>
That would be interesting. Could it be made to no-op on older servers?
<DemiMarieObenour[m]>
Looks like `wl_registry_destroy` is `static inline`, but thankfully old binaries that have inlined its definition will still work (they just won’t call the destructor).
<DemiMarieObenour[m]>
This also means that adding a destructor request after the fact is an ABI-breaking change.
<DemiMarieObenour[m]>
Could wayland-scanner be made to reject any interfaces that do not have exactly one destructor request, with a hard-coded list of exceptions?
<jadahl>
DemiMarieObenour[m]: it could be added as a test case to wayland-protocols' CI
<jadahl>
probably better than breaking downstream protocols which cannot reasonably be added to such a list
<DemiMarieObenour[m]>
What about making it a warning, and then having wayland-protocols build with warnings-as-errors?
<jadahl>
maybe an alternative
<jadahl>
problem is that sometimes its valid, or complicated
<DemiMarieObenour[m]>
That is true
<jadahl>
see for example the leasing protocol, it has quite an elaborate object lifetime management model
<SardemFF7>
we already had destructor added in a later version, as pq mentioned, with the _release name to specifically not break the _destroy function
fmuellner has quit []
<DemiMarieObenour[m]>
Ah, good point.
<DemiMarieObenour[m]>
Interfaces with a destructor event and any requests are known to be broken. Can `wayland-scanner` just reject them?
leon-p has quit [Quit: leon-p]
fmuellner has joined #wayland
<DemiMarieObenour[m]>
For the zombie object case, the best solution I can think of is to have a request on `wl_display` that puts the connection in a slightly different mode, where the server sends `delete_id` events whenever it destroys an object, and the client must respond with a `delete_id` request with the destroyed object ID *unless* it has already sent a destructor request.
sstiller has quit [Quit: Leaving]
<DemiMarieObenour[m]>
That would ensure that every object destruction goes through a round-trip.