ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
aelius has quit [Ping timeout: 480 seconds]
DavidEdmundson[m] has joined #wayland
narodnik has quit [Ping timeout: 480 seconds]
emilio[m] has joined #wayland
aelius has joined #wayland
davidre has joined #wayland
zzxyb[m] has joined #wayland
BrianYurko[m] has joined #wayland
sally has quit []
glennk has quit [Ping timeout: 480 seconds]
narodnik has joined #wayland
Drakulix has quit [Ping timeout: 480 seconds]
robertmader[m] has joined #wayland
Drakulix has joined #wayland
karenw has joined #wayland
karmavil[m] has joined #wayland
zebrag[m] has joined #wayland
Orko[m] has joined #wayland
karenw has quit [Quit: Deep into that darkness peering...]
Brainium has quit []
Eighth_Doctor has joined #wayland
exkc has joined #wayland
Lyude has quit [Ping timeout: 480 seconds]
outfoxxed has joined #wayland
Lyude has joined #wayland
orowith2os[m] has joined #wayland
swick[m] has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
zamundaaa[m] has joined #wayland
fmuellner has joined #wayland
dcz_ has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
AJC_Z0 has joined #wayland
AJ_Z0 has quit [Read error: Connection reset by peer]
OtzmaYehudit has quit [Remote host closed the connection]
OtzmaYehudit has joined #wayland
<wlb>
weston Issue #1041 opened by Nickiven1 (Nickiven1) Virtual keyboard different behavior between weston10 and weston12, keyboard will be deactivated after a while even typing. https://gitlab.freedesktop.org/wayland/weston/-/issues/1041
<DavidEdmundson[m]>
it's a bit weird in usage - the client makes an xdg-popup with a null argument where the parent should be
<DavidEdmundson[m]>
then attaches it on another surface
<DavidEdmundson[m]>
having the input method panel inherit from xdg-surface is also a valid path
<emersion>
i wonder if it would make sense to have an XML attribute to inherit a version of a new object from an arg instead of parent
<emersion>
hm, could be quite weird
<emersion>
(would be possible to mess things up and mix protocols)
<jadahl>
would the point be to distinguish between what version a xdg-popup has depending on if its mapped on top of an input panel or regular toplevel?
<emersion>
the point would be able to create new xdg_popups from other protocols
<emersion>
(same with other objects, e.g. image_description)
mahkoh has joined #wayland
<mahkoh>
That's not possible because other parsers exist and they ignore unknown attributes.
<mahkoh>
However, what you can do is use the following signature <arg name="x" type="new_id">.
<mahkoh>
That removes some amount of type safety, but it allows you to specify the version in the requets.
<mahkoh>
And then just specify in the request description that the type of the object is XYZ.
<mahkoh>
I'm using this in one of my protocols to define an extension mechanism where the extensions can be versioned independetnly.
<mahkoh>
(Without the "type of the object is XYZ" restriction.)
<emersion>
it's fine if they ignore unknown attributes, it's up to the protocol consumers to ensure their generator supports the features they need
<emersion>
yeah, name without interface is possible, but not super nice
paulk-bis has quit []
paulk has joined #wayland
<mahkoh>
I think a good solution would be to add a new attribute like this: <arg name="x" type="new_id" advisory_interface="xdg_surface">. Generators that are aware of this interface can then generate type safe code while older generators will still generate code that serializes and deserializes correctly.
<mahkoh>
Any mismatch between what the application expects and what the generator produces would be detected at compile time via a compilation error.
<mahkoh>
*aware of this attribute
Sid127 has joined #wayland
__0x1eaf has joined #wayland
<dcz_>
"having the input method panel inherit from xdg-surface is also a valid path" what's the advantage of that?
mahkoh has quit [Ping timeout: 480 seconds]
<dcz_>
hm, I guess it would be sharing ack_configure and configure and geometry for free
* dcz_
wonders if it's worth the effort and why layer_shell didn't do that
<DavidEdmundson[m]>
At the time layer shell landed xdg shell wasn't finalised, I suspect that was the main reason
<DavidEdmundson[m]>
It was round about when we were messing about going from v5 to v6 and dealing with the headache there
<dcz_>
and someone else chimed in, so I guess I should do it. I just wish this had been expressed before I implemented the current version
rgallaispou1 has quit [Read error: Connection reset by peer]
mohit81582263530690 has quit [Remote host closed the connection]
mohit81582263530690 has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
paulk-bis has quit []
paulk has joined #wayland
rgallaispou2 has quit [Read error: Connection reset by peer]
kts has joined #wayland
tombh has joined #wayland
___nick___ has joined #wayland
<tombh>
Hello, I'd like to explore a Wayland-like protocol and organisation for terminals, something that inspires moving on from ANSI and terminfo. Does anybody have any advice? Ideally I'd be interested in talking to somebody that has experience with the social aspects of introducing ecosystem changes like this. Thank you, Tom.
iomari891 has joined #wayland
julian1 has quit [Quit: WeeChat 4.6.3]
iomari891 has quit [Ping timeout: 480 seconds]
yshui_ has joined #wayland
yshui_ has quit [Remote host closed the connection]
yshui_ has joined #wayland
yshui_ has quit [Remote host closed the connection]