Plans for portals that integrate widgets inside the app window?

[Bastien Nocera]

On Wed, 2016-06-22 at 16:54 +0200, Sébastien Wilmet wrote:
> On Wed, Jun 22, 2016 at 03:14:37PM +0200, Alexander Larsson wrote:
> > On ons, 2016-06-22 at 12:36 +0200, Sébastien Wilmet wrote:
> > > Hi again,
> > > 
> > > From what I know, the first portals that will be implemented
> > > (e.g.
> > > the
> > > file chooser portal) will open another window, that runs in
> > > another
> > > process outside the sandbox.
> > > 
> > > But are there plans to have portals that integrate widgets
> > > *inside*
> > > the
> > > app window?
> > > 
> > > The example that I have in mind is an integrated file browser in
> > > a
> > > side
> > > panel of a text editor or IDE. Are there plans to implement such
> > > feature
> > > securily? so that the app can access the filename and content of
> > > only
> > > the files that the user has chosen to open.
> > > 
> > > It would probably need a compositor to integrate the drawing of
> > > the
> > > app
> > > and the drawing of the integrated widget(s). With a D-Bus API
> > > like
> > > for
> > > the "external" file chooser portal.
> > > 
> > > I know an implementation for that is not going to happen anytime
> > > soon,
> > > one thing at a time, but I'm curious to know the overall plans.
> > 
> > At some point i spent time making recursive wayland compositors for
> > embedding widgets working:
> > 
> >   https://github.com/alexlarsson/wakefield
> > 
> > That said, i'm not sure this is useful in the larger scope of
> > portals.
> > There is just so much complexity in a generalized plugin scheme
> > like
> > that. Themes? Keyboard shortcuts? Size negotiation? Toolkit
> > behaviour?
> 
> An integrated file browser is however very useful. An IDE has other
> features that require access to the filesystem, at least the
> directory
> of a project. So we'll not be able to secure those apps completely.
> 
> Maybe the portals will fit only some of the most common apps. When an
> application wants to do something a bit differently, have a different
> UX, to go off the beaten track, this won't be possible.
> 
> The --filesystem parameter of flatpak-build-finish already supports
> middle grounds between total access to the user's home (including
> private keys), and having the file chooser portal for sole access
> point.
> So for an IDE, the access could be restricted to a certain directory
> containing the programming projects. But it's less convenient for the
> user: the user is restricted with how to organize directories, or
> needs
> to go through a desktop UI to configure a list of directories. So,
> security can get in the way for the user, and also for the developer.

I'd expect the IDE to have complete access to a directory hierarchy,
rather than ask about each and every file. There's already a portal
being worked on that would allow selecting a directory. I'd expect the
app to have free reign over that directory, such as a source tree and
then be able to present its own browsing interface.