On Thu, 09 Jul 2015 09:13:54 -0700
Bill Spitzak wrote:
> I thought about having the ID work only once like you propose, but I
> think this means that a client must be able to create unlimited ID's per
> object, and thus a malicious one can fill up the server's map from ID to
> object.
If that
On Thu, Jul 9, 2015 at 5:58 AM, Jonas Ådahl wrote:
>
> Yea, an inverse of xdg_surface.set_parent on xdg_foreign sounds like the
> best option to me too. We can't be too specific though, adding too much
> DE design into the protocol (like making it modal or other things that
> might not apply to n
On 07/09/2015 02:19 AM, Jasper St. Pierre wrote:
Calling sandboxed_surface_manager.get_surface_for_id(); retrieves that
surface and deletes the ID from the global namespace.
I thought about having the ID work only once like you propose, but I
think this means that a client must be able to cre
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_su
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 12
On Thu, Jul 09, 2015 at 03:10:51PM +0200, Alexander Larsson wrote:
> On Thu, 2015-07-09 at 20:58 +0800, Jonas Ådahl wrote:
> > On Thu, Jul 09, 2015 at 01:26:09PM +0100, Daniel Stone wrote:
>
> > > Or rather, xdg_foreign.reparent_as_dialog_into(xdg_surface). I like
> > > the idea of limiting the su
On Thu, 2015-07-09 at 20:58 +0800, Jonas Ådahl wrote:
> On Thu, Jul 09, 2015 at 01:26:09PM +0100, Daniel Stone wrote:
> > Or rather, xdg_foreign.reparent_as_dialog_into(xdg_surface). I like
> > the idea of limiting the surface area as much as possible, to not
> > only
> > make it explicit as to w
On Thu, Jul 09, 2015 at 01:26:09PM +0100, Daniel Stone wrote:
> Hi,
>
> On 9 July 2015 at 12:51, Alexander Larsson wrote:
> > So, you disagree with xdg_surface.set_parent accepting both xdg_surface
> > and xdg_foreign objects?
>
> It can't. Typing is very strict, and there is no subtyping.
> xdg
Hi,
On 9 July 2015 at 12:51, Alexander Larsson wrote:
> So, you disagree with xdg_surface.set_parent accepting both xdg_surface
> and xdg_foreign objects?
It can't. Typing is very strict, and there is no subtyping.
xdg_surface doesn't extend wl_surface in a traditional (C++/Java)
style inherited
On Thu, 2015-07-09 at 13:38 +0300, Pekka Paalanen wrote:
> On Thu, 09 Jul 2015 11:37:06 +0200
> Alexander Larsson wrote:
>
> > On Thu, 2015-07-09 at 02:19 -0700, Jasper St. Pierre wrote:
> > > My issue with this is that you're tying two things together. You
> > > want
> > > access to """a surfac
On Thu, Jul 09, 2015 at 01:38:32PM +0300, Pekka Paalanen wrote:
> On Thu, 09 Jul 2015 11:37:06 +0200
> Alexander Larsson wrote:
>
> > On Thu, 2015-07-09 at 02:19 -0700, Jasper St. Pierre wrote:
> > > My issue with this is that you're tying two things together. You want
> > > access to """a surfac
On Thu, 09 Jul 2015 11:37:06 +0200
Alexander Larsson wrote:
> On Thu, 2015-07-09 at 02:19 -0700, Jasper St. Pierre wrote:
> > My issue with this is that you're tying two things together. You want
> > access to """a surface""", and you think you can do this by having
> > global cross-client object
On Thu, 2015-07-09 at 02:19 -0700, Jasper St. Pierre wrote:
> My issue with this is that you're tying two things together. You want
> access to """a surface""", and you think you can do this by having
> global cross-client objects and handles and such. I don't see a need
> for this. We can just add
On Thu, 2015-07-09 at 10:00 +0100, Daniel Stone wrote:
> > However, the problem I have now is different, in that it involves
> > an
> > existing, less privileged client initiating a higher privileged
> > operation (in a controlled fashion) and the higher privileged
> > client
> > needing to refe
On Thu, Jul 09, 2015 at 10:00:56AM +0100, Daniel Stone wrote:
> Hi Alex,
>
> On 9 July 2015 at 09:44, Alexander Larsson wrote:
> > On Wed, 2015-07-08 at 12:47 +0100, Daniel Stone wrote:
> >> This thread has sadly degenerated into: 'what if Wayland's object
> >> model was totally different? what i
My issue with this is that you're tying two things together. You want
access to """a surface""", and you think you can do this by having
global cross-client objects and handles and such. I don't see a need
for this. We can just add a new protocol that does what we want.
We have a few requirements:
Hi Alex,
On 9 July 2015 at 09:44, Alexander Larsson wrote:
> On Wed, 2015-07-08 at 12:47 +0100, Daniel Stone wrote:
>> This thread has sadly degenerated into: 'what if Wayland's object
>> model was totally different? what if some of its explicit core design
>> principles were thrown out the windo
On Wed, 2015-07-08 at 12:47 +0100, Daniel Stone wrote:
> Hi,
> None of them will really work.
>
> This thread has sadly degenerated into: 'what if Wayland's object
> model was totally different? what if some of its explicit core design
> principles were thrown out the window?'. Realistically, tha
Hi,
On 8 July 2015 at 18:46, Bill Spitzak wrote:
> All your objections sounds like you are confusing the implementation with
> the abstraction that the client program sees. A few examples:
No, not at all. On the contrary ...
> On Wed, Jul 8, 2015 at 4:47 AM, Daniel Stone wrote:
>
>> > Yes this
All your objections sounds like you are confusing the implementation with
the abstraction that the client program sees. A few examples:
On Wed, Jul 8, 2015 at 4:47 AM, Daniel Stone wrote:
> Yes this also creates
> > multiple C structures in the server, to keep track of the actual client
> > comm
Hi,
On 7 July 2015 at 21:15, Bill Spitzak wrote:
> On Mon, Jul 6, 2015 at 11:53 PM, Pekka Paalanen wrote:
>> Multiple "handles" to the same underlying server-side object from
>> completely asynchronous contexts (different processes). I can't see
>> that ending well at all, considering that *noth
On Mon, Jul 6, 2015 at 11:53 PM, Pekka Paalanen wrote:
> Multiple "handles" to the same underlying server-side object from
> completely asynchronous contexts (different processes). I can't see
> that ending well at all, considering that *nothing* we have ever
> designed for Wayland accounts for
On Fri, 2015-07-03 at 18:10 +0800, Jonas Ådahl wrote:
>
> With "see" I suppose you mean "be aware and map", because it wouldn't
> see the content.
Sure, there is no need for the other client to ever see (or change) the
contents of the window (or get events or whatever). This is purely
about bein
On Mon, 6 Jul 2015 11:25:53 -0700
Bill Spitzak wrote:
> On Fri, Jul 3, 2015 at 3:10 AM, Jonas Ådahl wrote:
>
> >
> > > This would work, but it still feels wrong to me. It has the same
> > > priority-inversion as before (the less privileged clients gets to see
> > > the more privileged one). It
On Fri, Jul 3, 2015 at 3:10 AM, Jonas Ådahl wrote:
>
> > This would work, but it still feels wrong to me. It has the same
> > priority-inversion as before (the less privileged clients gets to see
> > the more privileged one). It also limits what the "open file dialog"
> > client can do. For insta
On Fri, Jul 03, 2015 at 11:52:53AM +0200, Alexander Larsson wrote:
> On fre, 2015-07-03 at 17:24 +0800, Jonas Ådahl wrote:
> >
> > As an option prior to ending up with taking the nested compositing
> > path,
> > I had a proposal that sounds similar to what you are talking about:
> >
> > http://l
On fre, 2015-07-03 at 17:24 +0800, Jonas Ådahl wrote:
>
> As an option prior to ending up with taking the nested compositing
> path,
> I had a proposal that sounds similar to what you are talking about:
>
> http://lists.freedesktop.org/archives/wayland-devel/2013
> -March/008093.html
>
> What i
On Fri, Jul 03, 2015 at 10:37:01AM +0200, Alexander Larsson wrote:
> I understand the ideas behind not allowing one client to access a
> surface from another client. However, there are cases where we really
> want one client to refer to a surface (typically a xdg_surface) from
> another client.
>
I understand the ideas behind not allowing one client to access a
surface from another client. However, there are cases where we really
want one client to refer to a surface (typically a xdg_surface) from
another client.
In particular, I have a need for this in my sandboxing work. Consider a
setup
29 matches
Mail list logo
