Re: RFC: GtkPreview library
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
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
Re: RFC: GtkPreview library
On Sun, 2015-01-25 at 07:22 -0500, Cosimo Cecchi wrote: On Sat, Jan 24, 2015 at 4:33 AM, Carlos Garcia Campos carlo...@gnome.org wrote: I'm assuming the providers will render the contents into surfaces that the previewer will compose, not providers directly drawing into the previewer. We can share the bitmaps between processes without using anything like CORBA, simply using shared memory and sending the file descriptor with dbus. Note that providers might not be asynchronous, or thread safe. I can see a few problems with this approach: - data is not always a static bitmap. You can preview arbitrary complex things like webpages, videos, presentations, etc. In the future even possibly complex CAD drawings or whatnot, if a module gets written for them. - the problem with doing this generically is that there needs a system that notifies what has been invalidated in order to redraw, something that forwards input events, etc. - ideally we don't want to copy every frame while doing that Bastien's suggestion to use (wayland) sub-surfaces sounds like a much better fit, as they're designed specifically to address some of these problems. My understanding is that it requires writing a small wayland compositor in the widget itself; not sure yet what'd be involved with this. There's also a question about what to do on backends (like X11) that don't really support such a thing. I guess we could use XEmbed on X11, but I can see it turning messy pretty quickly. 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. Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Sat, Jan 24, 2015 at 4:33 AM, Carlos Garcia Campos carlo...@gnome.org wrote: I'm assuming the providers will render the contents into surfaces that the previewer will compose, not providers directly drawing into the previewer. We can share the bitmaps between processes without using anything like CORBA, simply using shared memory and sending the file descriptor with dbus. Note that providers might not be asynchronous, or thread safe. I can see a few problems with this approach: - data is not always a static bitmap. You can preview arbitrary complex things like webpages, videos, presentations, etc. In the future even possibly complex CAD drawings or whatnot, if a module gets written for them. - the problem with doing this generically is that there needs a system that notifies what has been invalidated in order to redraw, something that forwards input events, etc. - ideally we don't want to copy every frame while doing that Bastien's suggestion to use (wayland) sub-surfaces sounds like a much better fit, as they're designed specifically to address some of these problems. My understanding is that it requires writing a small wayland compositor in the widget itself; not sure yet what'd be involved with this. There's also a question about what to do on backends (like X11) that don't really support such a thing. I guess we could use XEmbed on X11, but I can see it turning messy pretty quickly. 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. Cosimo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
On Sat, Jan 24, 2015 at 10:07:56AM -0500, Paul Davis wrote: GTK3's CSS styling feature is a huge draw for many developers. Being able to take an understanding of themeing based on web development and apply it to native applications is really a very very nice feature. I would have talked at greater length about that rather than GObject, since many developers using any language binding stand to benefit from CSS themeing, versus the few who might one day use a little bit of GObject. I personally use more often GObject features than CSS. CSS is more for theme authors, not application authors. A small GTK+ app doesn't really need CSS, the available GTK+ widgets are sufficient and have a decent theme with Adwaita. I would cite some of the more unique widgets in GTK also, especially the newer ones that might not be known by people familiar only with GTK1 and GTK2. To better understand widgets, screenshots are needed, and a flyer is too small for screenshots (at least the three-folded A4 page). As you said, two A4 pages are not enough for describing every interesting features. Nothing prevents us from writing a brochure about GTK+ only, and another brochure about lower-level libraries, but it'd become maybe a bit too much content (that said, the FreeBSD stand has almost 10 different flyers! And in different languages). Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
