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
fmuellner has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
i509vcb has joined #wayland
caveman has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
mohamexiety has quit [Quit: Konversation terminated!]
nerdopolis has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
<Company>
DemiMarie: said yesterday that I prefer v1
<Company>
at least from a gut feeling perspective
<DemiMarie>
Company: why is that?
<Company>
because the buffer and the surface are different in more than just a scale factor
<Company>
so it feels better to me to have some way like wp_viewport to describe which coordinate of the buffer maps to the top left or the surface and which maps to the bottom right
<Company>
and you want to make it possible to do subpixel positioning for that somehow
<Company>
and potentially integrate with transforms
<Company>
with the vertical monitor thing
<Company>
which needs some kind of complex 2d matrix to describe that
<Company>
my biggest worry is that there's so many nudges in so many prortocols, that it's soon gonna be impossible to do the right thing with every compositor
<Company>
but maybe that's overblown because there's just 4 (?) different compositors that are worth supporting and that can usually somewhat agree on stuff
<Company>
but for buffer scale, it's already 3 options for determining (fractional-scale if supported, buffer-scale if wl_surface_version >= 6, output otherwise) and 2 options for setting it (wp_viewport vs set_buffer_scale)
<danielle1>
Hey, my mouse seems to often drop a held click without me releasing the button (especially with lag). I was wondering if there were any way to make this more reliable.
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
invertedoftc096 has quit []
invertedoftc096 has joined #wayland
rosefromthedead has quit []
mvlad has quit [Quit: Leaving]
<DemiMarie>
Company: which 4? Mutter, KWin, wlroots, Smithay?
moa has quit [Read error: Connection reset by peer]
moa has joined #wayland
<Company>
I was thinking Weston
molinari has quit [Remote host closed the connection]
molinari has joined #wayland
<kennylevinsen>
well you don't support compositors, you support protocols - supporting only a subset of those is fine though.
<kennylevinsen>
things go bad if you start to go "I support xdg-shell, but only in compositor XYZ's interpretation and bugs" :P
Jerric has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Quit: WeeChat 3.6]
danvet has quit [Ping timeout: 480 seconds]
Narrat has quit []
dcz_ has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
luc4 has quit []
kelnos_ has joined #wayland
molinari has quit [Ping timeout: 480 seconds]
kelnos_ has left #wayland [#wayland]
kelnos has joined #wayland
<kelnos>
hey all, having a problem, wondering if what i'm doing is even possible. i'm writing an embedded/nested compositor (i want to support out-of-process panel applets for xfce). my current approach is to have the first xdg_toplevel created by the applet process get embedded in the parent window, and then any other toplevels and popups created will get "forwarded" to the parent compositor. (i've considered passing two wayland display
<kelnos>
handles to the client, but this doesn't meet requirements for other reasons.) i have the embedded window working ok, and forwarding xdg_toplevels is almost working. but i can't get xdg_popups working. here's the problem:
<kelnos>
when i create the embedded compositor, i set it up to draw into a wl_surface in the parent compositor. i'm using GTK, so this surface is created and owned/managed by GDK (obtained via gdk_wayland_window_get_wl_surface()). for xdg_popups, the most common case is that the application will create one and set the parent as the embedded xdg_toplevel. however, that toplevel exists only in the embedded compositor, but the popup is to be
<kelnos>
forwarded to the parent. so instead i want to use the closest thing: that same GTK-owned wl_surface that the embedded compositor is drawing into.
<kelnos>
first problem: i don't have the xdg_surface handle for that wl_surface, which is required for xdg_popup's parent. that's hidden in GDK's internals. so my next thought was to use xdg-foreign to export that surface, then immediately reimport it, and use xdg_imported.set_parent_of(). the problem is that set_parent_of() only accepts an xdg_toplevel as the child argument, but i have an xdg_popup to pass. so that doesn't work either.
<kelnos>
next idea: put up a transparent dummy xdg_toplevel as the child window, and then use that as the parent of the xdg_popup. problem there is that i can't control where the parent compositor will place that toplevel, and of course i want it to 'mirror' what the popup's positioner would set.
<kelnos>
sorry for the big wall of text... is there any way i can achieve what i'm trying to accomplish?
cvmn has joined #wayland
caveman has quit [Remote host closed the connection]
_libaneid1 has joined #wayland
<kennylevinsen>
kelnos: so you want your nested compositor to render its xdg-shell clients to its own xdg-toplevel, but you are limited by gtk?
<kelnos>
sorry, no, i'm not explaining this well
<kennylevinsen>
well, two options: 1. Stay in this setup - If you cannot obtain the xdg_toplevel to make popups, make gtk create them for you. 2. Perform actual composite, rendering everything to the surface (e.g. use wlroots for that)
jmdaemon has quit [Ping timeout: 480 seconds]
<kelnos>
the first toplevel the 'child' app starts will get drawn into a subsurface of a surface that's controlled by gtk. that part is working fine, actually. but then if the 'child' app wants to put up a popup, i want to 'forward' it to the 'parent' compositor. the problem is that xdg_popups require a parent surface, but the parent surface is the one "inside" the embedded compositor, so i need a parent xdg_surface in the parent compositor
<kelnos>
the reason i need to forward is because these popups won't necessarily be contained inside the embedded compositor's drawing area
<kennylevinsen>
so the target in the parent is not an xdg_surface? or is it one that you do not have access to? In case of the former, you would have to use subsurfaces or composite, constraining yourself to the area of the parent surface. In case of the latter, you could coerce gtk to create the popups for you.
<kelnos>
the area in the parent where the embedded compositor draws is indeed an xdg_surface, but i can only get the wl_surface handle for it (because GDK doesn't give access to the xdg_surface).
<kelnos>
not sure what you mean about coercing gtk to create them -- gtk (in the child app) _is_ creating them, just in the embedded compositor. my plan was to have the embedded compositor create a corresponding popup in the parent compositor, and then synchronize/forward state between the two
<kelnos>
but the one bit of state i can't properly handle is the parent surface for the popup in the parent compositor
<kennylevinsen>
what happens in the child app is not particularly relevant. If you use Gtk in the parent, but gtk does not expose the xdg_surface to make popups, then manage popups through gtk/gdk API instead and get the wl_surface for that for rendering.
<kelnos>
oh, i see what you mean. call the GtkMenu APIs in my embedded compositor in order to create the popups on the parent compositor.
<kennylevinsen>
yeah not a Gtk expert, but this would be similar-ish to what Firefox does - letting Gtk handle what Gtk must handle, and getting wl_surface objects for itself where possible
<kelnos>
hmmm. the problem there is that i don't really know how. the child app has created a popup, and the embedded compositor just sees an xdg_popup instance. it has no idea that it holds a GtkMenu or GtkMenuItems, and even if i could assume that, i have no access to those data structures in order to duplicate them in my gtk calls
<kelnos>
(the goal here was also to be toolkit-agnostic; my embedded compositor library doesn't actually use gtk. it just so happens that i'm using gtk for testing it, as the end use-case of xfce4-panel does use gtk)
tzimmermann_ has joined #wayland
<kennylevinsen>
not quite, you're not interested in making menu items, but making a "popup window" (GTK_WINDOW_POPUP)
<kennylevinsen>
this should give you a gtk window thingiemabobber, backed by an xdg_popup
<kelnos>
ohh, i see what you mean. and then i could use gtk's functions to pop that up on the existing parent-compositor gtk-controled surface that i have
jmdaemon has joined #wayland
<kelnos>
and somehow draw into it rather than letting gtk draw its own thing
<kelnos>
that does introduce a dependency on gtk, but that might be the only way to do it
<kennylevinsen>
gtk generally doesn't like not doing that - firefox puts opaque subsurfaces on top of things to get control
<kelnos>
gotcha. yeah, not surprised i'll have to fight with gtk a bit
tzimmermann has quit [Ping timeout: 480 seconds]
<kelnos>
thank you for your help! i think this gives me a path forward
<kennylevinsen>
well you already have gtk/gdk in your compositor, no? Otherwise, I'd say that this is outside the scope of either and for something as involved as a nested compositor I'd probably recommend handling things from the toplevel and down by hand. :)
<kelnos>
i actually don't already have gtk/gdk in the compositor. just that the parent app that will use it, and child apps that will end up connecting to it, happen to be written using gtk.
_libaneid1 has quit [Remote host closed the connection]
<kelnos>
what i'm thinking, though, is that my compositor currently just takes a wl_surface to draw into. it should also take an xdg_surface for that surface, for the case where it's being used with a toolkit (that is not gtk) that gives access to it. in that case, there's no problem, popups can use that as the parent. in the case i have, where i don't have that xdg_surface, my embedded compositor library can fire off a signal that just says
<kelnos>
"hey, i have a popup, and i need a place to draw it into on the parent, give it to me". and for my gtk implementation, i can do what you suggested in response to that signal
<kennylevinsen>
yeah that could work
<kelnos>
it's feeling pretty ugly, and i suspect (as you say) i'll have some fighting against gtk to do, but... right, could work
<kennylevinsen>
note that depending on the xdg_shell version you chose to expose, you might need a few more options for controlling the popup (reposition support, anchor, gravity, constraints)
<kelnos>
ah, yeah. so far just exposing the current version, but may want to pare that back a bit. my current code forwards/syncs all of that state on the positioner back and forth, at least
cheatbeat has joined #wayland
cheatbeat has left #wayland [#wayland]
<kelnos>
anyhow, thanks again! hopefully will have something useful to show for my work at some point!