Mark Thomas wrote:
>
> As part of my current attempts to get MATE fully working on Wayland, I was
> planning to take a look at porting mate-panel this weekend. However, I
> pretty quickly hit the first snag, which is that Gtk on Wayland doesn't
> support the GtkSocket/GtkPlug interface, which ma
On 02/19/2014 02:42 AM, Pekka Paalanen wrote:
Besides, it's not that much code, really. clients/nested.c is 1140
lines, and that includes support for EGL-passthrough so that
nested-client.c can efficiently use GLES rendering.
Sample code like this does help a lot.
I would still be worried tha
On Tue, 18 Feb 2014 19:09:45 + (GMT)
Mark Thomas wrote:
> On Mon, 17 Feb 2014, Bill Spitzak wrote:
>
> > I do believe users are looking for something more like this than for
> > implementing a subcompositor. Subcompositor really worries me as it relies
> > on
> > the buffers being passed
Mark Thomas wrote:
I suggest you read up on the subsurface protocol. A "subsurface" object
takes two "surface" arguments, one is the parent to attach to, and the
other is the child surface that becomes the subsurface.
You are right, the actual object I wanted to send from A to B is a
surf
On Tue, Feb 18, 2014 at 2:22 PM, Bill Spitzak wrote:
> On 02/18/2014 11:09 AM, Mark Thomas wrote:
>
> I think the above description can be greatly simplified by removing
>>> the "hole" and "plug" objects and just using a subsurface:
>>>
>>> A creates a main surface
>>> A creates a subsurface f
On Tue, 18 Feb 2014, Bill Spitzak wrote:
On 02/18/2014 11:09 AM, Mark Thomas wrote:
The "hole" and "plug" are meaningful objects and are needed, at least
server-side, for some associated state. They're also helpful for
limiting the amount of uid-dipping a client can do, as only holes and
plug
On 02/18/2014 11:09 AM, Mark Thomas wrote:
I think the above description can be greatly simplified by removing
the "hole" and "plug" objects and just using a subsurface:
A creates a main surface
A creates a subsurface for the "hole"
A gets the uid of the subsurface from the compositor
A pas
On Mon, 17 Feb 2014, Bill Spitzak wrote:
Mark Thomas wrote:
I've pushed some doc updates to the protocol.xml file my git repo. But
in terms of Jonas Ådahl's proposal, my protocol works the other way round:
A creates a main surface
A creates a "hole" on that surface and sets its position
On Mon, Feb 17, 2014 at 6:41 PM, Jasper St. Pierre wrote:
> GtkPlug and GtkSocket are really implemented in terms of XEmbed. As we've
> found, XEmbed has a surprising number of problems in real-world use cases,
> so it's considered deprecated.
>
> Building something special-case for panels seems m
On Mon, Feb 17, 2014 at 10:59:11PM +, Mark Thomas wrote:
> On Mon, 17 Feb 2014, Pekka Paalanen wrote:
>
> >On Mon, 17 Feb 2014 00:04:19 + (GMT)
> >Mark Thomas wrote:
> >
> >> - The subsurface has separate focus from the main window surface. For
> >>the usual use cases of embedding like
On Mon, 17 Feb 2014 22:59:11 + (GMT)
Mark Thomas wrote:
> On Mon, 17 Feb 2014, Pekka Paalanen wrote:
>
> > On Mon, 17 Feb 2014 00:04:19 + (GMT)
> > Mark Thomas wrote:
> >
> >>- The subsurface has separate focus from the main window surface. For
> >> the usual use cases of embedding
Mark Thomas wrote:
I've pushed some doc updates to the protocol.xml file my git repo. But
in terms of Jonas Ådahl's proposal, my protocol works the other way round:
A creates a main surface
A creates a "hole" on that surface and sets its position and size
A gets the uid (handle) from the
GtkPlug and GtkSocket are really implemented in terms of XEmbed. As we've
found, XEmbed has a surprising number of problems in real-world use cases,
so it's considered deprecated.
Building something special-case for panels seems much better than trying to
implement something generic like WaylandEm
On Mon, 17 Feb 2014, Pekka Paalanen wrote:
On Mon, 17 Feb 2014 00:04:19 + (GMT)
Mark Thomas wrote:
- The subsurface has separate focus from the main window surface. For
the usual use cases of embedding like this, you'd prefer the parent
surface to remain focused (or at least, appear f
On Mon, 17 Feb 2014 00:04:19 + (GMT)
Mark Thomas wrote:
>
> As part of my current attempts to get MATE fully working on Wayland, I was
> planning to take a look at porting mate-panel this weekend. However, I
> pretty quickly hit the first snag, which is that Gtk on Wayland doesn't
> supp
As part of my current attempts to get MATE fully working on Wayland, I was
planning to take a look at porting mate-panel this weekend. However, I
pretty quickly hit the first snag, which is that Gtk on Wayland doesn't
support the GtkSocket/GtkPlug interface, which mate-panel relies heavily
u
16 matches
Mail list logo
