ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
bjorkintosh has quit [Quit: "Every day, computers are making people easier to use." David Temkin]
bjorkintosh has joined #wayland
mclasen has quit [Quit: mclasen]
mclasen has joined #wayland
Satan has quit [Quit: Bad stuff happened]
Satan has joined #wayland
Satan has quit []
Satan has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
tent4052 has quit []
tent405 has joined #wayland
lbia has quit [Quit: lbia]
rebtoor_ has joined #wayland
dami-lu has joined #wayland
rebtoor has quit [Ping timeout: 480 seconds]
dami-lu has quit []
Company has quit [Ping timeout: 480 seconds]
Company has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest1774
Guest1756 has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
Calandracas has quit [Ping timeout: 480 seconds]
Calandracas has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Calandracas_ has joined #wayland
Calandracas has quit [Ping timeout: 480 seconds]
Guest1774 has quit [Remote host closed the connection]
chamlis has quit [Remote host closed the connection]
chamlis has joined #wayland
fmuellner has joined #wayland
chamlis has quit [Remote host closed the connection]
chamlis has joined #wayland
coldfeet has quit [Remote host closed the connection]
chamlis has quit [Remote host closed the connection]
chamlis has joined #wayland
chamlis has quit [Remote host closed the connection]
chamlis has joined #wayland
nerdopolis has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
chamlis has quit [Remote host closed the connection]
chamlis has joined #wayland
chamlis has quit [Remote host closed the connection]
chamlis has joined #wayland
garnacho has joined #wayland
chamlis has quit [Remote host closed the connection]
chamlis has joined #wayland
chamlis has quit [Remote host closed the connection]
chamlis has joined #wayland
chamlis has quit [Remote host closed the connection]
chamlis has joined #wayland
kts has quit [Quit: Konversation terminated!]
mclasen has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<kennylevinsen>
I wonder how xdg_dialog_v1's "this interface effect on toplevels that are not attached to a parent toplevel." should be interpreted
<kennylevinsen>
it's either "you cannot use the interface which controls modality" (which makes sense, hard to be modal without something to be modal to), or "your toplevel is not a dialog if it does not have a parent"
<kennylevinsen>
I don't think the latter makes much sense - a dialog can exist without a parent, and xdg_dialog is there to register that a toplevel is a dialog
mclasen has joined #wayland
<jadahl>
kennylevinsen: I guess what needs to be clarified is if first setting some state, e.g. modal, then setting the parent, will make it modal, or if that earlier set_modal was really a no-op
<kennylevinsen>
Ah yes, that too
<kennylevinsen>
(in my case, clarifying if creating an xdg_dialog means that the surface is a dialog even if it has no parent should also be clarified)
<kennylevinsen>
(that was one too much "clarify")
<jadahl>
please clarify what you mean with claryifying
<jadahl>
:P
<kennylevinsen>
we should clearly clarify the clarification with clarity
<jadahl>
clearly
cool110 has joined #wayland
* ManMower
sighs and clears the window
cool110 is now known as Guest1808
<jadahl>
ManMower: unclear why you'd clear the window if the window was all about clarity
coldfeet has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
Moprius_ has joined #wayland
Moprius_ has quit []
Company has joined #wayland
Moprius has quit [Ping timeout: 480 seconds]
<mohan43u>
Hi, I'm struggling with a Gtk application which requires gtk_window_move() to work correctly in wayland, It seems that Gtk dont invoke xdg_toplevel_set_window_geometry() with XY values, is there any way to position an application on screen in XY co-ordinate?
<kennylevinsen>
mohan43u: In Wayland, applications do not control window management directly themselves like that. Instead you more explicitly describe your content and intent so that the server can do something appropriate for the user within its specific UX paradigm.
<kennylevinsen>
so in that regard,s saying "I want to place a window at these coordinates" is a bit of an X-Y problem - we would step back and instead ask what type of window it is
rasterman has quit [Quit: Gettin' stinky!]
narodnik has joined #wayland
kts has joined #wayland
Guest1808 has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 is now known as Guest1813
garnacho has quit [Ping timeout: 480 seconds]
feaneron has joined #wayland
mripard has quit [Quit: mripard]
tzimmermann has quit [Quit: Leaving]
<mohan43u>
kennylevinsen: Its a regular gtk window, which I believe is xdg_toplevel in wayland
<soreau>
generally speaking, with xdg in wayland, there is no way to position it
<soreau>
it's the compositor job to do this
<soreau>
some compositors still honor xwayland positioning like wayfire, but that's really neither here nor there
garnacho has joined #wayland
coldfeet has joined #wayland
<mohan43u>
soreau: yes, If I run my gtk application under Xwayland, it works exactly what I want, I can position, But my original goal is to write a wayland application
<vyivel>
a regular window shouldn't know or modify its position, which, depending on the compositor, might not even be expressed as a pair of numbers
<mohan43u>
vyivel: my application is kind of remote app running on a remote machine, the window shown through this app contains title bar, when the user click and move that title bar, the remote machine send the co-ordinates to my application, my application need to mimic the movement happening on the remote desktop screen, which requires gtk_window_move() call to work properly
<vyivel>
so you have two machines, and moving window on one is replicated on the other?
<mohan43u>
vyivel: its a remote desktop client (kind of citrix remote app concept), it should show full remote desktop, or it should show a single remote window, showing full remote desktop is pritty easy, but achieving single remote window and act like a mirror to the user inputs from the client side is what I'm struggling
<mohan43u>
vyivel: the window shown through this app contains title bar, when the user click and move that title bar, the remote machine send the co-ordinates to my application, my application need to mimic the movement happening on the remote desktop screen, which requires gtk_window_move() call to work properly
<mohan43u>
vyivel: I can also rewrite my app to native wayland client instead of gtk client, if that is required
ebassi has quit [Remote host closed the connection]
ebassi has joined #wayland
<mohan43u>
vyivel: I even tried sending XY values using xdg_toplevel_set_window_geometry(), labwc seems to position it correctly only when the XY values are positive, it screws up when the values are negative
<vyivel>
wayland by itself doesn't have the concept of absolute window position
<vyivel>
xdg_surface's window_geometry exists for a different purpose, the position in it is surface-local
<mohan43u>
vyivel: from the documents, I understand that it XY in xdg_toplevel_set_window_geometry() can only work properly when the surface is a subsurface. I was hoping even the toplevel is also a subsurface for another parent, so just tried, it didn't work as expected
leon-anavi has quit [Quit: Leaving]
<vyivel>
"XY in xdg_toplevel_set_window_geometry() can only work properly when the surface is a subsurface": this is incorrect, and an xdg_toplevel can't be a subsurface
<kennylevinsen>
mohan43u: why does the remote end of the window need to move?
<kennylevinsen>
Also just for reference in case you weren’t aware, waypipe exists for tunneling Wayland apps in a “remote app/citrix/X forwarding style - might be useful, for inspiration if nothing else
<kennylevinsen>
)The limitation on stuff like window position also makes things like remote *easier* because a Wayland app doesn’t know much about or control where it is - one doesn’t need to fake a bunch of state like output layouts and window position when it’s not visible or controllable by the app in the first place)
<kennylevinsen>
More detail about the solution would be good regardless
mclasen has quit [Quit: mclasen]
mclasen has joined #wayland
<mohan43u>
kennylevinsen: I'm not understanding you correctly, the remote window is running under windows os, it needs to be shown through my app which runs under wayland, the remote side sends me XY co-ordinate to position my wayland app on a particular screen co-ordinate.
rebtoor_ has quit [Quit: Konversation terminated!]
<dottedmag>
mohan43u: you're explaining the details, please explain what the application does from the user's perspective.
rebtoor_ has joined #wayland
rebtoor_ is now known as rebtoor
paulk has quit [Ping timeout: 480 seconds]
<mohan43u>
dottedmag: the user see the remote window which is running under windows os, it contains title-bar, when the user click on this remote title-bar and move around on the screen, user expects this remote window to move around on the screen, currently it doesn't do this.
paulk has joined #wayland
chamlis has quit [Remote host closed the connection]
chamlis has joined #wayland
<mohan43u>
dottedmag: the remote window is shown through my app, also mouse move events are captured by my app and sent to the remote machine, remote machine send back XY co-ordinate to my app, my app should position itself on this particular XY
mclasen has quit [Quit: mclasen]
mclasen has joined #wayland
<dottedmag>
Could you tell it in a way that does not involve coordinates, title bars and so on? Something like "This is a Windows app that displays a remote Wayland desktop in a window and allows use to interact with applications there as if the users were using Wayland desktop locally"? I have no idea if this description has anything to do with reality, because I can't make any sense of what you're saying so far.
<mohan43u>
dottedmag: "This is a Windows app running on a remote Windows OS, shown through a Gtk Window running in Wayland Desktop locally", I hope I described as expected
<MrCooper>
sounds like you essentially want the window to move when the user clicks on a certain area of it (e.g. where the Windows title bar is visible) and then drags?
<mohan43u>
MrCooper: exactly
fmuellner_ has joined #wayland
kts has quit [Quit: Konversation terminated!]
fmuellner has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
fossdd has quit [Remote host closed the connection]
<mohan43u>
soreau: how can I pass the XY co-ordinate in xdg_toplevel_move()? to my knowledge, it is used trigger a move request to the compositor, the movement is entirely controlled by compositor, correct me if I'm wrong
Moprius has joined #wayland
<soreau>
you don't pass any x/y, that comes from the mouse movement during the grab
Brainium has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
<mohan43u>
soreau: the problem here is programatically move the window to a certain XY position in the screen, the XY co-ordinates already sent by the remote machine to my wayland application based on the mouse movement events I sent
<soreau>
that's not going to work without some special communication that the compositor might support
<soreau>
like in wayfire, there's ipc which you could use to position views
<soreau>
but it's specific to wayfire, it won't work on other compositors
<soreau>
the only way to really move the x/y of the window is for it to resize itself by top/left edge
<soreau>
and I don't think gtk offers a way to do this, and it would probably be very jarring, because you'd have to resize top/left with offset, then attach a buffer of the old size..
<soreau>
the other thing is, the offset is relative. The client never actually knows where it is on the screen
<soreau>
now that said, there might be a way to hack it with a fullscreen transparent surface that is click-through by setting input region and then rendering your view somewhere inside of that
<soreau>
then you'd know where you are in the transparent window at least
<soreau>
but I don't think gtk offers a way to do this either
<soreau>
namely, set the input region manually
<soreau>
but if I were to guess, I'd think there's an easier way to do what you want (wayvnc?)
<kennylevinsen>
mohan43u: again, you won't be able to control the position of the window, but thi is also back to the X-Y problem: If I understand correctly, you're trying to let the connected user move the window on their own screen, and replicating an exact window position was just how you previously did that
<kennylevinsen>
if that's the case, then the position of the window doens't really matter, you're just trying to initiate a move operation
<soreau>
but apparently, the only input is on the 'client side', so move won't work
<soreau>
it almost sounds like you want waypipe, but I really don't understand fully what you're acutally wanting to do still
<kennylevinsen>
If they managed to register that the move started on the server-side, couldn't they just react to that and call toplevel::move? then let the remotely connected user have the window just move locally on their system, not replicating anything on the remote-controlled system
<kennylevinsen>
(during the move, input would no longer be sent so the window wouldn't actually move on the controlled system until the user released their cursor)
<kennylevinsen>
alternatively, if you can figure out what draggable areas of the window is you could just intercept that
<kennylevinsen>
Having window movement roundtrip to a remote-controlled system will also have pretty bad latency/ux
<kennylevinsen>
not to mention fun issues when the controlled system's output layout deviates from the controlling system
<soreau>
and then you have outputs of different sizes, remote and local. Where does it end up when local is 4k bottom right quadrant and the remote is HD?
* kennylevinsen
has a hard time figuring out what words to use - server, client, remote, local - when dealing with remote desktop. The application one wants to see is a client you want to see on your server, but you're connecting to a remote desktop server with your client, and both ends are remote from the other ends perspective
* soreau
locally remotes into kennylevinsen's client server
<kennylevinsen>
the security of my system is solely needing to figure out the correct order of remote/local/client/server
<soreau>
heh
<any1>
remote and local are relative terms, client and server are absolute.
<kennylevinsen>
yes, but in this case we have client and servers in both directions
<kennylevinsen>
e.g., waypipe: you connect a local ssh client to a remote ssh server to have a remote wayland client connect to a local wayland server
<soreau>
remote wayland server*
<kennylevinsen>
well that was meant to be the wayland server on your (desk|lap)top, so local to you
<soreau>
subjection
<any1>
lol
<kennylevinsen>
I suggest we standardize on calling the system that is being remotely controlled "bob"
vincejv has quit [Remote host closed the connection]
<ManMower>
gets my ack as long as we standardize on calling the system that is doing the controlling "robert"
kenny has quit [Ping timeout: 480 seconds]
fmuellner_ has quit [Ping timeout: 480 seconds]
kenny has joined #wayland
rebtoor_ has joined #wayland
rebtoor has quit [Read error: Connection reset by peer]
privacy has quit [autokilled: This host violated network policy. Mail support@oftc.net if you think this is in error. (2024-08-29 20:36:12)]
coldfeet has quit [Remote host closed the connection]
vincejv has joined #wayland
mvlad has quit [Remote host closed the connection]
fmuellner has joined #wayland
sima has quit [Ping timeout: 480 seconds]
latex has quit [Remote host closed the connection]
latex has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
<bl4ckb0ne>
i propose richard
rv1sr has quit []
<soreau>
now that would just be confusing
fmuellner has joined #wayland
sewn has quit [Read error: Connection reset by peer]