Is there a way to promote the availability of these proprietary applications in Fedora, in a way that doesn't look like a recommendation or preference of the apps themselves?

Is there a way to promote the availability of these proprietary applications in Fedora, in a way that doesn't look like a recommendation or preference of the apps themselves?

The closest to that is probably option 4. That section on the home screen is currently headed "editor's picks" but we could change that to something less recommend-y ("Discover", "Available for Fedora", etc).

We could also think about policies we want in place. Maybe we could have a rule that we always include an equivalent free/libre app (if one's available), so it doesn't look like we're recommending proprietary apps over free/libre ones.

It would be odd to do this and then bury the results of our work. Ideally I would like us to be promoting the 3rd party apps that we've put effort into making available.

But what about all the non-third-party apps that Fedora has also worked on making available? Promoting some applications necessarily means not promoting others. There are many apps worth promoting that also happen to be less controversial to promote; there are enough of them to fill all the slots and banners in the Explore section in Software.

And, whether any app is best in class is super subjective, because none of them does well on all objective metrics. For example, Chrome is fast (according to browserbench.org) and supports web standards well (according to wpt.fyi), but it also has poor system integration and no native support for Wayland. So is it best in class (on Workstation, which is what matters)?

Popularity is one indicator of quality and usefulness, and even contributes to them in some ways (e.g., it might mean more extensions available, more incentives for website compatibility, more people you can talk with), but it hardly accounts for everything and search costs ensure it usually lags some years behind and favors apps available on many platforms. Surely one of the main purposes the recommendations in Software can serve for users is to overcome the costs of searching for better apps than the ones they already know? Such could be done more effectively by promoting good apps like Foliate and Apostrophe that are not very well known than by promoting Dropbox, which everybody already knows about.

There are many apps worth promoting that also happen to be less controversial to promote; there are enough of them to fill all the slots and banners in the Explore section in Software.

I don't think that's correct.

We are a long way from having to choose some apps over others. The explore page is supposed to be dynamic and be constantly updating, in order to make it engaging and enable discovery. That page in turn is supposed to be a jumping off point for other sections of dynamic content. That provides plenty of capacity to present large collections of content (as other platforms do, which have vastly more apps than we do).

Our major problem at the moment is that we don't have enough high quality apps to fill the space we have available.

It's also worth bearing in mind that what's being proposed here is quite limited - the addition of a restricted number of key apps, which will be significantly outnumbered by existing content.

Action: Allan to propose a mockup for a design that reduces the emphasis on proprietary applications.

Action: Allan to propose a mockup for a design that reduces the emphasis on proprietary applications.

Adding pending-action for this.

I've attached the promised mockup, which gives an idea of what an "Available for Fedora" section could look like. This is a modified version of the latest mockups for Software, which are somewhat different from the current version. There is an ongoing effort to implement them.

It seems that the new UI has a section for the most popular apps. I'm not sure how feasible that is to implement, but if it does happen, it might be that we don't need the extra "available for Fedora" section. (Presumably many of the apps that would go into the "available" section would naturally bubble to the top of the most popular category.)

The working group discussed the above mockup yesterday. In general it seemed that people were positive. There were some questions and suggestions about the section title and showing the source of each app; I think we can return to those at a later date.

We might want to see if the most popular section makes its way into Software before proceeding with this design proposal. Relevant upstream tickets for that are #1111 and #427.

If we do decide to go ahead, there are a couple of pieces that we might need to get in place first. The first is the filtered Flathub view (#108). The second thing might be to retire the existing downstream maintained "editors picks" selection, since this would in effect replace it. The upstream issue for that is #747.

I see the pending-action tag here. What is that action and to whom is it assigned?

Action is for GNOME Software developers to implement your mockups.

Note you need to fix the application licenses first. The Software changed the way it detects the license, it relies on as_license_is_free_license. Many core applications are recognized as proprietary, because they have set in the appdata licenses for the code and for the documentation, or they have otherwise broken license field, which makes the license unrecognized as free by the as_license_is_free_license function. One example is GNOME Mahjongg, which is currently shown as Proprietary license. See (currently closed) https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1200 .

For the design itself, the https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1021 doesn't seem to be updated.

For the design itself, the https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1021 doesn't seem to be updated.

The mockup for this issue is here.

For the design itself, the https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1021 doesn't seem to be updated.

The mockup for this issue is here.

Allan marked the upstream bug as "Needs Design" 3 months ago, from which I guess the above mockup is obsolete. In any case, what is here doesn't matter, the work is done upstream.

There's been a lot of UI churn in GNOME Software this cycle and GNOME UI freeze is now in effect (see below for a screenshot of the current explore page). If we have enough apps available through the 3rd party repos, we could aim to add the "Available for Fedora" section in GNOME 42 / Fedora 36.

I couldn't see an upstream ticket for the latest design proposal (the "Available for Fedora" section), so have created one: #1409

The action that's pending here is to implement that proposal for GNOME 42 / Fedora 36.

So to be clear: under the new design, proprietary software could appear under the Available for Fedora section, but no longer in the large banner at the top of the window? That sounds good to me.

So to be clear: under the new design, proprietary software could appear under the Available for Fedora section, but no longer in the large banner at the top of the window? That sounds good to me.

That's the plan.

Something that needs to be decided on the WG side is which apps to include there: should it just be apps from the 3rd party repos, or are there other apps we'd like to include?

We also need to decide on how to maintain the "available for Fedora" app list. My hope was to have an XML definition that could live in a repo that's owned by the WG... do you think that would be possible, @mcrha ?

My hope was to have an XML definition that could live in a repo that's owned by the WG... do you think that would be possible

Yes, of course. The changes https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/967 for https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1409 expect the same format as https://gitlab.gnome.org/GNOME/gnome-software/-/blob/main/data/assets/org.gnome.Software.Featured.xml , except instead of the GnomeSoftware::FeatureTile is expected key GnomeSoftware::DistroFeatured. More details can be found here: https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1409#note_1265711

The change is not accepted by the upstream yet, and it's slightly more complicated due to the translations of the "Available for Fedora" string, which should be provided by the distro as well, from my point of view.

The change is not accepted by the upstream yet, and it's slightly more complicated due to the translations of the "Available for Fedora" string, which should be provided by the distro as well, from my point of view.

Can't it use the distro name from the usual place (os-release?) rather than having it in the gnome-software string?

Can't it use the distro name from the usual place (os-release?) rather than having it in the gnome-software string?

It can use the os-release, but then it'll generate sometimes weird string, like Available for Fedora Linux, Available for Debian GNU/Linux, and who knows what's in other distros.

The string Available for Fedora is not in the gnome-software sources, it's supposed to be provided by the distribution, with translated variants, in a separate file (as the current merge request is done).

This will be better discussed upstream.

The string Available for Fedora is not in the gnome-software sources, it's supposed to be provided by the distribution, with translated variants, in a separate file (as the current merge request is done).

It's not going to happen. Won't be translated at all if you expect the translation to be added in downstream. Not on Fedora, and probably not on 95% of other distributions.

If we really can't include this string upstream, then please change it somehow to not include the OS name. "Available for your system" or something.

"Available for your system" or something.

@aday That's up to you. I can do the change, just tell me what it's supposed to be. It will be simpler code, thus the upstream will benefit as well.

"Available for your system" or something.

@aday That's up to you. I can do the change, just tell me what it's supposed to be. It will be simpler code, thus the upstream will benefit as well.

That it's probably best to discuss the heading in the upstream ticket...

The upstream changes landed few days ago. If someone provides me with the needed files (see the Deployment Featured Apps section there), I can add them to the gnome-software package. Or it can be distributed in a different package (which would be better (maybe in fedora-release-workstation), only an update of those files requires gnome-software restart).

Thanks Milan! I think Allan will tackle this when he returns. Adding pending-action tag.

I'll work on a list of apps that we'd like to show in this section. In the meantime, could you provide a few screenshots, @mcrha ?

Screenshot of what specifically, please? It's only a new section, at the bottom of the Explore page, the same as "Editor's Choice" and "New & Updated", just below the last app set ("New & Updated" in this case), titled as the .ini file says.

I've tested the new "deployment featured" feature now. It looks like this:

It is a simple section containing 12 app tiles. If fewer than 12 apps are specified, the section isn't shown. If more than 12 are specified, @mcrha tells me that a random selection will be chosen each day.

This looks good to me, and I think that it will be good to use this feature in Workstation, in order to advertise the following types of apps:

• the most well-known and popular apps that are available for Fedora (both because it's likely that someone will want to install them, and because it speaks to the overall attractiveness of the platform)
• the 3rd party apps that we've put the work into making available
• apps which speak to our focus on developers and creators

The third party repos currently contain 9 apps and I'm sure we can find 3 more apps to make up the numbers (so far I used RStudio, Ardour and Blender).

There is a question here about what we do if and when we open up more of Flathub (#300). In that case, we could have many more apps to choose from. But maybe we just cross that bridge when we get to it.

It would be good to get approval from the working group before we enable this - adding the meeting tag.

The working group discussed this on Tuesday, and is happy for this feature to be enabled in F37.

I've updated my own configuration to include the following apps:

• From the 3rd party repos:
  • Bitwarden
  • Discord
  • Google Chrome
  • Microsoft Teams
  • Minecraft
  • Postman
  • PyCharm Community Edition
  • Skype
  • Steam
• From the Fedora repos:
  • Ardour
  • Audacity
  • Blender
  • Qt Creator
  • RStudio

These were selected using the following criteria:

• Include all the third party apps
• Other apps should:
  • have a good level of brand awareness
  • generally fit with Workstation's focus on developers and creators
  • not overlap with existing featured apps

I expanded the list from the minimum of 12 to 14, just in order to make it a bit more robust. (With a list of only 12, if one can't be found, then the whole section disappears.)

Here is the configuration file:

Here is the configuration file

You need also the deployment-featured.ini file with the translations of the section name.

Which package will these files be distributed by, please? Maybe fedora-workstation?

You need also the deployment-featured.ini file with the translations of the section name.

If we could get the section name upstream, that would be ideal. E.g. to keep it distro-agnostic you could do something like: g_strdup_printf (_("Available for %s"), g_get_os_info (G_OS_INFO_KEY_NAME))

If it's just a downstream config file then it will not be translated, which would be a shame.

If we could get the section name upstream, that would be ideal. E.g. to keep it distro-agnostic you could do something like: g_strdup_printf (_("Available for %s"), g_get_os_info (G_OS_INFO_KEY_NAME))

It had been decided upstream to do it the way it is done. It has its advantages.

Honestly Allan, I would give up at this point. We should not add this feature if there won't be upstream translations for it.

Presumably, the question of whether the string goes upstream or downstream is down to whether this string would be wanted for other distros and deployments? We could ask around and see what Datto or Red Hat might want to use for their internal deployments.

If the "Available for Fedora" string lives as part of a Fedora package, what are the prospects of getting it translated?

Sounds like you would have to manually contact translators and have them give you translations to paste into the config file. Sounds like a lot of effort for one string: certainly not worth it. Realistically, all translated strings need to be upstream or they'll be English-only, just like our GNOME Terminal patches from nearly a decade ago are still English-only.

I've already provided my suggestion for upstreaming the string in a distro-agnostic way.

So for Fedora we wanted a very neutral heading which was clearly not an endorsement, hence why we went with "Available for Fedora", but a different organisation might want something stronger, like "Recommended for FooCorp Associates" or "Essential FooCorp Apps".

Solution: just add all variants that you want to support to the upstream codebase.

Solution: just add all variants that you want to support to the upstream codebase.

No. I do not see a reason why should upstream care of anything specific to a single distro. Not about me, upstream itself doesn't see that reason either.

OK, I suggest closing this issue then. Adding the new UI is less important than avoiding untranslated strings.

Or alternatively: redesign so that allowing downstreams to choose different headings is no longer a goal.

I agree that Fedora shouldn't be pushing its own strings into the GNOME project, in order to get its translators to do our work for us.

That said, while the existing "Available for Fedora" heading was designed to meet Fedora's needs, it could potentially be relevant to other distros. Likewise, if this feature is explicitly intended to be used by smaller scale deployments, then it might make sense for GNOME to support a number of different strings that they can use out of the box.

One thing I don't understand though - why are we assuming that Fedora couldn't translate this string? I see other Fedora components being translated...

I see other Fedora components being translated...

Like what? Are you sure they are translating downstream patches, and not entire projects where Fedora controls the entire translation? You'd then need to merge the translation into this configuration file that would be maintained in our dist-git. I'm sure it's not impossible, but doesn't seem worth the effort.

I spoke to @mcrha about the this issue last week.

Regarding the translation, it seems that there's a preference amongst the upstream maintainers to not have the string upstream. We could try and revisit that, but the timing isn't great: people are away on vacation, the GNOME 43 beta is out the door, and F37 is coming together.

@mcrha 's suggestion is to create a new project to store the configuration for the deployment featured configuration, and to hook this up to Fedora's translations infrastructure. it is a simple, single string that needs translating, so we can probably fill in the translations ourselves if needs be.

That seems like a workable approach to me.

The second issue is which package to use to distribute the configuration. @mcrha 's suggestion is to use the appstream-data package. Alternatives might be to use gnome-software itself, or fedora-release.

Opinions?

The second issue is which package to use to distribute the configuration. @mcrha 's suggestion is to use the appstream-data package. Alternatives might be to use gnome-software itself, or fedora-release.

The idea behind the appstream-data package is that it already contains tweaks for the gnome-software, thus it would make sense to put it there, to have the tweaks on a single place.

We also spoke about the fedora-release package, which I suggested, but Allan had a good catch about having a problem to provide this for the other spins and/or the Silverblue, thus instead of it a common package for all the spins/variants would be better, which the appstream-data package is.

@mcrha I think we should probably just go ahead with the plan you described, assuming there's still time to implement it for F37...

I think we should probably just go ahead with the plan you described, assuming there's still time to implement it for F37...

If I'm not mistaken, there's nothing left on the gnome-software side, just provide the files in the correct place and that's it. Correct me if I'm wrong, please.

If I'm not mistaken, there's nothing left on the gnome-software side, just provide the files in the correct place and that's it. Correct me if I'm wrong, please.

I can set up a project containing the configuration files, and I can maintain it. However, I'm a bit lost when it comes to setting up the translations.

However, I'm a bit lost when it comes to setting up the translations.

In what sense? If how to write it into the deployment-featured.ini file, then it's quite similar to what you can see in many /usr/share/applications/*.desktop files. Say you have:

Title=Featured by Fedora Linux

as the default text, which will be used when the respective locale is not found (aka keep it in the file). Then you add lines with the translations:

Title=Featured by Fedora Linux
Title[bs]=Predstavlja Fedora Linux
Title[ca]=Presentat per Fedora Linux

and so on.

The tricky part, at least for me, is to map the code with an actual locale name. Files like /usr/share/iso-codes/json/iso_639-2.json can help (there are more files in that directory).

I'll just add we could solve this problem in about five minutes by committing the "Featured by %s" string upstream. Then we wouldn't have needed to spend months discussing it.

@aday could you provide a status update here? You had some pending action item, but I don't remember what it was because we forgot to update this ticket. (Maybe it was to poke again regarding getting the translation upstream?)

My opinion remains that trying to keep the string downstream is not worth it, and if upstream isn't willing to add one string we should just give up on this feature.

@aday could you provide a status update here? You had some pending action item, but I don't remember what it was

The last time we discussed this, I was wondering about the impact of unfiltered Flathub and the reorganisation of the app recommendations that's currently being discussed in GNOME. My action was to figure out how those changes would affect the "available for Fedora" section. I've done that and think that it's still worth pursuing the "available for Fedora" section, since I think we need a way to advertise some of the big well-known apps.

However, I am a little uncertain about using the "available for Fedora" heading if we end up including a lot of Flathub apps in that section. ("Available for Fedora" made sense in the context of the other 3rd party repos, since those do in fact bring together apps that are available for Fedora. Flathub is a bit different because it is more distro-agnostic and has a distinct brand of its own.)

The translations issue is still the main blocker here, so yes talking about it upstream makes sense. We could consider alternative headings as part of that.

1. Configuration option

It could be possible to add a user visible control to enable/disable promotion of proprietary software. This could perhaps be included in Initial Setup, alongside the option for 3rd party repos.

This can be covered by https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1021

The translations issue is still the main blocker here

If I recall correctly, the proposal was to use "Available for %s", where the %s is replaced with /etc/os-release::NAME key, thus Fedora Linux currently, composing Available for Fedora Linux at the end. How much pretty it is is up to you. The PRETTY_NAME equals to Fedora Linux 37 (Workstation Edition) which is not suitable for this usage for sure.

It sounds like the current action item here is for Allan to provide a new design for Milan?

Or is it for Milan to implement the "Available for %s" proposal?

At any rate, the original issue of GNOME Software advertising proprietary software is long since fixed, right? The advertised/recommended software is nowadays always open source?

Changes for the above-mentioned https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1021 had been merged for gnome-software 44.0 (the first stable release version with it included).

The "Available for %s" doesn't have much to do with proprietary software. It's not "implemented" upstream either.

At any rate, the original issue of GNOME Software advertising proprietary software is long since fixed, right?

Right. We should probably close this issue and start a new one.

It sounds like the current action item here is for Allan to provide a new design for Milan?

Or is it for Milan to implement the "Available for %s" proposal?

I got sidetracked looking into app recommendations in general, and have some outstanding work there.

Last time I checked, the "Available for %s" proposal was still desirable, and I haven't thought of a better heading.

Here is a proposal for the "Available for %s" string:
https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/1654