change CMAKE_BUILD_TYPE to RelWithDebInfo and remove CMAKE_INSTALL_LIBDIR=lib

I'll do the change of krita if nobody beats me to it.

When the KDE nightly build is switched to this manifest, it would be good, if a hint was added to krita's download page, with a link to the repo file:

I changed the manifest to be usable for nightly builds and removed openjpeg.

Yes... Sometimes a feature is not worth the fight against !@#$%-idity...

In D9882#191275, @rempt wrote:

I have no opinion in the appstream file question, but I'm fine with having these definitions in our repo, on the same basis as the snap definitions: I cannot maintain them.

I have no opinion in the appstream file question, but I'm fine with having these definitions in our repo, on the same basis as the snap definitions: I cannot maintain them.

In D9882#191052, @ngraham wrote:

Would you consider adding <release> information to your AppStream metadata file here, so you don't need to patch it in on Flathub?

It's already there on master and will be dropped when 4.0 is released.

Would you consider adding <release> information to your AppStream metadata file here, so you don't need to patch it in on Flathub?

And in case you are not familiar with the current state of flatpak: when the user has a recent version of Plasma Discover or GNOME Software installed, it's of course enough to click the the bundle to install it.

fixed name of manifest in instructions

By the way: The resulting bundle includes python scripting support and should contain support for audio in animations (I had no idea how to test that).

At the moment we have builds of the runtime, as it's being built in flathub. Not for applications so far.

Should be solved now. We don't use platform plugin anymore, only platform theme.

Should be solved now. We don't use platform plugin anymore, only platform theme.

Should be solved now. We don't use platform plugin anymore, only platform theme.

Very much so. In fact Minitube is now on Flathub.

We included phonon-gstreamer. @nickrichards are your issues solved with the new version of the platform?

Correct, we found this specific issue today looking at KTouch with @aacid today. Should be solved with T5847.

Thanks!

https://codereview.qt-project.org/#/c/202746/

Correct. It's related to this one: https://phabricator.kde.org/T5847

Sounds like a plan =)

What I mean and what we need is:

Found the culprit. The symlink target was missing. Thanks for the report!

The icons don't need to be exported as exported files are what the system needs from the flatpak (such as the application icons). The theme icons are only needed inside the flatpak, so not exporting is correct. I guess this is just an annoyance of flatpak.

Not sure I understand you correctly.

• We need the patch for flatpak to work, right (Right now I can choose between working openUrl and a crashing webengine)?
• You suggest that we just patch the qt copy in the kde runtime until 5.11 is released? (I would agree that this would be nice to bridge the time until 5.11 is out)

Well, unless we patch our Qt in KDE runtime until 5.11 is released, I don't see this as a problem.

I take it this essentially means no functional flatpak until qt 5.11 or so?

Oh, also I tested it and I confirm it works for me.

The issue has been fixed upstream and the runtimes rebuilt.

The icon is clearly there:

flatpak run --command=find org.kde.kube /usr /app -name password-show-on.svg*
/usr/share/icons/breeze-dark/actions/16/password-show-on.svg
/usr/share/icons/breeze-dark/actions/24/password-show-on.svg
/usr/share/icons/breeze-dark/actions/22/password-show-on.svg
/usr/share/icons/breeze/actions/16/password-show-on.svg
/usr/share/icons/breeze/actions/24/password-show-on.svg
/usr/share/icons/breeze/actions/22/password-show-on.svg
/app/share/icons/kube/actions/16/password-show-on.svg
/app/share/icons/kube/actions/24/password-show-on.svg
/app/share/icons/kube/actions/22/password-show-on.svg

Installed via :

"Disconnected" simply means that the last operation couldn't reach the server. We don't really maintain much state beyond that.
F5 or clicking the folder always triggers a sync, and if that is successful it will clear the "Disconnected" message you see in the lower left corner.
Closing and reopening Kube should definitely not be necessary.

Thanks for the report. I just checked and the icon should be available from looking at the code. Did you get flatpak from the kde repository or did you build it yourself?

I pushed a patch to Qt for review [1]. The patch makes platform services as a standalone plugin which you can override and make apps to use it, basically same way as platform theme. I also created a branch in flatpak-platform-plugin where I removed our custom platform integration plugin and created just platform services plugin instead.

Figured out:
https://commits.kde.org/flatpak-kde-runtime/d016215d753b6178fe615f92263eb4d693ef204a

Right, so this means konsole has to make this desktop file visible to the dolphin part, which at the moment it isn't. We should figure it out.

konsolehere.desktop is installed by konsole.
Btw the kdeconnect fileitemaction plugin is also affected, I think.

Works! Thanks

Who installs konsolehere.desktop?

Included libcurl: https://commits.kde.org/flatpak-kde-applications/fe4e0b49001d46c26dd1246cc2376d80caaffe5f

It starts ark via KRun but it also needs libkerfuffle (private library shipped by ark). In theory it would be possible to move the plugin and the library out of the main ark repo.

In sink. If its not somehow conflicting with the existing libcurl,, then sure.

Where are we using libcurl? Would it make sense to build it separately in Kube's flatpak manifest?

What does the ark plugin do? Does it need ark code? If not maybe it could be moved into dolphin-plugins.

We were looking into it with @jgrulich today.

You are right, there are actually two parts where this check is. One fails and the other just reports a warning. The one which is failing is in src/core/content_browser_client_qt.cpp (lines 300+) and to avoid that we need to do two things:

1. Implement nativeResourceForContext() into flatpak platform plugin which should be trivial
2. Make qtwebengine to accept flatpak platform plugin, which probably means to carry our own patch as I don't think something like that would be accepted in upstream at this moment

@jgrulich I've been able to reproduce the issue. In org.kde.kube sometimes you get a message saying flatpak platform not yet supported and the application closes.

This should work already with Qt 5.9. With older versions (at least in 5.6.3) it fails to work with other platform plugins, while with Qt 5.9 it just reports a warning but doesn't fail. Same applies to wayland platform plugin by the way as there is a check for xcb plugin only.

@jgrulich can you please take a look?

It works however when unsetting the variable: flatpak run --devel --env=QT_QPA_PLATFORM="" org.kde.kube

Reported on Flatpak upstream: https://github.com/flatpak/flatpak/issues/947