Manual review required for snap thonny-ide

store-requests
1

Hey snapcraft community, i recently released a snap thonny, i need it to use xdg-portal so i specified dbus slot, the official flatpak build also uses gtk portal to work and integrate nicely, i want to keep the snap app in line with the flatpak one, so please consider this request…

snap name -thonny-ide

2

The portals don’t need a dbus slot, you can use the desktop interface plug which is auto-connected.

3

can you please explain in detail…

4

To make use of xdg-desktop-portals, you just need:

plugs:
  desktop

E.G

name: test-snap
base: core22
version: '1'
summary: A summary
description: |
  A description
confinement: strict

parts:
  test-snap:
    plugin: cmake
    source: myrepo.git

apps:
  test-snap
  command: bin/test-app
  plugs:
    - desktop
1 Like
5

dont delete it , i deleted accidentally thanks for replying

6

hey james its already present in my yaml

7

My yaml

8

It didnt work with the desktop so i used dbus

9

You’ve set GTK_USE_PORTAL: 1 (which the gnome extension also does implicitly) and added the desktop plug (also implicit with the extension). Beyond looking for application specific environmental variables or other config, I’d question whether the IDE actually has portals support. You should try removing the DBus slot and running snappy-debug (sudo snap install snappy-debug) whilst trying to use the app. If the debug tool doesn’t complain about DBus calls relating to portals, it’s because they’re not being used or the sandbox isn’t interfering (because desktop is set).

The flatpak might not be using them either; but might work differently because the Flatpak sandbox operates differently.

Granting access to the portals won’t make the app use them if it doesn’t know how to.

If granting the dbus slot does change the behaviour, I’d be concerned about what’s going on under the hood.

10

So the issue here is that all snaps that slot a dbus interface are blocked by the automated review process until a store reviewer can assess that the snap is not trying to impersonate some well-known dbus name (e.g. imagine if a snap slotted the Keyring service name, it could then potentially snoop on your passphrases etc) - I have now just granted the dbus name for revision 7 and the snap has passed automated review.

11

I think revision 18 is stuck not rev 7 ??

12

Oh apologies - I thought this was about thonny-canary - will go take a look at thonny-ide :slight_smile:

1 Like
13

canary is private and experimental

14

Thanks i pushed rev 18 to stable, :smiling_face_with_three_hearts:

15

Snappy debug gives nothing…

16

Indeed - snapd will happily allow an installed snap to use a given dbus name - so we do this check on the store side when the snap is uploaded.

17

I will push a new one without dbus and do snappy debug again… I think Flatpak somehow make each app use gtk-portals ?? somehow ??

18

Personally I’m not convinced the Flatpak would be using the Desktop Portals either. Thonny seems to be built on TKInter, which I’d assume doesn’t have have Portal support.

Is there some specific behavioural differences in the Flatpak vs your Snap that makes you think the Flatpak has portals support where the snap doesn’t?

I’m imagining you might be looking at a file picker/folder picker UI and seeing behavioural differences there relating to the sandbox each platform has, but personally I’m suspecting that the differences don’t involve one using the portals and the other not using portals, but more the Snap sandbox has tighter permissions and changes the default $HOME & etc.

19

Stiil nothing snappy debug is empty even without dbus

20

yes the flatpak one uses a much better xdg portal file picker and saver but the snap one uses a bit ugly and buggy to open and save which made me think to use xdg portal for snap one