Re: RFC: GtkPreview library
On Thu, Jan 29, 2015 at 6:58 PM, Paul Davis p...@linuxaudiosystems.com wrote: On Thu, Jan 29, 2015 at 7:34 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: After talking to Owen today, I'm wondering if it makes sense to consider GtkPreview a portable widget. These platforms tend to already have their own document preview systems, and I'm not sure it makes sense to port all our apps (evince preview system, LibreOffice preview system) to use our own system instead of simply using the native preview widget. Its a fine point. But consider the perspective of a GTK developer who comes across GtkPreview and wants to write a cross-platform application using it. Embedding non-GTK widgets/views/thingdings inside GTK is still a bit of black art ... An almost identical argument can be made for the file browser and yet ... Would it make sense instead to provide GtkPreviewer on all platforms, but implement it in terms of each platform's native previewer? That's what app developers would end up doing anyway if we considered it non-portable. -- Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
After talking to Owen today, I'm wondering if it makes sense to consider GtkPreview a portable widget. These platforms tend to already have their own document preview systems, and I'm not sure it makes sense to port all our apps (evince preview system, LibreOffice preview system) to use our own system instead of simply using the native preview widget. OS X has QuickLook: https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/Quicklook_Programming_Guide/Introduction/Introduction.html While I can't find a Win32 equivalent, it seems file pickers use IThumbnailCache: https://msdn.microsoft.com/en-us/library/windows/desktop/bb774628%28v=vs.85%29.aspx On Wed, Jan 28, 2015 at 1:23 AM, Jasper St. Pierre jstpie...@mecheye.net wrote: All of this is part of wl_event_loop, which is an unfortunate public API that should probably go away. On Wed, Jan 28, 2015 at 1:21 AM, Philip Chimento philip.chime...@gmail.com wrote: On Tue, Jan 27, 2015 at 8:49 AM, Jasper St. Pierre jstpie...@mecheye.net wrote: Gah. I always get those backwards. I actually typed SCM_RIGHTS and then changed it to SCM_CREDENTIALS. I still don't understand why fd passing is called rights. On Tue, Jan 27, 2015 at 11:25 AM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: On 27/01/15 15:55, Jasper St. Pierre wrote: Wayland requires two features that would perhaps make it unportable: FD passing (SCM_CREDENTIALS), and shared memory (allocate a temporary files, ftruncate it, mmap it, unlink it and then send the fd across the wire). Everything else is just a simple Unix domain socket. Does OS X support those two features? I think you mean SCM_RIGHTS? SCM_RIGHTS is here's a message with an open fd attached. It's how D-Bus does fd-passing, so if D-Bus fd-passing works on your favourite platform, Wayland fd-passing should too. SCM_CREDENTIALS is here's a message with my uid, gid and pid[1] attached, the kernel will check that I haven't lied to you (also called SCM_CREDS on e.g. FreeBSD). Basically every Unix has either this or a syscall to query those things or both, but most Unixes also have their own unique spelling for the API, because standards are hard.[2] S [1] Strictly speaking the uid, gid and pid I had at the time I opened this socket [2] Except that FreeBSD, Dragonfly BSD and Hurd share SCM_CREDS, and several platforms (sadly not including Linux) share getpeereid(). For the gory details see libdbus source code. I put it to the test and tried to build Jasper's proof of concept (and therefore Wayland) on OSX. I didn't get very far. Wayland's configure.ac checks for SFD_CLOEXEC and TFD_CLOEXEC which implies that it uses signalfd() and timerfd(), not available on OSX. I guess the replacement would be something with kqueue though I really haven't the faintest idea what I'm talking about there. Wayland also wants clock_gettime() - not insurmountable to provide on OSX but afaik uses a different API, quick googling showed up this: http://stackoverflow.com/a/6725161/172999 PS. Funny thing that this is one of the top results for googling SFD_CLOEXEC, even without adding osx or wayland: http://stackoverflow.com/questions/27864027/sfd-cloexec-wayland Best, -- Philip -- Jasper -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Thu, Jan 29, 2015 at 7:34 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: After talking to Owen today, I'm wondering if it makes sense to consider GtkPreview a portable widget. These platforms tend to already have their own document preview systems, and I'm not sure it makes sense to port all our apps (evince preview system, LibreOffice preview system) to use our own system instead of simply using the native preview widget. Its a fine point. But consider the perspective of a GTK developer who comes across GtkPreview and wants to write a cross-platform application using it. Embedding non-GTK widgets/views/thingdings inside GTK is still a bit of black art ... An almost identical argument can be made for the file browser and yet ... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
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
Re: RFC: GtkPreview library
On Tue, Jan 27, 2015 at 2:23 PM, Paul Davis p...@linuxaudiosystems.com wrote: what happened to the idea of GTK being a cross-platform toolkit? you're seriously proposing building something as significant as a Preview widget around a technology that isn't even deployed on most Linux systems yet, and will almost certainly never be available on other platforms? Paul, I don't think you understand what is being proposed here, and I much dislike the aggressive tone you are imposing on this conversation. Whether to use something different than a Wayland transport on non-Linux platforms is entirely up for debate. I am not familiar with how Windows and OSX implement previews, and whether integration with the native platform APIs is desirable in those cases, but I will point out that a simple shared memory transport can be used with Wayland, which should work fine even on those platforms. Cosimo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
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! what happened to the idea of GTK being a cross-platform toolkit? you're seriously proposing building something as significant as a Preview widget around a technology that isn't even deployed on most Linux systems yet, and will almost certainly never be available on other platforms? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Tue, Jan 27, 2015 at 9:42 AM, Cosimo Cecchi cosi...@gnome.org wrote: On Tue, Jan 27, 2015 at 2:23 PM, Paul Davis p...@linuxaudiosystems.com wrote: what happened to the idea of GTK being a cross-platform toolkit? you're seriously proposing building something as significant as a Preview widget around a technology that isn't even deployed on most Linux systems yet, and will almost certainly never be available on other platforms? Paul, I don't think you understand what is being proposed here, and I much dislike the aggressive tone you are imposing on this conversation. Whether to use something different than a Wayland transport on non-Linux platforms is entirely up for debate. I am not familiar with how Windows and OSX implement previews, and whether integration with the native platform APIs is desirable in those cases, but I will point out that a simple shared memory transport can be used with Wayland, which should work fine even on those platforms. I'm not trying to be aggressive. I've been very active at trying to keep GTK functioning and improving on OS X (less so in the immediate past, but a lot more a year or two ago). I understand the appeal of using existing technology (i.e. Wayland) to accomplish something when it appears that it will make it much easier. But if GTK is still at least nominally cross-platform, then surely the place to start is a higher level abstraction of the transport system, and then later to bolt wayland onto that design under the hood, rather than starting with Wayland and then shrugging one's hands and saying do something like Wayland on other platforms? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
All of this is part of wl_event_loop, which is an unfortunate public API that should probably go away. On Wed, Jan 28, 2015 at 1:21 AM, Philip Chimento philip.chime...@gmail.com wrote: On Tue, Jan 27, 2015 at 8:49 AM, Jasper St. Pierre jstpie...@mecheye.net wrote: Gah. I always get those backwards. I actually typed SCM_RIGHTS and then changed it to SCM_CREDENTIALS. I still don't understand why fd passing is called rights. On Tue, Jan 27, 2015 at 11:25 AM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: On 27/01/15 15:55, Jasper St. Pierre wrote: Wayland requires two features that would perhaps make it unportable: FD passing (SCM_CREDENTIALS), and shared memory (allocate a temporary files, ftruncate it, mmap it, unlink it and then send the fd across the wire). Everything else is just a simple Unix domain socket. Does OS X support those two features? I think you mean SCM_RIGHTS? SCM_RIGHTS is here's a message with an open fd attached. It's how D-Bus does fd-passing, so if D-Bus fd-passing works on your favourite platform, Wayland fd-passing should too. SCM_CREDENTIALS is here's a message with my uid, gid and pid[1] attached, the kernel will check that I haven't lied to you (also called SCM_CREDS on e.g. FreeBSD). Basically every Unix has either this or a syscall to query those things or both, but most Unixes also have their own unique spelling for the API, because standards are hard.[2] S [1] Strictly speaking the uid, gid and pid I had at the time I opened this socket [2] Except that FreeBSD, Dragonfly BSD and Hurd share SCM_CREDS, and several platforms (sadly not including Linux) share getpeereid(). For the gory details see libdbus source code. I put it to the test and tried to build Jasper's proof of concept (and therefore Wayland) on OSX. I didn't get very far. Wayland's configure.ac checks for SFD_CLOEXEC and TFD_CLOEXEC which implies that it uses signalfd() and timerfd(), not available on OSX. I guess the replacement would be something with kqueue though I really haven't the faintest idea what I'm talking about there. Wayland also wants clock_gettime() - not insurmountable to provide on OSX but afaik uses a different API, quick googling showed up this: http://stackoverflow.com/a/6725161/172999 PS. Funny thing that this is one of the top results for googling SFD_CLOEXEC, even without adding osx or wayland: http://stackoverflow.com/questions/27864027/sfd-cloexec-wayland Best, -- Philip -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Tue, Jan 27, 2015 at 8:49 AM, Jasper St. Pierre jstpie...@mecheye.net wrote: Gah. I always get those backwards. I actually typed SCM_RIGHTS and then changed it to SCM_CREDENTIALS. I still don't understand why fd passing is called rights. On Tue, Jan 27, 2015 at 11:25 AM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: On 27/01/15 15:55, Jasper St. Pierre wrote: Wayland requires two features that would perhaps make it unportable: FD passing (SCM_CREDENTIALS), and shared memory (allocate a temporary files, ftruncate it, mmap it, unlink it and then send the fd across the wire). Everything else is just a simple Unix domain socket. Does OS X support those two features? I think you mean SCM_RIGHTS? SCM_RIGHTS is here's a message with an open fd attached. It's how D-Bus does fd-passing, so if D-Bus fd-passing works on your favourite platform, Wayland fd-passing should too. SCM_CREDENTIALS is here's a message with my uid, gid and pid[1] attached, the kernel will check that I haven't lied to you (also called SCM_CREDS on e.g. FreeBSD). Basically every Unix has either this or a syscall to query those things or both, but most Unixes also have their own unique spelling for the API, because standards are hard.[2] S [1] Strictly speaking the uid, gid and pid I had at the time I opened this socket [2] Except that FreeBSD, Dragonfly BSD and Hurd share SCM_CREDS, and several platforms (sadly not including Linux) share getpeereid(). For the gory details see libdbus source code. I put it to the test and tried to build Jasper's proof of concept (and therefore Wayland) on OSX. I didn't get very far. Wayland's configure.ac checks for SFD_CLOEXEC and TFD_CLOEXEC which implies that it uses signalfd() and timerfd(), not available on OSX. I guess the replacement would be something with kqueue though I really haven't the faintest idea what I'm talking about there. Wayland also wants clock_gettime() - not insurmountable to provide on OSX but afaik uses a different API, quick googling showed up this: http://stackoverflow.com/a/6725161/172999 PS. Funny thing that this is one of the top results for googling SFD_CLOEXEC, even without adding osx or wayland: http://stackoverflow.com/questions/27864027/sfd-cloexec-wayland Best, -- Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
Gah. I always get those backwards. I actually typed SCM_RIGHTS and then changed it to SCM_CREDENTIALS. I still don't understand why fd passing is called rights. On Tue, Jan 27, 2015 at 11:25 AM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: On 27/01/15 15:55, Jasper St. Pierre wrote: Wayland requires two features that would perhaps make it unportable: FD passing (SCM_CREDENTIALS), and shared memory (allocate a temporary files, ftruncate it, mmap it, unlink it and then send the fd across the wire). Everything else is just a simple Unix domain socket. Does OS X support those two features? I think you mean SCM_RIGHTS? SCM_RIGHTS is here's a message with an open fd attached. It's how D-Bus does fd-passing, so if D-Bus fd-passing works on your favourite platform, Wayland fd-passing should too. SCM_CREDENTIALS is here's a message with my uid, gid and pid[1] attached, the kernel will check that I haven't lied to you (also called SCM_CREDS on e.g. FreeBSD). Basically every Unix has either this or a syscall to query those things or both, but most Unixes also have their own unique spelling for the API, because standards are hard.[2] S [1] Strictly speaking the uid, gid and pid I had at the time I opened this socket [2] Except that FreeBSD, Dragonfly BSD and Hurd share SCM_CREDS, and several platforms (sadly not including Linux) share getpeereid(). For the gory details see libdbus source code. ___ 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
Re: RFC: GtkPreview library
On Tue, Jan 27, 2015 at 2:59 PM, Paul Davis p...@linuxaudiosystems.com wrote: I understand the appeal of using existing technology (i.e. Wayland) to accomplish something when it appears that it will make it much easier. But if GTK is still at least nominally cross-platform, then surely the place to start is a higher level abstraction of the transport system, and then later to bolt wayland onto that design under the hood, rather than starting with Wayland and then shrugging one's hands and saying do something like Wayland on other platforms? I don't see how anything I've said could be used to imply that GTK is, nominally or concretely, not cross-platform anymore. What is being discussed here is the possibility of using Wayland as the implementation to communicate privately between the preview plugin process and the main process, without a Wayland requirement for the session the processes live in. I'm arguing that as long as the Wayland libraries can be built on the platforms we care about and a suitable way of sharing a buffer exists, even if not extremely optimized, we can possibly get away without the abstraction you're talking about. Cosimo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Tue, Jan 27, 2015 at 10:55 AM, Jasper St. Pierre jstpie...@mecheye.net wrote: Wayland requires two features that would perhaps make it unportable: FD passing (SCM_CREDENTIALS), and shared memory (allocate a temporary files, ftruncate it, mmap it, unlink it and then send the fd across the wire). Everything else is just a simple Unix domain socket. Does OS X support those two features? It would appear so: fd passing: http://flylib.com/books/en/3.126.1.113/1/ shared memory is supported using the POSIX shared memory API, not the system V one. I have no idea if the combination of the two (shared memory, fd passing) together works. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On 27/01/15 15:55, Jasper St. Pierre wrote: Wayland requires two features that would perhaps make it unportable: FD passing (SCM_CREDENTIALS), and shared memory (allocate a temporary files, ftruncate it, mmap it, unlink it and then send the fd across the wire). Everything else is just a simple Unix domain socket. Does OS X support those two features? I think you mean SCM_RIGHTS? SCM_RIGHTS is here's a message with an open fd attached. It's how D-Bus does fd-passing, so if D-Bus fd-passing works on your favourite platform, Wayland fd-passing should too. SCM_CREDENTIALS is here's a message with my uid, gid and pid[1] attached, the kernel will check that I haven't lied to you (also called SCM_CREDS on e.g. FreeBSD). Basically every Unix has either this or a syscall to query those things or both, but most Unixes also have their own unique spelling for the API, because standards are hard.[2] S [1] Strictly speaking the uid, gid and pid I had at the time I opened this socket [2] Except that FreeBSD, Dragonfly BSD and Hurd share SCM_CREDS, and several platforms (sadly not including Linux) share getpeereid(). For the gory details see libdbus source code. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
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: RFC: GtkPreview library
Cosimo Cecchi cosi...@gnome.org writes: On Tue, Jan 20, 2015 at 10:24 AM, Carlos Garcia Campos carlo...@gnome.org wrote: One important thing is that preview providers should be out of process, since unfortunately it's very easy to make things crash with buggy files (which are very common). That could be done by every provider, but if we force that at a higher level it would be much better. That would also ensure that preview providers don't block the UI main thread, assuming the communication with the provider processes will be always asynchronous unconditionally. I ultimately agree, and I wrote a paragraph to that effect in my proposal... It's tricky to enforce this in the library, because it effectively means inventing a way for a process to draw into another process that doesn't look like libbonobo, and I didn't really want to go that path... 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. Cosimo -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Tue, Jan 20, 2015 at 10:24 AM, Carlos Garcia Campos carlo...@gnome.org wrote: One important thing is that preview providers should be out of process, since unfortunately it's very easy to make things crash with buggy files (which are very common). That could be done by every provider, but if we force that at a higher level it would be much better. That would also ensure that preview providers don't block the UI main thread, assuming the communication with the provider processes will be always asynchronous unconditionally. I ultimately agree, and I wrote a paragraph to that effect in my proposal... It's tricky to enforce this in the library, because it effectively means inventing a way for a process to draw into another process that doesn't look like libbonobo, and I didn't really want to go that path... Cosimo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Wed, 2015-01-21 at 10:16 -0500, Erick Pérez Castellanos wrote: Theoretically, previewing would be interesting whenever an app wants to provide a view of a content item - that could be useful for chat, social messaging, mail, or download/transfer applications. However, I haven't done any detailed work into how this would look. One question in this area is whether applications would Thinking on this I would add to the API: + `GtkWidget * gtk_preview_widget_new_from_data (gpointer)` in order to provide preview for not file-backed data. Or perhaps GtkWidget *gtk_preview_widget_new_from_stream (GInputStream *); which would more generally cover this via GMemoryInputStream? 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
Theoretically, previewing would be interesting whenever an app wants to provide a view of a content item - that could be useful for chat, social messaging, mail, or download/transfer applications. However, I haven't done any detailed work into how this would look. One question in this area is whether applications would Thinking on this I would add to the API: + `GtkWidget * gtk_preview_widget_new_from_data (gpointer)` in order to provide preview for not file-backed data. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Mon, Jan 19, 2015 at 9:24 PM, Cosimo Cecchi cosi...@gnome.org wrote: I moved this to the wiki: https://wiki.gnome.org/Projects/GTK%2B/Preview Hey, thanks for starting this discussion! I think the document would benefit from a section listing some expected use cases: where do we expect this preview to be used ? nautilus, filechooser - anything else ? Having that list will make it easier to judge whether the embedding api is suitable for all those cases. Also, it would be good to list some of the things that you expect to preview: documents, videos, music, images - anything else ? Having that list will help to get a sense for the interactivity that will be required from the preview. One thing we should keep in mind while designing this is that we hope to make application more isolated from the host system (and from each other) with https://wiki.gnome.org/Projects/SandboxedApps - what we come up here should have a chance of working in such an environment. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
Matthias Clasen matthias.cla...@gmail.com wrote: https://wiki.gnome.org/Projects/GTK%2B/Preview Hey, thanks for starting this discussion! Ditto! I think the document would benefit from a section listing some expected use cases: where do we expect this preview to be used ? nautilus, filechooser - anything else ? Having that list will make it easier to judge whether the embedding api is suitable for all those cases. From a design point of view, nautilus and the file chooser (or future incarnations of it) are the primary initial focus. Previewing could also be interesting for the system sharing dialogs [1] (as a way to check the identity of a content item, before it is shared). Theoretically, previewing would be interesting whenever an app wants to provide a view of a content item - that could be useful for chat, social messaging, mail, or download/transfer applications. However, I haven't done any detailed work into how this would look. One question in this area is whether applications would need to be able to change the UI controls for the preview. Also, it would be good to list some of the things that you expect to preview: documents, videos, music, images - anything else ? My understanding is that we would want to provide previews for as much common content as possible. Things like contacts or presentations could easily be added to the list. Having that list will help to get a sense for the interactivity that will be required from the preview. ... The UI present today in Sushi is a good reference point, and I would expect similar controls to be provided by the new library. I have promised UI designs for this. Allan [1] https://wiki.gnome.org/Design/OS/Sharing#Mockups ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
I moved this to the wiki: https://wiki.gnome.org/Projects/GTK%2B/Preview Cosimo On Mon, Jan 19, 2015 at 11:46 AM, Cosimo Cecchi cosi...@gnome.org wrote: Hi all, We talked in the past with other GTK developers about the possibility of integrating a preview library, allowing GTK applications to easily get a widget that represents the preview of a file. This would currently be used by GtkFileChooser, or a future evolution of the current class, but also by file managers, possibly mail clients, etc. I wrote a draft proposal for the architecture of the library. The master copy lives for now in a Google Doc free for comments here [1], but I will also paste it here below. I will move this to the GNOME Wiki once I have received the initial feedback. Comments welcome! [1] https://docs.google.com/document/d/1kaHZtOSUMgm6qB3FLzGNuYJIgJVAEnWMvBPDvlzNeNY/edit?usp=sharing Overview The primary goal of the feature is to be able to create an interactive preview of a given file, in the form of a GtkWidget, from a generic interface that is extensible to different mime types. “Interactive” means that a set of actions can be performed on the preview itself. For instance, when previewing a PDF document it is desirable to switch to previous/next page; when previewing a video or a song it’s desirable to play/pause, etc. The feature lives ideally inside GTK. Architecture The requirement of supporting the widest variety of formats possible in the library calls for an extensible system, where a set of modules are registered as preview “providers”, each handling a list of mime types. This also avoids the need for GTK to directly link to all the dependencies directly, but some providers could be distributed as part of GTK (e.g. a GdkPixbuf-based one for images). The most straightforward way to implement this is through an extension point with a well-defined interface that can be implemented by shared objects modules installed by the different libraries or applications that want to extend the functionality. It should also be possible for implementations to use a DBus interface to transfer the data. This makes it possible for an actual application to be spawned in response to a preview request, and send the data over the wire, which will be not as expensive as it is now when kdbus enters the picture. Doing this in a generic “dbus implementation” module might be hard though, because it’s not possible to export a GtkWidget over DBus, and is outside the scope of this proposal. I imagine e.g. a Totem-provided viewer to be able to stream the video to the library, but the Totem module would still know how to draw back the data it receives from the Totem process. Registration Modules can register themselves by installing a .so file into a known location. A design where a textual descriptor is also installed, providing metadata about the module capabilities is possible; otherwise there could be methods on the module interface to define that without the need of an extra file. An advantage of the descriptor file is that it makes it easy to e.g. load modules in priority order (by just sorting the descriptors alphabetically), giving the library a mechanism to predictably resolve conflicts in case two modules claim to handle the same mime type. Interface We need two separate interfaces; one used by the client of the library and one between the library and the modules. Client GtkWidget * gtk_preview_widget_new (void) GtkWidget * gtk_preview_widget_new_from_file (GFile *) voidgtk_preview_widget_set_file (GtkPreviewWidget *, GFile *) GFile * gtk_preview_widget_get_file (GtkPreviewWidget *) These are all pretty obvious; to create a preview widget you need a file. GtkPreviewContext * gtk_preview_widget_get_context (GtkPreviewWidget *) Everything that relates to the widget but is not part of the widget itself is split into a GtkPreviewContext object. This is effectively the entry point for all the actions-related operations. GtkPreviewContext implements GActionGroup GIcon * gtk_preview_context_get_icon (GtkPreviewContext *, gchar * action) gchar * gtk_preview_context_get_label (GtkPreviewContext *, gchar * action) gchar * gtk_preview_context_get_description (GtkPreviewContext *, gchar * action) By implementing GActionGroup, GtkPreviewContext can be used by the client to enumerate actions and create UI elements with them. There are no assumptions on where the actions come from; for instance, GtkPreviewContext could add by default an “open” action that is handled in a generic way entirely outside of the module. Similarly, applications could add their own actions on top of the stock. Higher level objects can be built on top of these two simple classes. For instance, a GtkPreviewDialog could be created that displays the preview widget in a GtkScrolledWindow with actions in a GtkActionBar below it. Module GLib and GIO offer low-level and
RFC: GtkPreview library
Hi all, We talked in the past with other GTK developers about the possibility of integrating a preview library, allowing GTK applications to easily get a widget that represents the preview of a file. This would currently be used by GtkFileChooser, or a future evolution of the current class, but also by file managers, possibly mail clients, etc. I wrote a draft proposal for the architecture of the library. The master copy lives for now in a Google Doc free for comments here [1], but I will also paste it here below. I will move this to the GNOME Wiki once I have received the initial feedback. Comments welcome! [1] https://docs.google.com/document/d/1kaHZtOSUMgm6qB3FLzGNuYJIgJVAEnWMvBPDvlzNeNY/edit?usp=sharing Overview The primary goal of the feature is to be able to create an interactive preview of a given file, in the form of a GtkWidget, from a generic interface that is extensible to different mime types. “Interactive” means that a set of actions can be performed on the preview itself. For instance, when previewing a PDF document it is desirable to switch to previous/next page; when previewing a video or a song it’s desirable to play/pause, etc. The feature lives ideally inside GTK. Architecture The requirement of supporting the widest variety of formats possible in the library calls for an extensible system, where a set of modules are registered as preview “providers”, each handling a list of mime types. This also avoids the need for GTK to directly link to all the dependencies directly, but some providers could be distributed as part of GTK (e.g. a GdkPixbuf-based one for images). The most straightforward way to implement this is through an extension point with a well-defined interface that can be implemented by shared objects modules installed by the different libraries or applications that want to extend the functionality. It should also be possible for implementations to use a DBus interface to transfer the data. This makes it possible for an actual application to be spawned in response to a preview request, and send the data over the wire, which will be not as expensive as it is now when kdbus enters the picture. Doing this in a generic “dbus implementation” module might be hard though, because it’s not possible to export a GtkWidget over DBus, and is outside the scope of this proposal. I imagine e.g. a Totem-provided viewer to be able to stream the video to the library, but the Totem module would still know how to draw back the data it receives from the Totem process. Registration Modules can register themselves by installing a .so file into a known location. A design where a textual descriptor is also installed, providing metadata about the module capabilities is possible; otherwise there could be methods on the module interface to define that without the need of an extra file. An advantage of the descriptor file is that it makes it easy to e.g. load modules in priority order (by just sorting the descriptors alphabetically), giving the library a mechanism to predictably resolve conflicts in case two modules claim to handle the same mime type. Interface We need two separate interfaces; one used by the client of the library and one between the library and the modules. Client GtkWidget * gtk_preview_widget_new (void) GtkWidget * gtk_preview_widget_new_from_file (GFile *) voidgtk_preview_widget_set_file (GtkPreviewWidget *, GFile *) GFile * gtk_preview_widget_get_file (GtkPreviewWidget *) These are all pretty obvious; to create a preview widget you need a file. GtkPreviewContext * gtk_preview_widget_get_context (GtkPreviewWidget *) Everything that relates to the widget but is not part of the widget itself is split into a GtkPreviewContext object. This is effectively the entry point for all the actions-related operations. GtkPreviewContext implements GActionGroup GIcon * gtk_preview_context_get_icon (GtkPreviewContext *, gchar * action) gchar * gtk_preview_context_get_label (GtkPreviewContext *, gchar * action) gchar * gtk_preview_context_get_description (GtkPreviewContext *, gchar * action) By implementing GActionGroup, GtkPreviewContext can be used by the client to enumerate actions and create UI elements with them. There are no assumptions on where the actions come from; for instance, GtkPreviewContext could add by default an “open” action that is handled in a generic way entirely outside of the module. Similarly, applications could add their own actions on top of the stock. Higher level objects can be built on top of these two simple classes. For instance, a GtkPreviewDialog could be created that displays the preview widget in a GtkScrolledWindow with actions in a GtkActionBar below it. Module GLib and GIO offer low-level and higher-level APIs to setup a library extension point. Assuming that part of the problem is solved, let’s define GtkPreviewModule as the interface that all modules need to implement. GtkPreviewModule * gtk_preview_get_module_for_file (GFile *)
