Skip to main content

There is a draft of xdg-foreign protocol extension, which allows to obtainobtaining handles of wl_surface's, created by other Wayland clients. Having the handle, you can obtain from it anything you can obtain from surfaces of your client. However, this protocol still has limitations:

  • Obviously, it won't work if not implemented in clients.
  • It's targeted for clients that "know"know each other, so it does not provide a way to trigger it: your client communicates with a foreign client client in some way, not covered by the extension, then. Then the foreign client publishes publishes a handle for your client via this extesionextension.
  • It gains too much control, if compared to xprop. Actually, you can even draw on foreign surfaces!

So, this willis unlikely to become a general way to get surface parameters from any client by any client. But don't lose a hope: there are a lot of an examples in tech history when a technology, initially designed for some purpose, became widely used for other purposepurposes, just like car cigarette lighters or AccesibilityAccessibility APIs in Android. Moreover, in the future, there may appear a protocol extension that is more suited for your task, as there is definitely a need for it (for example, for time trackers).

There is a draft of xdg-foreign protocol extension, which allows to obtain handles of wl_surface's, created by other Wayland clients. Having the handle, you can obtain from it anything you can obtain from surfaces of your client. However, this protocol still has limitations:

  • Obviously, it won't work if not implemented in clients.
  • It's targeted for clients that "know" each other, so it does not provide a way to trigger it: your client communicates with foreign client in some way, not covered by the extension, then foreign client publishes a handle for your client via this extesion.
  • It gains too much control, if compared to xprop. Actually, you can even draw on foreign surfaces!

So, this will unlikely become a general way to get surface parameters from any client by any client. But don't lose a hope: there are a lot of an examples in tech history when a technology, initially designed for some purpose, became widely used for other purpose, just like car cigarette lighters or Accesibility APIs in Android. Moreover, in future, there may appear a protocol extension that is more suited for your task, as there is definitely a need for it (for example, for time trackers).

There is a draft of xdg-foreign protocol extension, which allows obtaining handles of wl_surface's, created by other Wayland clients. Having the handle, you can obtain from it anything you can obtain from surfaces of your client. However, this protocol still has limitations:

  • Obviously, it won't work if not implemented in clients.
  • It's targeted for clients that know each other, so it does not provide a way to trigger it: your client communicates with a foreign client in some way, not covered by the extension. Then the foreign client publishes a handle for your client via this extension.
  • It gains too much control, if compared to xprop. Actually, you can even draw on foreign surfaces!

So, this is unlikely to become a general way to get surface parameters from any client by any client. But don't lose a hope: there are a lot of examples in tech history when a technology, initially designed for some purpose, became widely used for other purposes, just like car cigarette lighters or Accessibility APIs in Android. Moreover, in the future, there may appear a protocol extension that is more suited for your task, as there is definitely a need for it (for example, for time trackers).

Source Link
bodqhrohro
  • 386
  • 1
  • 9

There is a draft of xdg-foreign protocol extension, which allows to obtain handles of wl_surface's, created by other Wayland clients. Having the handle, you can obtain from it anything you can obtain from surfaces of your client. However, this protocol still has limitations:

  • Obviously, it won't work if not implemented in clients.
  • It's targeted for clients that "know" each other, so it does not provide a way to trigger it: your client communicates with foreign client in some way, not covered by the extension, then foreign client publishes a handle for your client via this extesion.
  • It gains too much control, if compared to xprop. Actually, you can even draw on foreign surfaces!

So, this will unlikely become a general way to get surface parameters from any client by any client. But don't lose a hope: there are a lot of an examples in tech history when a technology, initially designed for some purpose, became widely used for other purpose, just like car cigarette lighters or Accesibility APIs in Android. Moreover, in future, there may appear a protocol extension that is more suited for your task, as there is definitely a need for it (for example, for time trackers).