10:18 wlb: wayland.freedesktop.org Merge request !85 opened by Marius Vlad (mvlad) remotes/: Remove tarballs for weston > 10.0.0 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/85
12:20 kennylevinsen: I wonder how xdg_dialog_v1's "this interface effect on toplevels that are not attached to a parent toplevel." should be interpreted
12:21 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"
12:22 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
12:36 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
12:37 kennylevinsen: Ah yes, that too
12:44 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)
12:44 kennylevinsen: (that was one too much "clarify")
12:48 jadahl: please clarify what you mean with claryifying
12:48 jadahl: :P
12:48 kennylevinsen: we should clearly clarify the clarification with clarity
12:48 jadahl: clearly
12:50 ManMower:sighs and clears the window
12:53 jadahl: ManMower: unclear why you'd clear the window if the window was all about clarity
12:55 ManMower: 🙈
12:56 jadahl: unclear? :P (i'll stop)
12:57 ManMower: :)
13:24 wlb: weston Merge request !1603 opened by Marius Vlad (mvlad) libweston/color-management: Add fallback for static_assert https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1603
14:01 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?
14:09 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.
14:10 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
15:15 mohan43u: kennylevinsen: Its a regular gtk window, which I believe is xdg_toplevel in wayland
15:24 soreau: generally speaking, with xdg in wayland, there is no way to position it
15:24 soreau: it's the compositor job to do this
15:25 soreau: some compositors still honor xwayland positioning like wayfire, but that's really neither here nor there
15:37 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
15:38 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
15:42 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
15:43 vyivel: so you have two machines, and moving window on one is replicated on the other?
15:45 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
15:46 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
15:48 mohan43u: vyivel: I can also rewrite my app to native wayland client instead of gtk client, if that is required
15:50 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
15:50 vyivel: wayland by itself doesn't have the concept of absolute window position
15:51 vyivel: xdg_surface's window_geometry exists for a different purpose, the position in it is surface-local
15:54 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
15:55 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
15:55 kennylevinsen: mohan43u: why does the remote end of the window need to move?
15:56 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
15:59 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)
16:01 kennylevinsen: More detail about the solution would be good regardless
16:03 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.
16:05 dottedmag: mohan43u: you're explaining the details, please explain what the application does from the user's perspective.
16:13 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.
16:17 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
16:37 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.
16:37 dottedmag: *allows users
16:42 wlb: weston/main: Marius Vlad * libweston/color-management: Add fallback for static_assert https://gitlab.freedesktop.org/wayland/weston/commit/3dc28308e615 libweston/color-management.c
16:42 wlb: weston Merge request !1603 merged \o/ (libweston/color-management: Add fallback for static_assert https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1603)
16:50 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
16:59 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?
17:13 mohan43u: MrCooper: exactly
17:51 soreau: mohan43u: you should be able to do that, just by calling https://wayland.app/protocols/xdg-shell#xdg_toplevel:request:move
17:56 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
18:00 soreau: you don't pass any x/y, that comes from the mouse movement during the grab
18:16 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
18:17 soreau: that's not going to work without some special communication that the compositor might support
18:17 soreau: like in wayfire, there's ipc which you could use to position views
18:18 soreau: but it's specific to wayfire, it won't work on other compositors
18:19 soreau: the only way to really move the x/y of the window is for it to resize itself by top/left edge
18:20 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..
18:25 soreau: the other thing is, the offset is relative. The client never actually knows where it is on the screen
18:26 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
18:26 soreau: then you'd know where you are in the transparent window at least
18:26 soreau: but I don't think gtk offers a way to do this either
18:26 soreau: namely, set the input region manually
18:27 soreau: but if I were to guess, I'd think there's an easier way to do what you want (wayvnc?)
18:41 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
18:44 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
18:46 soreau: but apparently, the only input is on the 'client side', so move won't work
18:46 soreau: it almost sounds like you want waypipe, but I really don't understand fully what you're acutally wanting to do still
18:47 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
18:48 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)
18:48 kennylevinsen: alternatively, if you can figure out what draggable areas of the window is you could just intercept that
18:48 kennylevinsen: Having window movement roundtrip to a remote-controlled system will also have pretty bad latency/ux
18:49 kennylevinsen: not to mention fun issues when the controlled system's output layout deviates from the controlling system
18:50 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?
18:51 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
18:51 soreau:locally remotes into kennylevinsen's client server
18:52 kennylevinsen: the security of my system is solely needing to figure out the correct order of remote/local/client/server
18:53 soreau: heh
18:53 any1: remote and local are relative terms, client and server are absolute.
18:53 kennylevinsen: yes, but in this case we have client and servers in both directions
18:54 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
18:54 soreau: remote wayland server*
18:55 kennylevinsen: well that was meant to be the wayland server on your (desk|lap)top, so local to you
18:55 soreau: subjection
18:55 any1: lol
18:58 kennylevinsen: I suggest we standardize on calling the system that is being remotely controlled "bob"
19:01 ManMower: gets my ack as long as we standardize on calling the system that is doing the controlling "robert"
21:43 bl4ckb0ne: i propose richard
22:34 soreau: now that would just be confusing