I've done the above. https://github.com/magcius/wakefield
Check it out, run make, then run: $ LD_LIBRARY_PATH=. ./test-compositor $ ./test-client-2 Right now it's a very basic prototype -- it doesn't support all functionality, it doesn't dynamically resize the surface the client handed us, and will easily crash, but for a day and a half of work, I think it proves that it can be done. On Tue, Jan 27, 2015 at 5:19 AM, Cosimo Cecchi <cosi...@gnome.org> wrote: > So you're effectively proposing that the "transport" of the data between > plugins and the widget is always Wayland, even if the session is running > under X11? That sounds like a good idea to me if it's possible to > implement. I would definitely welcome a proof of concept! > > Thanks, > Cosimo > > On Sun, Jan 25, 2015 at 4:21 PM, Jasper St. Pierre <jstpie...@mecheye.net> > wrote: > >> We could indeed write a tiny Wayland compositor that composited a single >> wl_surface as a GTK+ widget, and I wouldn't feel too bad about it. We could >> even do it while under X11, and it might be an interesting proof of >> concept. I could do a PoC if you guys want. >> On Jan 25, 2015 8:05 AM, "Cosimo Cecchi" <cosi...@gnome.org> wrote: >> >>> Fair enough, those are good points. >>> To rephrase my last message I am not well-versed in the details of >>> subsurfaces and how they would help in this case, so I will appreciate help >>> to evolve my API proposal in that direction :-) >>> >>> Cosimo >>> >>> On Sun, Jan 25, 2015 at 3:49 PM, Emmanuele Bassi <eba...@gmail.com> >>> wrote: >>> >>>> hi; >>>> >>>> On 25 January 2015 at 13:31, Philip Withnall <phi...@tecnocode.co.uk> >>>> wrote: >>>> >>>> >> That's why my proposal doesn't enforce this specific design; I'm >>>> >> definitely open to think more about how a multi-process design looks >>>> >> like, but I wouldn't want to block until that is figured out. >>>> > >>>> > To me, the security and rendering architecture of this seems pretty >>>> core >>>> > in the design, so I _would_ block on figuring it out. It doesn’t feel >>>> > like the kind of thing which can easily be bolted on or fixed >>>> > afterwards. >>>> >>>> I tend to agree; we need to start designing our API with sandboxing >>>> and security context separation from the start, these days, otherwise >>>> we'll have nothing but grief (in the form of API changes or, worse, >>>> complete rewrites) down the line. >>>> >>>> ciao, >>>> Emmanuele. >>>> >>>> -- >>>> https://www.bassi.io >>>> [@] ebassi [@gmail.com] >>>> >>> >>> >>> _______________________________________________ >>> gtk-devel-list mailing list >>> gtk-devel-list@gnome.org >>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list >>> >>> > -- Jasper
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
