cross-client surface references

[Jasper St. Pierre]

No, it's not the same thing. You want an xdg_surface interface exposed
on both sides. We don't want that. The resulting derail was us
collectively ramming our heads straight into the wall trying to figure
out any way that having the same interface exposed on both sides could
make any sense.

xdg_surface was not designed as an API to be used by multiple
consumers. There would be *no* way to make it work. None. Stop trying.

This is why I'm proposing a new API to be used in its stead.

On Thu, Jul 9, 2015 at 8:55 AM, Bill Spitzak <spitzak at gmail.com> wrote:
> On 07/09/2015 02:21 AM, Jonas Ådahl wrote:
>
>> That is more or less what was the idea before the thread derailed.
>
>
> I have no idea why you think my proposal "derailed" this when I was
> attempting to describe EXACTLY the same thing you are, except I replaced
> "fd" with a "key" which I figured is a 128-bit random number or a text
> representation of that number.
>
>> Something like:
>>
>> low-priv-client:
>>
>> xdg_surf = xdg_shell.get_xdg_surface
>> fd = export(xdg_surf)
>> * pass fd to high-priv-client via dbus *
>
>
> In my version:
>
>   key = export(xdg_surf)
>   * pass key to high-priv-client via any mechanism that can send a 128-bit
> number, such as using argv.
>
>> high-priv-client:
>>
>> * receive fd from low-priv-client via dbus *
>> xdg_foreign = import(fd)
>
>
> In my version
>   * recieve key by whatever mechanism
>   xdg_foreign = import(key, xdg_surface)
>
> I think the import needs to indicate the interface it expects. This allows
> the child to use a different version of the api, and insure the correct
> wl_proxy is created.
>
>> xdg_surf = xdg_shell.get_xdg_surface
>> xdg_surf.set_parent(xdg_foreign)
>>
>> I think that if we clarify what happens if the exported surfaces
>> disappears (which is the race you are referring to I suppose),
>
>
> That is why I said there would need to be a destroy event.
>
>> if
>> we force the set_parent(foreign) to always stack above the foreign tree
>> (similar to how subsurfaces stacking works), what would the security
>> implications be?
>
>
> Arrgh! As I have posted about 10 times now, it is EXACTLY how subsurface
> stacking works, and it should be using the SAME api! The only difference
> between a child window and a subsurface is that the compositor is allowed to
> insert other surfaces between a child and it's parent.
>
> I'm sorry I'm being abrasive in my posts but it seems I am hitting a brick
> wall. I try really hard to describe an idea, and then EXACTLY the same idea
> is posted as "here is what we want before Bill derailed it!"
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



-- 
  Jasper