This site has been retired. For up to date information, see handbook.gnome.org or gitlab.gnome.org.


[Home] [TitleIndex] [WordIndex] 

1. Day 2

1.1. Portals

Alex described the current portal prototype: 

app ---> org.freedesktop.portal.desktop --looks at--> /usr/share/portal/gtk.portal
                 |
         forwarded with verified app_id
                 |
                 +--> org.freedesktop.portal.desktop.gtk --shows --> file chooser, app chooser...

There was some differences of opinion on whether application should implement service APIs directly, e.g. cheese a video capture API. An alternative picture was drawn: 

app ---> portal thing
           [files]           <----> file chooser
           [image capture]   <----> app chooser
           [share]                  (could be 1-time-only)                 
                   < -+ 
                      |
                  DATA flows here
                      |
                      +---- > cheese
                             [image capture]

We discussed the pros and cons of having a "always use this app" setting, but it is probably necessary. There will need to be a control-center panel to reset these associations.

We also want to have prefix matching on http:// uris to redirect to specific applications, e.g. for facebook. This needs more research (there may be RFCs around this, should talk to webkit people.

1.2. Sharing portal

Desktop files can declare they support an interface, with parameters: 

Implements: org.freedesktop.Share
...

[org.freedesktop.Share]
Types: images, text,... (mimetypes)

Some side discussion on application help. We have a help:// uri, so we could treat this as a special case of uri opening if the help files are exported from the app. But we don't really want to do that.

We briefly discussed how image handler service providers are done on OS X.

1.3. URL handling

Separate cases: http(s) vs opening a different app. Custom uri schemes: steam:, irc:, magnet:, help: should always get a dialog to choose the app.

1.4. Printing

We just want to do a simple 'print this pdf file' portal that just opens a print dialog on the outside.

1.5. Device access

cdrom, dvd, joystick, etc. Need to treat them case-by-case.

Totem case: need full dvd access. Problem is that we can only set up device access at startup time, since we want to drop privileges. VLC also wants full optical device access, which is considered to be a showstopper for publishing VLC as a Flatpak.

joystick: one idea would be to have the compositor forward events in a somewhat transparent way. This has the advantage that we can subject these events to focus. But there's an open question if we need any custom ioctls. Need to talk to domain experts: sdl and libinput maintainers.

Richard wants to have usb access to update firmware. We tentatively agreed to just have a way to bind mount /dev in the metadata, for cases like this. Full device access is not quite as scary as it sounds since permissions still limit what is accessible.

1.6. Some background on policy

flatpak is basically policy-free, all the policy decisions (like permission overrides, or whether to automatically install dependencies, etc), are done in UI frontends like gnome-software.

One idea that came up is that we should have a "hello world" test app that is explicitly only available as flatpak, as an easy way to test Flatpak integration in e.g. gnome-software.

1.7. Eclipse meet-and-greet

Around noon, some of the eclipse guys came by to visit tell us a little bit about some of their issues with porting swt to gtk3. We agreed to have an eclipse session on Wednesday, when Eric is back.

1.8. Accessibility

We briefly discussed how to make accessibility work. Conclusion: give filtered access to a11y bus, don't let applications own any name, allow them to respond to calls and send signals. Should work, otherwise, look closer.

1.9. Proxy, network connectivity status

We'll have simple D-Bus apis that can be implemented in the desktop portal, and use the libproxy/GNetworkMonitor.

1.10. Keyring

Not clear what do to about kernel keyring, need to talk to domain experts. We believe that libsecret should use the kernel keyring underneath.

1.11. Contacts

We could have a very simplified vcard-based API that works as a frontend for eds/akonadi, with a way to get the current contacts and an update signal.

1.12. Developer documentation

Discussion happened, but I neglected to take notes.

1.13. Responsive design

Philip showed a number of examples where Endless has to use custom containers to achieve responsive designs, like disappearing logos, rearranged children in grid layouts, etc.

We discussed various aspects of implementing responsive designs that don't work in gtk. Media queries are problematic, since our 'viewport' (ie the toplevel window) changes its size depending on the content. Conditionally hiding content in containers should be done with child-visibility. The side-effect of this is that css will not change (you can't e.g. have rounded corners appear on the last visible child). Animated hiding of widgets needs to be done with something other than gtk_widget_hide, it should be instantaneous. We need to fix GtkPopover, GtkInfoBar and other places to add custom api, and implement it by fading out, followed by hide at the end.

Philip's notes / proposals: /ResponsiveDesignNotes

1.14. Search path problem

Towards the end of the afternoon, we spent a long time discussing the "search path problem" of how to make flatpak exports visible to the rest of the system. Currently, we rely on XDG_DATA_DIRS to be set somewhere during session setup, which is problematic in several ways (not the least on is just the fact that it is an environment variable). Options discussed included /opt, using a common directory in /var/lib for all app packaging frameworks, or using .d-style directories.

Another idea (and maybe the most promising one) is to create a bunch of symlinks in /run/user/$uid at session setup, and point at that.

Places that need patches for this:

2024-10-23 11:10