ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
qaqland has quit [Remote host closed the connection]
qaqland has joined #wayland
<mizvekov>
So if wl_shell is deprecated, and xdg_shell supersedes it, and we even mention this in the description of wl_shell, then why not simply ship it in libwayland?
<danieldg>
because you need to ship the rest of wayland-protocols anyway
<danieldg>
I'd say it makes more sense to go the other way: wayland.xml should not be part of libwayland, or maybe it should only contain wl_display (+callback)
<danieldg>
but it's not useful to change that now
<mizvekov>
wayland-protocols just includes the xmls but does build any libraries, so it's slightly more inconvenient to use.
<soreau>
not really
<danieldg>
if you have a working build system it's not, if you don't you need one anyway
<danieldg>
because you will eventually want to use viewporter, dmabuf, presentation feedback, and others
<mizvekov>
well you have to generate the c source from it, and plop it in your build system, instead of just linking to a library. distro folks tend to frown upon this, but I don't mind it too much myself.
<danieldg>
a good buildsystem is capable of handling xml -> .c -> .o
<danieldg>
that's like the original goal of Make, though it was .y -> .c
<soreau>
mizvekov: if you want a wrapper library for most protocols that matter, wlroots does a pretty decent job of this
<soreau>
then you don't have to worry about how wayland-scanner works :P
<mizvekov>
sure. but I don't mind using the scanner myself, I would do this for the whole libwayland. But it is slightly more inconvenient when you are just experimenting with things and want python-like convenience.
<mizvekov>
fwiw, vulkan is in the same boat, and they just ship everything pre-generated from their xmls, which I think is a good model.
<danieldg>
it's only a model needed because C doesn't have a buildsystem
<danieldg>
I think some distros frown on shipping generated source artifacts too
<mizvekov>
Well they tend to prefer shipping things in shared libraries, to both get overall image size down, and to make things more consistent and easier to update.
<mizvekov>
So what I meant is, they wouldn't ship the pregenerated C source, but just the shared library build from it, and everyone would just link to it.
<danieldg>
but that doesn't apply
<danieldg>
the actual wayland protocol is just as much the header
<danieldg>
there's little point in making a shared library from the protocols alone
<danieldg>
though I guess you could
mxz_ has joined #wayland
mxz has quit [Ping timeout: 480 seconds]
mxz_ is now known as mxz
Leopold_ has quit [Remote host closed the connection]
qaqland has quit [Remote host closed the connection]
zestyluna has quit [Remote host closed the connection]
privacy has joined #wayland
bittin has joined #wayland
glennk has joined #wayland
sima has joined #wayland
rasterman has joined #wayland
Company has joined #wayland
<kennylevinsen>
mizvekov: libwayland is a C implementation of the wire protocol, while wayland-protocols are the language and scanner agnostic protocol definitions. There are other non-C wire protocol implementations and scanners, so shipping pre-built for one of them would be slightly weird.
<kennylevinsen>
The mistake was how big the core protocol became. It should just have been e.g. display and registry tbh.
qaqland has quit [Remote host closed the connection]
qaqland has joined #wayland
kts has joined #wayland
kts has quit [Remote host closed the connection]
mvlad has joined #wayland
garnacho has joined #wayland
silverpower has quit [Ping timeout: 480 seconds]
kts has joined #wayland
silverpower has joined #wayland
<JoshuaAshton>
kennylevinsen: I agree with that
qaqland has quit [Remote host closed the connection]
qaqland has joined #wayland
kts has quit [Quit: Leaving]
leon-anavi has joined #wayland
privacy has quit [Quit: Leaving]
lbia1 has quit [Quit: lbia1]
kelnos has quit [Remote host closed the connection]
<Company>
kennylevinsen: if you went the route of slimming the protocol you run into the problem of not knowing who implements which of all the extensions and can't even properly deduce what you'd need to support in your code
<Company>
you could potentially solve that with some method where you bundle a bunch of protocols into some kind of "platform", but otherwise this turns into a mess real quick
<Company>
arguably it has already
<kennylevinsen>
you already need e.g. xdg_shell - having the abstract wl_surface doesn't help developers much in that regard
<kennylevinsen>
likewise, I don't think it wp_seat would be confusing compared to wl_seat
<Company>
yeah
<Company>
I agree that your idea would have been better
<Company>
you'd just have run into this issue earlier
<kennylevinsen>
I also agree that the current landscape can be a bit confusing. Everything optional has its downsides.
<Company>
because there'd be xdg_dnd and wp_dnd and xdg_clipboard and ext_clipboard_manager and...
crazybyte4 has joined #wayland
<Company>
there'd probably be separate protocols for each type of input, too
crazybyte4 has quit []
crazybyte8 has joined #wayland
crazybyte has quit [Quit: Bye]
crazybyte8 is now known as crazybyte
crazybyte has quit []
crazybyte has joined #wayland
<Company>
wl_input for keyboard/mouse and then xdg_touch and wp_stylus and ext_joystick and ..
<Company>
I expect that to hapen anyway, just like it happened with X11 over the years
crazybyte has quit []
<kennylevinsen>
well, tbf it would probably be e.g. a wp_seat, wp_keyboard, wp_touch, ... - with joystick being the likely ext candidate
<Company>
just that there needs to be a way to keep an overview
<kennylevinsen>
wayland.app was certainly a helpful addition
crazybyte has joined #wayland
<Company>
both in terms of versions of those protocols and in which protocols are actually widely supported
<Company>
there also probably needs to be a way to get rid of protocol support
<Company>
so that things like XInput don't happen
<Company>
"a way" meaning best practices
qaqland has quit [Remote host closed the connection]
FLHerne has quit [Quit: There's a real world out here!]
FLHerne has joined #wayland
rasterman has joined #wayland
<m0squ3ra_>
is there some wiki containing the concept of damage? (I don't know if it is a weston concept or a wayland concept)
<m0squ3ra_>
any* excuse my English
<kennylevinsen>
m0squ3ra_: damage is a graphics concept, referring to parts of the screen or a buffer which has changed and therefore needs to be repainted
<m0squ3ra_>
ty
<kennylevinsen>
A Wayland client submits buffers with damage indicating areas that contain new content, which Weston uses to only paint what is needed.
<ManMower>
weston has its own concept of damage which is currently violently distinct from the normal graphical concept.
Leopold has quit [Remote host closed the connection]
<kennylevinsen>
Well isn't that great :|
<ManMower>
well, it's pretty normal except for the bugs
<daniels>
well, there’s buffer damage (for the shadow GL copies we keep of SHM buffers), which propagates into surface damage, which propagates into plane damage
<daniels>
they’re all damage, just you have to remember which kind of damage you’re dealing with, and (cough) not screw it up
<ManMower>
*^_^*
vincejv has joined #wayland
vincejv_ has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
Narrat has joined #wayland
m0squ3ra_ has quit [Quit: Lost terminal]
leon-anavi has quit [Quit: Leaving]
garnacho has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
<Company>
YaLTeR[m]: the shell screenshot code does bad things to me - it seems it runs entirely different codepaths when screenshotting a window vs screenshotting a selected region?
<Company>
because it seems my selected region is 2x scaled up even though I'm screenshotting on my 1x monitor
<Company>
or do I need to ask swick[m] about that?
___nick___ has joined #wayland
alatiera has joined #wayland
privacy has quit [Quit: Leaving]
sima has quit [Ping timeout: 480 seconds]
jlco_ has quit [Ping timeout: 480 seconds]
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
Narrat has quit []
JakeSays1 has quit [Ping timeout: 480 seconds]
danieldg has quit [Ping timeout: 480 seconds]
vsyrjala has quit [Remote host closed the connection]
soreau has quit [Ping timeout: 480 seconds]
<swick[m]>
it does indeed run two different code paths because selecting a window is supposed to create a screenshot of the window without any other windows or shell elements influencing it