On tor, 2014-01-02 at 15:22 +0000, Michael Ikey Doherty wrote: > Hello, > > My name is Michael Ikey Doherty, though some of you will know me as Ikey > Doherty. A quick introduction: I'm a software engineer at Intel and have > worked with the GNOME stack for a few years. I've mostly been known for > distribution development, </endintro>
I'm guessing you're aware of the linux apps project: https://docs.google.com/document/d/1QTgxakyUVFMkvr-xFY2Xg9lYjcJLd6kPTl3Ij5_dL7Q/edit As part of that we've talked quite a bit about "portals". Essentially, the idea is that by default, a sandboxed applications gets its own kdbus sub-session-bus, which is forbidden to talk to any other peer on the session bus (this can be opened up by fine grained permissions of course). Except there would be one service that you're allowed to talk to, the Portal. The portal is a meant to be a pretty minimal dbus API that essentially acts as a form of proxy to other services on the bus, in much the same fashion of how well known dbus names act as a proxy. For example, on the normal dbus you can message a well know name org.gnome.Foobar and assume that it will implement a known interface for Foobars (as defined by some external entity). You don't have to know who implements the foobar, and if its not running it will be activated. In the same way you can send requests to the portal manager targeting a named portal. The portal manager will activate the right target and send the message there, and the target will have to implement the defined interface for that particular portal name. The main difference is that portal interfaces are limited in certain ways to make them "safe" for any app to use. First of all, all the operations are meant to be interactive, i.e. they never return any data to the app unless the user did something, and the user is always able to cancel the operation. And I don't mean a "the app wants to do foo, allow yes/no" dialog, but an actual interactive operation. Let me give some example portals: Share portal: The user selects some text or image in an app and clicks the "share" button, which triggers a share portal call. This will typically show a list of possible ways to share things, or if there is only one way it will be launched. But the launched thing is meant to be e.g. a twitter compose dialog with the text inserted ready to be tweeted, rather than something that just immediately tweets the text. This way an app can't misuse this to e.g. tweet as you without you knowing it. In this way every portal action is interactive, cancellable and will feel natural when invoked by the user (but weird when the app does so unexpectedly). Get an image portal: Allows you to insert an image into an app. When you activate this you get a dialog that allows you to select an image via e.g. picking a file or using a webcam. Select a file: Opens up a file selector, and if a file is selected streams the contents to the app so that it can read it even if it has no access to $home otherwise. Select a contact: Contact chooser UI that lets you chose from your addressbook and return (only) the selected result to the app, without the app having access to the addressbook. The portal manager by itself is not terribly complex, but defining all the dbus interfaces for possible portals (and adding gnome implementations for some standard ones) is a lot of work. However, this is work that can be done incrementally. All you need is to define a well known portal name and some dbus introspection xml describing the interface. Then any app can use the introspection xml either at runtime, or at compile time using gdbus-codegen to create nice GObject wrappers for it. The disucssion about portals and the linux apps project is kind of dormant atm as the interested parties are busy with other stuff. But things are progressing at some fronts at least, like the kdbus work which will be great for this. _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
