Re: RFC: GtkPreview library



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 <cosimoc 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 <jstpierre 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" <cosimoc 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 <ebassi gmail com> wrote:
hi;

On 25 January 2015 at 13:31, Philip Withnall <philip 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]