[KDE developer and involved with Flatpak on the KDE side]
I agree with many of the guidelines, but IMO a major problem is that some are effectively putting their finger on the scale, which helps to produce the observed effect of mostly GNOME apps ending up featured. For example:
The recommendation to avoid all uppercase and camel/pascal case in app names privileges apps from communities that already have these restrictions, e.g. GNOME. This is also not something the app author is going to be willing to change just for Flathub.
Almost the entire section on icon design essentially enshrines the GNOME icon guidelines as the thing to follow. Like your app’s name, you’re probably not going to change your app’s icon just for Flathub.
“Reasonable window size” privileges small single-function apps which GNOME has a lot of, and disadvantages large powerful apps that are designed to be used maximized.
“Do not use a mix of windowed and fullscreen screenshots” privileges apps without separate windowed and full screen modes that the user might want to see.
References to things like “your native system screenshot tool” and “Use the platform default configuration” are problematic due to the diversity of our ecosystem, as doing so may contradict another guideline. These feel a bit like they’re trying to avoid saying “Take your screenshot in GNOME or Plasma, using GNOME Screenshot or Spectacle.”
These examples aren’t actually objective quality guidelines but rather subjective style guidelines. And it’s notable what’s missing, too. For example the app naming guidelines don’t say “avoid the name being a single generic word like ‘Files’ or ‘Icons’ that would be hard to do a web search for”, which would disqualify almost all GNOME apps.
I think it would be worth going over the text to remove some of the opinionatedness that has the de facto effect of tilting the scale in favor of GNOME apps. Other opinionatedness that has to do with more objective quality is fine, but subjective style guidelines are always going to be problematic in a diverse ecosystem such as ours.
There are other recommendations that are not as clear as they could be IMO. For example:
“ideally phrase it in the imperative with a verb” starts with “ideally” which implies that it is not a requirement, but 100% of the “good examples” follow it. Is it actually a requirement or not? I hope not, because this would be quite awkward as applied to a lot of apps. For example Kate’s summary is “Advanced text editor” which IMO is okay. How would we rephrase that in the imperative? “Edit text in an advanced manner” ?
“No weird formatting” is subjective and mildly inflammatory, and needs to be rewritten with a more neutral title and a hard-and-fast list of don’ts. Also it needs to be clarified that acronyms specifically are OK, since they’re all-caps and would otherwise fall under the “bad example” of an app with an all caps name. The reference to VLC implies this, but does not state it clearly.
I’ll get specific about an app I co-maintain, Elisa. It’s currently failing three quality checks:
Icon not good on dark theme - as mentioned earlier, not going to change the icon just for Flathub.
Window too large - it’s a big app and a big screenshot showcases it well. The screenshot is perfectly fine IMO.
Summary too long - “Play music and listen to online radio stations” (46 chars) is fine IMO, and even if I shorten it by removing “stations” (37 chars) it still wouldn’t fit. This is even a bit out of date as of a change I pushed upstream to change it to “Play local music and listen to online radio” (43 chars) to address the emerging impression many seem to have that music is a thing you stream from a big evil company, which is the one thing Elisa doesn’t do. Even if I shortened that as much as I possibly could to “Listen to local music and online radio” (38 chars) it still won’t fit. “Play local music and online radio” (33 chars) fits but barely but doesn’t feel as good to me IMO. I think 35 characters is just too restrictive.
There are also additional technical violations that the quality checkers didn’t catch:
Technically, the second screenshot that lacks shadows because it’s full-screen and depicts the mobile UI. Technically this is a violation, even though obviously there’s nothing wrong with it since it’s advertising the fact that the app works on mobile with a mobile-optimized UI.
Technically, the first screenshot doesn’t depict default settings since I took it while the titlebar had a non-default “keep on top” button added to it. Presumably the quality checkers didn’t notice, reflecting how minor and unimportant such a technical violation is.
Technically, the UI is “out of date” in both screenshots because there have been extremely minor visual changes made to the app since the screenshots were taken.
There’s just too much rigidity here IMO. Even the checkers can’t keep up with the level of criticality with which they’re being asked to review apps’ presentation. It’s simply too much IMO.
The summary should not have any weird formatting or punctuation. It should use sentence case, rather than title case. It shouldn't end with a full stop.
Sentences should always end with a full stop or relevant punctuation.
I tried to get many of the application I work on or at least remotely involved in KDE to fully passes all the checks. Until now, I only managed to pass all checks with Calligra.
One issue is that our release schedules is 4 months and I can’t backports strings changes to patch releases. So when I change any strings, I then have to wait ~4 months for any textual changes to see if I resolved the issue or not. For screenshots it is a bit better, because I can backport them but I still have to wait around a month to see if my changes are deployed and I unfortunately don’t have that big of an attention span.
I did update many screenshots ~8-10 months ago for dozens of KDE apps, specially for the introduction of this quality guidelines. But unfortunately they didn’t follow the ‘guidelines’, because I still used the old style of having a red close button instead of the new style of using a button with a transparent background and as such my screenshots were not using the default of the platform. This was super annoying and really significantly decreased my motivation to improve the metadata for Flathub. I am slowly updating the screenshots again but this is a large effort and I have a lot of other things to do.
I had other issues.
For Neochat, an issue I had, but which was recently recently fixed, is Do not display screenshots with environment="windows" · Issue #4105 · flathub-infra/website · GitHub . Since we use AppStream for more than just Linux but also Android and Windows, we added screenshots of NeoChat also on windows and properly marked them as for windows. Other than that I hope all the other issues will hopefully be resolved in the next release coming in 2 weeks.
For Tokodon, this looks good aside from a screenshot being to big. Again hopefully fixed with the next release in 2 weeks.
For KDE Itineray, most issues are easy to fix and the fixes should be available in the 24.12.0. release. But there are some unresolved issues. This applications uses a vertical layout and this seems to triggers “Reasonable window size” for the screenshots. The name is “KDE Itinerary” and this triggers “Just the name” and the icon is also an issue because it has a very small shadow on the bottom but this is just the style used by most of our new apps Apps - Plasma Mobile I don’t think Flathub should be policing the icons unless the icon is very ugly.
Generally the window size requirement is also a painpoint for any a bit complex application. Trying to get small screenshots of Kdenlive or Krita is almost impossible and these are supposed to be lighthouse projects from KDE.
I maintain Flathub packages of two applications: Telegram Desktop and Kotatogram Desktop. Both packages got 8 (different) failed checks. Most of those (7) look like false negative to me for Telegram Desktop. And about half of them (4) for Kotatogram Desktop. I’ve mentioned all that in in details in issue: App Listing Quality has lots of false negatives · Issue #5900 · flathub/flathub · GitHub.
I very strongly feel that many of the screenshot guidelines should pretty much be the opposite of what they are currently:
Screenshots should be taken without shadows and without window decorations - if this is universally adhered to then padding and shadows and rounded corners can be added procedurally as desired
Screenshots should accurately represent runtime appearance of the current Flatpak version as closely as possible, for the largest or one of the largest groups of users, at the time that the current Flatpak version was shipped - distro, DE, settings etc. mustn’t be rigidly standard or bleeding edge, but the screenshots must not misrepresent the app in any way
If the app appears different in light/dark mode, the first two screenshots must demonstrate light and dark mode in that order
The screenshots should be sized such that they demonstrate realistic and actual usage of the app. All UI elements must be shown
The first (or the first two if light/dark) screenshot should additionally be as compact as possible while conforming to the above rules - I genuinely believe a sensible and representative size is something that can easily be judged on an app-by-app basis, obviously full-screen shots of GNOME Files are good to nobody, but also no one ever uses Blender in only a quarter of their screen
If the app is typically used in full-screen mode or in mobile format, these should be demonstrated in at least one screenshot
KDE HIG requires colorful to have 4px margins, it seems flathub requires 2px margins, which means the apps doesn’t pass the following check “Doesn’t fill too much or too little of the canvas”
Please make sure, that screenshots also include rounded corners according to DE specs and anti aliasing still works. We also can’t loose stuff in the middle of the picture or downgrade image quality significantly.
If anyone is trying to make their apps pass and has specific questions or problems like the ones above (and not general feedback for the entire guidelines), I suggest opening an issue using the quality guidelines template.
This is also now linked in the quality check sidebar on flathub.org, so you can open an issue directly from there as well and ask for clarifications.
and the icon is also an issue because it has a very small shadow on the bottom but this is just the style used by most of our new apps