[L2Ork-dev] Packaging Purr Data as a Flatpak for Linux

[Sam Thursfield]

A couple more things ... sorry for the double post!

> Here are some Purr Data graphics:
>  https://git.purrdata.net/jwilkes/purr-data/blob/master/pd/nw/purr.png
>  https://git.purrdata.net/jwilkes/purr-data/blob/master/packages/win32_inno/big_cat.bmp
>  https://git.purrdata.net/jwilkes/purr-data/blob/master/packages/win32_inno/pdPatch_catGraphics.ico
>  https://git.purrdata.net/jwilkes/purr-data/blob/master/packages/win32_inno/small_cat.bmp

These icons are quite low-res. For Flathub we need a 64x64 and a
128x128 pixel icon[1]. Are there any higher resolution cats?

Also, I signed up for the https://git.purrdata.net/ instance just now.
Do i need to announce myself in any special way, or is this mail
enough?

I submitted a request to the Flathub app store[2]. There will probably
be some work needed before Purr Data is published there, but i wanted
to get some feedback from them early on.

Sam

1. (see: https://github.com/flathub/flathub/wiki/App-Requirements#application-icons)
2. https://github.com/flathub/flathub/pull/1265

On Thu, Nov 14, 2019 at 11:20 PM Sam Thursfield <ssssam at gmail.com> wrote:
>
> Hi Jonathan,
> Thanks for the feedback! I'll make the changes you recommend.
>
> > I'd use "Purr Data." Otherwise people will confuse it with Pure Data.
>
> My only worry is that some users will know they want "Pure Data", but
> they might not think to search for "Purr Data", and think that it's
> simply unavailable. I don't know exactly what our options are in
> Flathub for that -- perhaps it's enough if we have the words "Pure
> Data" in the description, or perhaps we'd have to do something ugly
> with the name like calling it "Purr Data (fork of Pure Data)".
>
> > What's the maintenance cost with flatpak? For example,
> > what happens when a new version gets released? Do you have to do
> > manually package up the new version?
>
> The packaging manifest references a Git tag in the purr-data.git repo.
> So we'd have to update the manifest to point to the new Git tag on
> every new release.
>
> (Actually, the package currently builds from my fork of purrdata.git,
> in order to disable the Gem submodule. I did this because I had
> problems getting the Gem repo to clone reliably. I hope that can be
> resolved in future though.)
>
> > Also, I assume flatpak does some sandboxing of apps. Does that create any
> > limitations on setting real time priorities/filesystem access/etc.?
>
> I think for the moment the sandbox is going to prevent realtime
> priority, and it also prevents using JACK.  I read that in the next
> Fedora cycle, there is an effort in Red Hat to make pro audio apps
> work "perfectly" inside Flatpak:
>
> > There is also a plan to have a core set of ProAudio applications available as Flatpaks for Fedora Workstation 32 tested and verified to work perfectly with Pipewire, the current apps planned to be included are Ardour, Carla, a2jmidid, Hydrogen, Qtractor and Patroneo, but if there is interested contributors joining the effort we could have even more
>
> (from https://blogs.gnome.org/uraeus/2019/09/23/fedora-workstation-31-whats-new/)
>
> I'm not connected with Red Hat, but hopefully we can get on board that train :-)
> Sam