Hello, I didn’t know about these guidelines, thanks for publicising them.
I spent some time trying to get my app through:
But it’s still failing on five items, and without more feedback I don’t think I can get it to pass.
suggestion: Perhaps the reviewer could open an issue on my repo with more detailed feedback? That would also allow some discussion if I feel there has been a misunderstanding.
I have some specific suggestions for some of these guidelines based on my fails:
Icon size … I’ve tried two sizes for review now. Frustratingly, both have failed with no feedback, I don’t know if I’m too big or too small.
In line with contemporary styles … I think this guideline should be removed. No one is going to redesign specifically for flathub. Though I agree my icon is awful heh.
Default settings … I made a “Gnome Classic” guest account on ubuntu 24.04, made zero changes, and took the screenshots. How can I get more default than this? Perhaps it’s because my app defaults to dark mode, as the Gnome HIG says image viewers should?
Reasonable window size … they all fit within 1000x700, so again, no idea why it fails and I can’t fix it.
Up to date … the shots were all taken of the uploaded version, so, again, no idea why it fails and it’s impossible for me to fix it.
Branding Has primary brand colors: I’m not a designer but I’m trying to add some with the next update that don’t look too bad in my eyes.
App Icon Doesn’t fill too much or too little of the canvas: the circle icon touches all sides, I don’t quite get though why it shouldn’t fill the canvas, the places displaying it can just add some padding around if they want? Also I didn’t make the icon myself, would also love to have a better icon someday.
Summary Shorter than 35 characters: mine is 41 characters so while “Configure and control your Razer devices” is for sure not the absolute shortest, it’s short enough in my eyes to say what it needs to say. Suggestions welcome.
Screenshots Default settings: Current screenshot is Qt with Breeze Dark theme, what I’m using on my laptop. But I’ve updated it to one with Breeze Light theme, easy enough, and a new screenshot was anyways necessary since the UI changed a bit.
Screenshots Include window shadow and rounded corners: There is, the screenshots are made with “Include window titlebar and borders” ticked in the Spectacle screenshot tool. For sure the shadows are not very strong but they’re there.
Let’s see what the reviewers will say with the next version.
My app uses the KDE runtime. The app is PianoCheetah
I named it PianoCheetah years ago.
And I will NOT change it to Pianocheetah or Piano cheetah or whatever.
flathub is great - i love it. But the guidelines are FAR too opinionated. Some are super dumb in my opinion.
I should be able to name =my= app whatever I want.
I guess name length makes some sense but capitalization and spaces are silly. Let me do it as I please. I won’t rename my app to meet such a dumb requirement.
Maybe I want to be informal. Why should that keep my app from meeting basic requirements?
The requirements are (VERY OBVIOUSLY) overly strict.
I’ve requested a review for my app and got 3 failed checks. But without actual comments, not just checkmarks, I cannot even understand what exactly is wrong and how to move forward.
I.e., “doesn’t fill too much or too little of the canvas” failed while it is clearly within the recommended boundaries:
Summary is not “understandable for a non-technical person” according to the review — well, my app works within GNOME and the summary is “Native-feeling timers for GNOME” — I have literally no idea what is the expectation here.
Also 35 characters limit is absurd IMO. 50 would be ok.
Icon size passes right now, so seems to have been resolved
Feel free to reach out in the kde or gnome design channels
Ubuntu unfortunately doesn’t ship default window decorations - a gnome OS or fedora VM should work better (and you also don’t need to install flatpak manually there)
Probably old, I just passed that
Same problem as 3
For context, we don’t care about the shadows themselves here, it’s mostly the added padding we “want”. (it’s complicated and unfortunate, that we need this)
We also fail this for apps, that are mostly transparent inside of the borders. We once had somebody send an app icon with just a red ring and everything else was transparent…
Mentioning technologies like “GNOME” is fine in your description (I would argue, it’s not very helpful even there) but your summary is way too important for such a detail. That it runs on gnome is after all just implementation detail, MPRIS will just work fine on every other freedesktop.
Not really. I would love for my app to work on any DE, but only GNOME implements a widget for players by default. I.e. in KDE there will be only a tray icon — while technically it might be considered as “working”, this is neither the intended, nor the supported behavior of the app.
But why should every app look like it only works with Gnome? Isn’t the strength of Linux and OSS the freedom of choice and shouldn’t a Linux App Store embrace this?
Yeah, I really feel like policing whether minimize and maximize buttons are visible in libadwaita apps and other recommendations like this aren’t helping the Linux community at all with getting new and old apps onto Flathub.
Listen, I like clean app listings too and agree with many of the recommendations, but some of them are, like others have said in this thread, way too opinionated and “perfectionist” for the current state of Linux apps. Like, is anyone actually confused when they see the maximize and minimize buttons on a screenshot and only a close button when installed? Unless you’re actually getting a lot of people posting about this, we should be focusing on getting developers on board with Flathub, not pushing them away with things like this that don’t champion the inherent diversity of an open source project like Linux.
I want to be clear that the quality guidelines we’re talking about are optional guidelines that help determine what apps are explicitly featured as the very first thing you see on the Flathub home page above all other apps.
The intent is to be opinionated (it’s the Flathub app store, we want to have a consistent look/feel for when people come to the site) and we of course are going to skew perfectionist (we want people—especially new users—to see Flathub in as best of a light as possible).
It’s less about people being confused, and it’s not at all about gatekeeping what can come to Flathub in the first place. I’m happy to debate the specific guidelines, but let’s not conflate these optional quality guidelines with “getting apps onto Flathub” in the first place.
Hey everyone, checking back in after a bit over a week of feedback and discussion. Thank you so much to everyone who has chimed in so far! This sort of conversation is enlightening and healthy.
I want to try to summarize some main, recurring points here that I’ve personally come away with—note that I’m focusing on the sentiment and not necessarily the “validity” and definitely not suggesting solutions at this point:
Some developers still didn’t realize these guidelines even existed at all, and there is still confusion around what the guidelines are actually for (e.g. they’re not gatekeeping what’s accepted on Flathub, but are prerequisites for being displayed prominently on the home page)
The review process does not provide enough direct feedback in many cases, e.g. how to make an icon better, what specifically could be improved about a screenshot, etc.
There’s a difference between an app listing and an app’s identity—and people feel strongly that Flathub should not be dictating app identity
Name & Summary
In general, guidelines like “just the app name” seem reasonable and easy to meet
“No weird formatting” seems more arbitrary and harder to meet, especially for existing apps
Some character-length restriction seems impractically short, and are not enforced for translations anyway
Icon
There’s a recurring sentiment of “we’re not going to change the icon we’ve always had just for Flathub”
Some people don’t have the skills (and don’t know/feel like they can ask for help) to make an icon that meets the guidelines
“In line with contemporary styles” seems subjective and sometimes hard to meet
Screenshots
Screenshots using “default settings” and “native decorations” is unclear and contentious in a world of multiple environments and distros with different default settings and window decorations
Size guidelines are unclear (some thought the sizing was a hard requirement), and not practical for all apps (doesn’t cater to large, complex apps in addition to small, simpler ones)
I have some thoughts on how we could move forward to both feature more apps and to improve the guidelines, but I think I’ll save that for another post after I think it over a bit.
For now, do you feel like the above summarizes common points raised? Did I miss anything?
I agree with the main recurring points that you’ve noted, @cassidyjames. The primary issues that I have that weren’t explicitly mentioned in the summary are as follows:
If I run afoul of one of the guidelines, there isn’t enough feedback for me to know how to fix them. The one app that I have on Flathub fails the “Default settings” check, but there’s no accompanying comments to tell me exactly what in the configuration doesn’t count as “default”.
I don’t like that I need to publish my app on Flathub to get a review. If I have an app in development, I would like to be able to submit a private version of my app for review so that it can launch in a state that follows the guidelines. I know this would take a lot of work to set up, but I think it would be worth the effort.
Generally speaking, I would say the guidelines have been a success story in politely enforcing good quality packages on Flathub, so don’t let the feedback discourage you!
IMO, your app is right at the border of having too much whitespace inside of the borders, but I guess tobias might have a different opinion.
Please read again, this was a specific recommendation for the author. You are free to have multiple screenshots of whichever DEs, just don’t edit them and make sure to include the shadows etc. and tag them correctly in the metadata.
Translation does not matter here IMO - the idea is to force the base of all translations to be succinct and easy to follow. Not trusting translators with translating that correctly, would be a mistake IMO.
Probably oversight, from the timeframe, where we asked the KDE team to confirm which decoration was their current one and they were unsure.
Regarding the recommendation to use a VM with default settings for the screenshots:
I would absolutely not be ready to spin up a VM to take a screenshots (for a hobby app. Something for work would be different).
In my case I changed the screenshots because using gnome made more sense, since I’m on sway and sway doesn’t support taking screenshots of a single window, so taking a “proper” screenshots using another DE seems fine. I’m on Arch, so a gnome install looks “default”, but If I were on a distro which ships a custom theme I would not have bothered to try to work around it.
Today I’m on cosmic alpha, which has a proper window screenshot tool, but does not support shadows, I’m unlikely launch gnome just for shadows (at least for a new app. Since my app already has shadows in its screenshots I would not want to remove them when updating the screenshots).
I personally would appreciate – because I haven’t seen it written anywhere – some clarification as to what “prominently” means. What is an app not eligible to be included in if it doesn’t meet the guidelines? The scrolling banner across the top? Does it mean the “App of the Day” box? The Trending/Popular/New/Updated boxes? The sections for each category? Does not meeting the guidelines mean it’s not possible to be on the front page at all?
If we’re only talking about exclusion from being app of the day, for example, then I wonder whether maybe many devs would be ok with simply not meeting the guidelines? And there’d be less disappoint in their strictness? But at the moment what’s written in the docs (emphasis mine):
Apps following the quality guidelines may be featured more prominently across Flathub and native app store clients, like on the front page or at the top of category pages.
makes it sound like you’re missing out on a lot and will basically be buried on page 6 of your category behind everything else, regardless of popularity.
Equally, I get why it says “may be featured” i.e. meeting them is no guarantee that you will be featured, but it doesn’t explicitly say that an app definitely won’t be in any of those places if it doesn’t meet the guidelines, which is a bit of a difference.
We also use the moderation data for other things, but I think that might not be helpful for this discussion.
Gnome also ships a list based on our passing apps as default list of apps, that will show on gnome softwares banner. But distros are free to overwrite that.
I’m late for sure - I’ve been seriously busy lately so only saw this through Brodie’s video pointing out its existence, BUT I feel I might as well provide some input myself in case it helps in any way:
For the record, I’m one of the maintainers of the one.ablaze.floorp Flatpak, BUT I AM NOT REPRESENTING FLOORP nor the opinions of other Floorp developers by saying this - this is just my take on it and may or may not align with the opinions of Floorp’s other maintainers.
I’ll list the currently failing items and provide my input:
Good primary brand colors: I agree with this, and for the record have already fixed it - however I never resubmitted for review yet due to reasons explained later
Summary shorter than 35 characters and Doesn’t start with an article: This is something I don’t necessarily agree with - sure, it works for summaries that say “X does Y thing”, but in the case of applications like Floorp I’d argue the summary being a mini description that also demonstrates the application’s key unique selling point (for Floorp, being from Japan with various additional features, for example) may be better suited, especially for aiding first impressions, but doing so would need a few more characters than the current limit and wouldn’t quite work without prefixing an Article.
Default Settings: Yeah, I certainly get where you’re coming from BUT this is sadly paradoxical because not every developer can resolve, if they even realise, the fact that their distro’s configuration isn’t vanilla out of the box - my suggestion would be to change this into a recommendation that the application is represented through the defaults of the OS that the application, or Flatpak, was developed in (that way, we account for Ubuntu’s Libadwaita patches for applications created inside Ubuntu, etc.)
Include window shadows: This one’s on us - I don’t see issue with this guideline, aside from the problem of some screenshot tools not screenshotting shadows in rare cases (and of course the client-side-shadow detection problem in Wayland that was a major player in creating this requirement to begin with), and this is just me being too busy to update our automated Floorp screenshot generation script to not use Openbox as the X11 session’s, where the screenshot is taken by automated scripting, window manager
Reasonable window size: Honestly, no qualms from me regarding this one either - per what I said in the previous bullet point, I’m likely going to have the automation install KWin, use a KWin window rule to force the window size, and take a screenshot that way to fix that issue
Good Content: That’s Floorp’s new tab page - there’s also screenshots showing the browser’s official website, which is what GNOME Web’s approach to screenshots is for reference, but I’d think showing the new tab page of the browser is far more useful for the user to know than the official website is in a primary application screenshot - suffice to say, I really don’t see how this one failed (unless it was the lack of captions at the time, which case that makes sense - as people mentioned prior, though, having textual feedback would help) (NOTE: most browser listings on Flathub also show their new tab page in their respective primary screenshot).
Same, we would probably have passed it, if it was the only failure. Usually we don’t want screenshots of empty states - which this technically could be seen as, but usually we still pass such cases. In general real content would be better and it probably shouldn’t be on slot 1.
I’m not a developer, just a user, but I was always confused by how small the app screenshots on Flathub are. Did’t realize that is by design.
I use a lot of apps that are intended to be full screen and 1920x1080p+ - eg. FreeCAD, KiCAD, LibreOffice, Scilab. Reduced to 1000x700, large apps like those have to hide toolbars, reduce the viewport, sometimes hide large parts of the UI altogether. This makes the screenshots not really representative of the app in use. Allowing full screen screenshots would make them harder to use on small screes, but then those apps are not intended for small screens anyway.
