It was updates and installs, it’s installs now. I do have a branch, that changes the wording to Installs, but that’s part of a translation rework right now.
Bigger as in height? It’s way wider for me, but that depends on your screen width. It’s also always present and doesn’t get hidden on mobile form factors. But that might change.
Looks great!
Needs more metrics visualizations. At least monthly downloads on publicly/user visible pages, just the last month would be enough, and for the developer, further metrics should be available, at least downloads per month for the last year.
Patreon-like supporter counter should also be added with the donation support. Hopefully, this will motivate developers to maintain their own apps.
We are working on supporting donations, but there is both a technical aspect and a legal/tax aspect we need to work through very carefully before we can enable it.
Most likely we’ll start with supporting donations to flathub itself, and then move from there toward apps.
I really like the new flathub UI nevertheless I miss the “publisher” section where pressing there would take me to the flatpak related repository of the app.
It makes things easier for users to find latest state of the app, issues it has and solutions for flatpak edge-cases. Also redirects users to the “correct” place to report issues related to flatpak.
@nimfaelfika Please could you file an issue against the frontend repo so that we can try and keep track of these missing features?
Thank you all for your useful feedback and bug reports from the last situation
report. We (Codethink, James Westman, Kolja Lampe, Bartłomiej Piotrowski, et
al.) have been heartened to see the interest in the work we’re doing. We
continue to be grateful to the GNOME Foundation and Endless Network for
supporting the effort to bring all these new features to flathub.org.
As we mentioned before, there are a number of legal/tax implications around
donations and purchases as they cross geopolitical boundaries. While work is
ongoing to understand these constraints on how we might be able to operate, we
have been hard at work preparing the backend and core frontend support for
processing transactions. We selected Stripe as our payments partner and have
been integrating their APIs and flows into the codebases.
We’ve been careful to ensure that Flathub retains no sensitive information about
these transactions, instead all of that is deferred to Stripe who have an
excellent set of processes and policies around this. All card transactions etc.
are handled by them, in a flow which embeds into our website.
At this point, we have a happy-path transaction flow fully working with the
backend, and we are working on frontend integration for that. Unfortunately
we’re not ready for https://beta.flathub.org/ to carry that work, though we are
getting much closer.
James’ work on verified application support in the Flathub backend and website
has continued. Developers can now verify their ownership of apps through their
GitHub or GitLab accounts.
In addition, James has been hard at work on a Flatpak authenticator, which will
direct you to the flathub.org website to buy or donate to a Flatpak application,
as the core of the support for paid-for Flatpak applications on Flathub. Once
you’ve bought an app, the authenticator will receive a code which it will use to
download the app. This work is going well, and will be integrated into the
purchase flow, as soon as we’ve worked through the legal/tax points mentioned
above.
We have, as a group, also been cleaning up and finalising the login support with
the ability to delete users, and the ability to add further login methods to your
account. This has a few outstanding PRs, but it should all be sorted soon, and
then you’ll be able to ensure Flathub knows your Github, GitLab, and/or Google
identities; and later we’ll add KDE and GNOME GitLab login too.
All these identities can be used by James’ work on verified apps to permit you
to claim the Flatpak applications which your logins demonstrate your control
over. This should streamline verification for people whose apps have
io.github, com.github and other similar org name origins.
The new frontend is now internationalised, and localisations are already being
produced for it. We have some work to do to integrate the login flow and
payment flows with this, but our hope is that by launch we will have the
frontend properly localised into as many languages as we can. This is being
done with weblate and we welcome
contributions.
Kolja and Bart are working hard to get to a point that the new frontend can go
live, meaning that the new functionality, translations, style, etc. will be
available for real on https://flathub.org/. It is very important that
if you have any more feedback on the application pages, or other data and
layouts, please provide that feedback to us ASAP. Note: we will not go live with
login support for another few weeks.
Sorry for the late response and for not being clearer before.
Yes, I was talking about the height of the search box. It kinda feels “squashed” and tiny for an element that I think should be one of the most prominent ones on the site.
Looks good. It’s nice to have the(/some) stats on the app pages.
I’m really missing an app extensions view. It would be really nice to be able to see which extensions are available for an app and to be able to install them.
Have you considered integration with Paddle instead of Stripe? The last time I checked Stripe did not provide any solution for handling international taxes which makes it unsuitable for use by EU-based indie developers.
It would be also great to have a “Pay what you can” option in similar fashion to the AppCenter from Elementary OS.
We’d not looked at Paddle before, no. I’d have to look carefully at what they offer to work out if they would suit our use. I agree that international taxation is a pain, but I can’t say if Paddle would be easier for us without investigation first.
As for ‘pay what you can’ - apart from minimum numbers for dealing with transaction fees etc, the intent is to permit the developer to set the “payment” down very low, and then just ‘recommend’ a donation number which is higher. I wrote a gist where I was musing about how to deal with this, because we want to ensure platforms also get a cut of donations, and a rough idea, not necessarily final in any sense, can be found here - flathub-vending.md · GitHub
I do not think so, most people just write “zero” there and download for free. If this is what the dev wants, we will already have a “donate” button, so no need for two options to do the same thing.
And the donate button will already have preset suggestions from the dev, from what I gather.
In some jurisdictions income from donations is taxed differently than income generated by selling software licenses, thus complicating accounting even more. If I recall correctly Paddle prohibits accepting donations because of that.
The “Pay what you can” model is somewhat a gray area, I guess the safest approach is to just make the app available for free and offer extra features via in-app purchases.
Is there a way for users to tell if an app has been verified, or is that still something to be implemented?
As I understand it, and James will have to correct me if I’m wildly incorrect, the intent is for the verification information to be available both via the website, and for flat-manager to incorporate it into the appstream so that store apps can show the information. The former is available on the beta site IIRC, but the latter will need further work yet.
So if I go to the beta website now, how do I tell if an app is verified? I don’t see any indication one way or the other on most app pages (the only exceptions being the apps whose description say they are unofficial packages, like Steam).
It’s not implemented (yet)
I’ve had an implementation of that, but it’s very hard frontend wise, as there are a lot of addons on some of the apps.
With regard to donations, have you looked into discourse subscriptions? Might make sense to hit two birds with one stone and incorporate discourse into your donations/review strategy.
It’s an established codebase with a company paying >1 maintainers to actively maintain. Could be integrated into GNOME-Software and KDE discover with plugins, it would be accessible from the web with straightforward process for users to delete accounts. You could scale the moderation teams much better as well without having to necessarily share what IP address or distro someone is using.
Yeah I guess a paginated list would work best for that, with the option of filtering by keyword. Don’t know about the API or backend support for that though…