Bug 397625 - No global menu from flatpak KDE applications
Summary: No global menu from flatpak KDE applications
Status: RESOLVED FIXED
Alias: None
Product: flatpak-platform-plugin
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Neon Linux
: NOR normal
Target Milestone: ---
Assignee: Jan Grulich
URL: https://github.com/flatpak/flatpak/is...
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-19 14:35 UTC by avlas
Modified: 2018-10-19 16:48 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description avlas 2018-08-19 14:35:32 UTC
It used to work after commit (https://commits.kde.org/flatpak-kde-runtime/f3cdd21232204f5c0518edd4759b6a73d7def019), but not anynmore.
Comment 1 Nate Graham 2018-08-21 20:44:06 UTC
Which apps? All apps? Some apps? Do any of them work?
Comment 2 avlas 2018-08-21 20:48:46 UTC
I tried okular, kdenlive and octave (even though octave is not a kde application, it relies on kde and worked fine before). So, I'm not 100% sure about all applications that I didn't test, but it seems like globalmenu does not work anymore for flatpak kde(-dependent) apps...
Comment 3 Nate Graham 2018-08-21 20:53:06 UTC
Thanks for the information!
Comment 4 avlas 2018-08-24 19:10:47 UTC
Mmm, it may be a bug in flatpak as globalmenu works for flatpak 0.11.7 but not for flatpak 1.0.0.

Reported in https://github.com/flatpak/flatpak/issues/2012
Comment 5 Nate Graham 2018-08-24 19:19:48 UTC
Thanks, let's see what shakes out there. If need be, we can re-open this.
Comment 6 avlas 2018-08-24 19:20:47 UTC
Sounds good
Comment 7 avlas 2018-08-27 14:28:53 UTC
(In reply to Nate Graham from comment #5)
> Thanks, let's see what shakes out there. If need be, we can re-open this.

Reopening this issue. Please see:
flatpak/flatpak#2012

In short, Flatpak stopped inheriting permission requests from the runtime. The apps need to list the permissions themselves.

Perhaps adding "--talk-name=com.canonical.AppMenu.Registrar", to "finish-args" and rebuilding will be enough (not sure about '--filesytem'... )
Comment 8 avlas 2018-08-27 14:30:01 UTC
> Please see: flatpak/flatpak#2012


I meant https://github.com/flatpak/flatpak/issues/2012
Comment 9 Nate Graham 2018-08-27 19:15:58 UTC
Thanks. I'll see if I can engage with upstream on the matter too.
Comment 10 avlas 2018-08-27 19:25:46 UTC
(In reply to Nate Graham from comment #9)
> Thanks. I'll see if I can engage with upstream on the matter too.

Great, thank you!
Comment 11 avlas 2018-10-02 19:51:07 UTC
(In reply to Nate Graham from comment #9)
> Thanks. I'll see if I can engage with upstream on the matter too.

Any update?
Comment 12 Nate Graham 2018-10-02 19:56:01 UTC
Sadly not.
Comment 13 Aleix Pol 2018-10-03 21:59:23 UTC
Git commit 92e9bd4843aba0e005a2dfb7b57090d75b4bf1ce by Aleix Pol.
Committed on 03/10/2018 at 21:57.
Pushed by apol into branch 'master'.

Add missing appmenu dbus path

M  +1    -0    org.kde.Sdk.json

https://commits.kde.org/flatpak-kde-runtime/92e9bd4843aba0e005a2dfb7b57090d75b4bf1ce
Comment 14 avlas 2018-10-04 00:21:49 UTC
Aleix, this is currently an upstream issue (https://github.com/flatpak/flatpak/issues/2012). In words of Alex Larsson, "We stopped inheriting permission requests from the runtime. The apps need to list the permissions themselves", so your commit, being part of the runtime, is not able to fix the issue.

I guess the two options right now are either to (try to) convince upstream developers to revert that policy upstream whenever possible, or to start adding all these arguments to the applications instead of to the runtimes... Another thing that gets affected, in addition to the global menu, is the look and feel, so applications load the breeze color theme, even though the native system uses a different color theme.
Comment 15 Aleix Pol 2018-10-04 11:20:34 UTC
Then there's nothing we can do on our end.
Comment 16 avlas 2018-10-04 11:35:28 UTC
(In reply to Aleix Pol from comment #15)
> Then there's nothing we can do on our end.

Well, if this finally doesn't get reverted upstream, then all KDE flatpak applications need to do this, so I guess this is still an open KDE issue anyways.

I tried to get an explicit answer to the question if this is going to be reverted or not upstream but so far the question is being ignored...
Comment 17 avlas 2018-10-04 20:15:35 UTC
If somebody is interested exporting the menu can be fixed on the fly with:

sudo flatpak override --talk-name=com.canonical.AppMenu.Registrar flatpak_application_name

sudo flatpak override --talk-name=com.canonical.AppMenu.Registrar.* flatpak_aplication_name

And for the look and feel:

sudo flatpak override --filesystem=xdg-config/kdeglobals:ro flatpak_aplication_name
Comment 18 Jan Grulich 2018-10-05 07:44:35 UTC
I updated all KDE apps, see https://phabricator.kde.org/D15958. I'll also go through flathub and try to update all applications there as well.
Comment 19 avlas 2018-10-05 10:32:01 UTC
(In reply to Jan Grulich from comment #18)
> I updated all KDE apps, see https://phabricator.kde.org/D15958. I'll also go
> through flathub and try to update all applications there as well.

Jan, do you know the way to make flatpak apps to follow the default system applications from KDE settings? Thanks in advance
Comment 20 avlas 2018-10-07 12:54:26 UTC
(In reply to avlas from comment #19)

> Jan, do you know the way to make flatpak apps to follow the default system
> applications from KDE settings? Thanks in advance

Actually I saw it sort of follows it, but not quite properly, at least for the browser application. My setting is to use the browser based on URL type, but this is not followed. Please let me know if it's better if I fill another bug for this...
Comment 21 Aleix Pol 2018-10-10 17:16:46 UTC
This has been properly solved in flatpak upstream.
Comment 22 Aleix Pol 2018-10-10 17:16:55 UTC
https://github.com/flatpak/flatpak/pull/2230
Comment 23 avlas 2018-10-10 17:22:13 UTC
(In reply to Aleix Pol from comment #21)
> This has been properly solved in flatpak upstream.

Nice
Comment 24 avlas 2018-10-12 16:55:14 UTC
Inheritance of permissions is back in flatpak 1.0.4:

https://github.com/flatpak/flatpak/releases

Changes in 1.0.4

- Flatpak 0.99.1 removed the inheritance of permissions from the runtime due
to concerns with dynamic app permissions. Due to popular requests, this
version re-introduces such inheritance, but does it instead at build time.
This solved the issues with dynamic permissions while still allowing runtimes
to have default permissions. Apps can disable this by passing
--no-inherit-permissions to build-finish.

Are there plans to revert this commit (https://phabricator.kde.org/D15958) adding those changes back to the kde flatpak runtime?
Comment 25 avlas 2018-10-12 18:44:07 UTC
Mmm, actually these changes (kdeglobals and registrar) were never removed from the kde runtime, were they?
Comment 26 Aleix Pol 2018-10-15 00:44:32 UTC
No, they're still in, we do need the applications to rebuild with latest flatpak-builder though.
Comment 27 avlas 2018-10-19 16:48:12 UTC
(In reply to Aleix Pol from comment #26)
> No, they're still in, we do need the applications to rebuild with latest
> flatpak-builder though.

Thank you