ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<wlb>
weston Issue #876 opened by Paul Pu (puhui) weston crashes in weston_desktop_xdg_toplevel_protocol_set_fullscreen() of xdg-shell.c if disconnect the screen just when calling set fullscreen https://gitlab.freedesktop.org/wayland/weston/-/issues/876
<pq>
drakulix[m], leaving emoticon reactions in Gitlab does not result in email notifications, and I definitely do not take them as reviews. Leave a proper comment if you want to accept/reject something, please. :-)
glennk has quit [Remote host closed the connection]
<pq>
or is there now an option to get email notifications of emoji as well?
<pq>
The problem with reviewing with emoji is that they can be withdrawn as well, and they do not insert into the stream to denote which revision was agreed to.
<emersion>
GitLab doesn't support RFC 9078 yet?
<emersion>
smh
<pq>
I also would never know if a :thumbup: is "LGTM" or "Sounds like a good idea if someone reviewed this" or "me too".
<emersion>
people should use π¦ instead, which is much more explicit
<pq>
a square?
<emersion>
no, a seal of approval
<pq>
it's a square here.
<bittin>
a seal here
<pq>
this is also IRC :-P
<emersion>
IRC or not shouldn't matter
<bittin>
guess its more about installed fonts and terminal
<bittin>
and irc client
<pq>
Gitlab has the approve button already.
<pq>
Just say what you mean, and don't leave people guessing.
<emersion>
booooriiiing
<pq>
Boring is good, and I'm not joking.
<pq>
There is nothing funny for me here.
<emersion>
i non-ironically agree
<pq>
Personally I find "summary reactions" utterly useless. I use them when I feel like I should participate, but I also know it would be much better for everyone if I didn't. They give me the feeling of having reacted while being almost sure that no-one will see it.
<emersion>
i only use them when it doesn't matter whether the other person sees it or not
<pq>
yup
<emersion>
they're more of a social media app feature than a useful forge feature
<pq>
very
<pq>
The definition of "summary reaction" is a knee-jerk, right? When was leaving knee-jerk reactions a good idea.
<pq>
:oldmanyeallsatcloud:
<davidre>
When creating a protocl in wayland-protocols should the protocol folder and file name include a prefix?
Leopold_ has joined #wayland
<emersion>
if wp: no, rest: yes
<davidre>
For example we have stable/xdg-shell/xdg-shell.xml but also stable/viewporter/viewporter.xml
<pq>
wayland-protocols README.md still talks about Makefile.am, and I don't think we ever had extension directory and file naming defined.
<pq>
the prefix, specifically
<davidre>
but at least <protocol name=" should include a prefix I guess
<pq>
I don't know. Would be good to define all that.
<pq>
I'm not even sure if anything uses that.
<davidre>
If it has <protocol name="mycoolprotocol"> which inclusion criteria apply?
<pq>
that's based on the interface names
<emersion>
i think governance says that the prefix is optional for wp_ but not rest
<davidre>
pq MAkes sense, until someone defines interfaces with two different prefixes in one protocl :D
<pq>
yeah, I'd hope review catches that
Leopold_ has quit [Remote host closed the connection]
JoanTorres[m] has joined #wayland
Leopold has joined #wayland
<pq>
I don't actually know what GOVERNANCE 2.1.2 is talking about. Directory names? XML file names? <protocol> name attribute?
<pq>
and it says prefix is optional. Nothing about which namespaces.
<emersion>
"Namespaces are implemented in practice by prefixing each interface name in a protocol definition (XML) with the namespace name, and an underscore (e.g. "xdg_wm_base")."
<emersion>
"Protocols in a namespace may optionally use the namespace followed by a dash in the name (e.g. "xdg-shell")."
<pq>
yeah, interface names. No mention of directory, file or <protocol> names.
* emersion
shrugs
<emersion>
to me the second line is about the protocol name
<emersion>
not interfaces
<pq>
This could use improving.
<pq>
yes
<pq>
2.1.1 is about interface names only. 2.1.2 is not about interface names but I don't know which names it is.
<emersion>
Protocols [...] may optionally use [...] in the name
<pq>
which name?
<pq>
directory, file, and/or <protocol> name?
<emersion>
it reads pretty naturally to me
<davidre>
Just make it all match
<davidre>
Less confusion
Leopold has quit [Remote host closed the connection]
<pq>
file name is required to have the major version suffix, while directory name does not, and <protocol> name I don't know.
Leopold has joined #wayland
<emersion>
a single directory must be able to contain multiple major versions
<pq>
yes
<pq>
so that means directory name cannot be the same as the base name of the XML file.
<emersion>
file name is kebab-case, while protocol name is snake_case
<emersion>
apart from this they should match, i think
<pq>
what about the major version suffix?
<emersion>
what about it?
<pq>
should be there or not?
<emersion>
yes
<pq>
I don't think that's doc'd anywhere.
<pq>
I'd be happy to mandate namespace prefix in *all* names, going forward.
<emersion>
that'd be fine by me
<pq>
having been free game, I doubt we can find consistency in existing names, expecially the oldest ones
<pq>
but if there is recentish consistency, I'd be delighted
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
joantolo has joined #wayland
joantolo has quit []
Leopold_ has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
JoanTorres[m] is now known as JoanTorres[m]1
junaid has joined #wayland
JoanTorres[m]1 has left #wayland [#wayland]
Brainium has joined #wayland
<pq>
Is it clear to clients that an event group ending at wl_output.done does not necessarily send events for things that did not change since the last 'done'?
kts has joined #wayland
CME_ has joined #wayland
CME has quit []
<vyivel>
pretty clear to me from the event description
<pq>
cool
joantolo[m] has joined #wayland
fmuellner has joined #wayland
zxrom has joined #wayland
<pq>
swick[m], there are a few MRs open against the color-management protocol, and the xx_color branch is already behind. It's a bit annoying to target an implementation to a version that's known outdated. Would you make a new version of xx_color as-is, or get the pending changes in soon, or?
junaid has quit [Remote host closed the connection]
<pq>
particularly as the implementation is already written for some of those changes, so we would actually have to go backwards to match the current xx_color version.
leon-anavi has joined #wayland
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<drakulix[m]>
<pq> "drakulix, leaving emoticon..." <- Honestly I think I meant to comment, got distracted and just forgot it. Definitely agree.
<pq>
drakulix[m], alright, thanks :-)
nerdopolis has joined #wayland
tzimmermann has quit [Quit: Leaving]
<swick[m]>
pq: I'll take a look at the MRs today and ask everyone with an implementation if updating the xx branch is fine
<pq>
how would updating the xx branch not be fine? I assumed it will be a cheap snapshot of the color branch that you could do even every week if there are changes.
<pq>
implementors then choose which version they pick from the xx branch as they are clearly numbered
kts has quit [Ping timeout: 480 seconds]
<swick[m]>
I have not looked at the changes yet but if they break compat then I want an ack from everyone that they can adjust their implementations soon
<swick[m]>
trying to have compatible compositors and clients is the point of the exercise, isn't it?
<pq>
not with time limitations, no
<pq>
IMO the point is to have clearly versioned snapshots that can be discovered at runtime
<pq>
everyone will naturally want to support the latest, but everyone also has their own schedules
<swick[m]>
mh, right, so just release xx_color_management_v2 and a new version whenever someone wants it
<pq>
yeah, that's what I thought
<zamundaaa[m]>
yeah
<swick[m]>
that would be fine with me
<zamundaaa[m]>
FWIW I can update my implementation easily, the v1 one isn't in any release yet
kts has joined #wayland
<swick[m]>
okay, let's do that then
<pq>
why would being in a release matter at all?
kts has quit [Remote host closed the connection]
<zamundaaa[m]>
I mean updating it for Plasma 6.0, so that clients can work with the newer thing
<zamundaaa[m]>
For git master it doesn't matter ofc
<pq>
the point of the xx rename was to not guarantee any specific version compatibility
kts has joined #wayland
<pq>
releases should be completely irrelevant
<pq>
because we do not want anyone to start actually relying on any xx version, and if you start thinking about releases, I think it gives a wrong message
kts has quit [Remote host closed the connection]
<zamundaaa[m]>
They are relevant in the sense that for me the biggest reason for the experimental tags is so that I can release a compositor that supports the protocol, for client developers to write an implementation against, with easy porting to the final thing
kts has joined #wayland
<zamundaaa[m]>
Otherwise client developers would have to compile some compositor branch, which isn't always trivial. At least in the case of KWin there's a whole bunch of dependencies behind it that may need compiling too.
<wlb>
weston Issue #876 closed \o/ (weston crashes in weston_desktop_xdg_toplevel_protocol_set_fullscreen() of xdg-shell.c if disconnect the screen just when calling set fullscreen https://gitlab.freedesktop.org/wayland/weston/-/issues/876)
<pq>
you can release, but you should not pay *any* mind to what you release - someone always need to build from a branch or snapshot, either a compositor or a client.
<pq>
otherwise we cannot make progress
<zamundaaa[m]>
What I meant is that it's good to have the more up to date protocol in the release / make a new snapshot now, rather than in a few weeks
<pq>
oh, yes
<zamundaaa[m]>
It's still all guarded behind an env var and disabled by default, so noone's actually gonna rely on it
<daniels>
pq: if I could ππΌπ€ your βI use summary reactions to leave an indicator that I have weak opinions that arenβt worth sending notificationsβ message on IRC, I would :)
Leopold_ has joined #wayland
<pq>
daniels, triple square?
kts has quit [Quit: Leaving]
mvlad has quit [Read error: Connection reset by peer]
<daniels>
thumbs up with medium-light skin tone, handshake
<daniels>
I guess youβd have to have a client supporting Unicode before you got reactions though :P
mvlad has joined #wayland
<pq>
I do Unicode, just not all of it, and definitely not anything coloured.
<emersion>
the proper description is: THUMBS UP SIGN, EMOJI MODIFIER FITZPATRICK TYPE-3, HANDSHAKE
Leopold_ has quit [Remote host closed the connection]
<pq>
even if the font had the glyphs, they would be too small for me to see, because my font size is good for reading regular text.
<kennylevinsen>
I find google's noto fonts to be a good way to have fallbacks for every codepoint
tzimmermann has joined #wayland
<kennylevinsen>
the glyphs are indeed small though, at the current font size and distance the handshakey thing looks more like a... yellow heart?
<kennylevinsen>
but better than a tofu or blank squares
<kennylevinsen>
pq: well, actually, the current shape of the latin alphabet is a very recent thing...
<kennylevinsen>
even lower-case letters is a pretty new thing, especially rules about their use
<kennylevinsen>
everything is a muddy mess
<pq>
in the history of electronic computing?
<kennylevinsen>
nah, computers are just a short-term fad in the scope of languages, but as they're here for longer they'll have to deal with how languages and writing systems are mutable and gross
<davidre>
These kids and there new-fangled U, all we had back in the day was V!