Menu is not exported (global menu)

[kupiqu]

the menu is located within the application window even though menu's in my system are configured to appear in a top bar

[TingPing]

I assume you use KDE, do you know how it configures this?

Or is Qt supposed to always export its menu?

[kupiqu]

I assume you use KDE

Yes, KDE user here.

do you know how it configures this? Or is Qt supposed to always export its menu?

AFAIK, Qt apps are natively supported

[kupiqu]

I don't have any but will test and report...

[kupiqu]

I tried and it doesn't seem to work, so it doesn't seem sth specific of the Octave flatpak package. I'll try to investigate where the problem is, if in flatpak missing some libs or if in KDE not supporting flatpak apps.

I think we can close this issue...

[kupiqu]

It will be fixed once this is added to flathub:

https://cgit.kde.org/flatpak-kde-runtime.git/commit/?id=f3cdd21232204f5c0518edd4759b6a73d7def019

[kupiqu]

The menu of the file editor appears embedded in the editor frame, hence it is not exported to the global menu. Shouldn't Octave have just one application menu, which would adapt according to the frame under focus?

[kupiqu]

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'... )

[kupiqu]

Doing that for each application seems cumbersome. Maybe some other solution can be found.

I hope so!

In the meantime you can run flatpak override --talk-name=com.canonical.AppMenu.Registrar org.octave.Octave

I get an error: permission denied

[kupiqu]

I don't think running with sudo is a conveniet temporary workaround, because the globalmenu doesn't work for applications run by a different user, root included (the dbus process it is based on, is user specific).
Also running end-user applications as root is not convenient as files etc get owned by root in the user filesystem, which frequently ends up being troublesome.
I guess we need to wait for a final, more convenient, solution.

[kupiqu]

Wait, this doesn't mean running Octave as sudo? I guess I missed that part...

[kupiqu]

Well, I just tried and:

• it opens octave in the terminal, not as a desktop app (I guess this can be solved somehow)

• it runs octave as root:

>>system('whoami')
root

[kupiqu]

Unfortunately, as a result .octave_hist and .selected_editor (and I bet other files/folders in my $HOME) are now owned by root. Will have to change those manually, to avoid backup errors, and denied modifications when running octave on my own user.

[kupiqu]

Well, that command (sudo flatpak run --talk-name=com.canonical.AppMenu.Registrar org.octave.Octave) did run octave as root in my system...

[mtmiller]

The command should be flatpak override --talk-name=com.canonical.AppMenu.Registrar org.octave.Octave. To be sure that we're on the same page, did you try that as well earlier, or were you always using flatpak run? The flatpak override command is the one that I think @Alexander-Wilms is saying should be run with sudo, and only needs to be run once.

[kupiqu]

Oops! Ok, I got it know. How silly: I didn't try at first when @Alexander-Wilms mentioned about override and then I misunderstood what he meant about the run command... So I ended up doing what I wanted to avoid in the first place. Anyways, it was quite easy to recover my ownership over all rooted files using find.

And indeed, using sudo flatpak override --talk-name=com.canonical.AppMenu.Registrar org.octave.Octave recovered the globalmenu, thank you!

But I'm curious, what is it exactly that that command modifies?

[mtmiller]

But I'm curious, what is it exactly that that command modifies?

It adds a permission to allow the application to talk to the com.canonical.AppMenu.Registrar D-Bus endpoint on the session bus. This is presumably how applications register their menus with the Ubuntu global application menu. This is essentially like poking holes in a firewall, if you think of D-Bus names as analogous to well-known TCP port numbers.

Doing that for each application seems cumbersome. Maybe some other solution can be found.

I agree with this, requiring each application to declare that they may talk to this or that desktop integration feature seems like an unnecessary burden.

[kupiqu]

I see. Thanks for the explanation!

[kupiqu]

Wondering... is there a way to revert this:

sudo flatpak override --talk-name=com.canonical.AppMenu.Registrar org.octave.Octave

I will stay with flatpak 0.11.8.3 for now until flatpak/flatpak#2012 is closed

[mtmiller]

is there a way to revert this

You can delete the override file. That command simply creates or adds to an override file, should be under /var/lib/flatpak/overrides if you are installing globally as root.

[kupiqu]

awesome, thank you!

[kupiqu]

Should we close this issue? I guess this can be considered an upstream issue at this point...

[kupiqu]

Could you please reopen this issue given the final decision upstream (flatpak/flatpak#2012)?

Fixing this in the flatpak package will just require adding

"--filesystem=xdg-config/kdeglobals:ro",
"--talk-name=com.canonical.AppMenu.Registrar",

to the "finish-args" section of manifest.json.

The first line is to respect the look and feel of the system (i.e. color scheme), and the second is to export the application menu. KDE apps have done this already (https://phabricator.kde.org/D15958)

[kupiqu]

I've added the required permissions.

Excellent, thank you

[kupiqu]

Things move fast. It seems applications can again rely on runtime specifications:

EDIT: Sorry, I meant flatpak/flatpak#2230

[mtmiller]

So with flatpak 1.2 or 2.0 or whatever, we can safely revert ac1ae28?

[kupiqu]

Well, it will need those changes in flatpak (maybe flatpak 1.0.4; or 1.1 or who knows, not sure how these things are added to the flatpak release schedule) as well as reverting the changes in the kde runtime.

I will try to be aware of this and will let you know...

[kupiqu]

Released in flatpak (see below). Will let you know when it is reverted in kde runtime...

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.

[kupiqu]

Will let you know when it is reverted in kde runtime...

As far as I can see, these lines were never removed from the kde runtime:

"--filesystem=xdg-config/kdeglobals:ro",
"--talk-name=com.canonical.AppMenu.Registrar",

However, the globalmenu is gone if I remove the overrides, which I don't quite understand.

[kupiqu]

However, the globalmenu is gone if I remove the overrides, which I don't quite understand.

@mtmiller @Alexander-Wilms It seems all what is needed is to rebuild the application with latest flatpak-builder.

[kupiqu]

@mtmiller @Alexander-Wilms It seems all what is needed is to rebuild the application with latest flatpak-builder

@Alexander-Wilms would you consider rebuilding octave so we could check this out?

[kupiqu]

thanks!

Edit: it works as expected.

[mtmiller]

The manifest in use still adds the permissions manually. Should this be reverted now?

[kupiqu]

I think so