Plans for portals that integrate widgets inside the app window?

Bastien Nocera hadess at hadess.net
Thu Jun 23 18:18:33 UTC 2016


On Wed, 2016-06-22 at 15:14 +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?

Also, using system provided dialogues means that the user knows when a
password field is provided by the system, after making a request to get
something from "outside" the application.

An "embedded portal" means that the user would have no way to know
whether a password popup in one of the embedded portals came from the
app itself, or the portal. This could mean a rogue application with
network access sending credentials to the internet at large without the
user being the wiser.

This is actually also a problem with GTK+-built portals right now, and
I've mentioned to Matthias and Alex that the compositor should try to
differentiate this type of system popup implemented in GTK+ compared to
the same version of "in the sandbox" popup.

Cheers



More information about the xdg-app mailing list