(→Detailed Description: Correct external link) |
No edit summary |
||
(2 intermediate revisions by one other user not shown) | |||
Line 7: | Line 7: | ||
== Summary == | == Summary == | ||
The primary way to install applications in Fedora is through the various Packagekit GUIs (gpk-application, | The primary way to install applications in Fedora is through the various Packagekit GUIs (gpk-application, Apper). This provide a suboptimal experience, as they're oriented towards packages, rather than applications, and expose various implementation details (repositories, dependencies, comps groups, just to name a few). | ||
Instead, this feature is about building a software installer that is focused on applications, including the actual name and menu position as shown in the Shell/KMenu, the app icon, as well as screenshots and ratings. This system should hide technical details as much as possible. | Instead, this feature is about building a software installer that is focused on applications, including the actual name and menu position as shown in the Shell/KMenu, the app icon, as well as screenshots and ratings. This system should hide technical details as much as possible. | ||
Line 21: | Line 22: | ||
== Detailed Description == | == Detailed Description == | ||
It's planned to use the | It's planned to use the [https://launchpad.net/software-center Software Center] from Ubuntu, with the recently developed PackageKit backend. The application itself has support for multiple repositories (channels, in apt parlance), including paid repositories, although this is not implemented for Fedora. It can show reviews and automatically fetch screenshots from a server shared by Debian and Ubuntu. All applications are categorized using Freedesktop menu spec, which makes it possible to use the same categories the desktop uses (although currently it uses a different .menu file). | ||
Application metadata is in the [http://distributions.freedesktop.org/AppStream AppStream] format (basically, an XML version of .desktop files), which is then merged with data from PackageKit to build a Xapian database. The database needs to be rebuilt completely for every change, so it is expected that the user will have both primary.xml and appdata.xml locally for the various repos. Probably, the best way to handle this is through a yum plugin, while the actual appdata file would be generated by createrepo. A yum plugin will be needed in any case if we want the software center to handle "technical items" (that is, packages that are not apps), given that softwarecenter use apt's native xapian index for this. | Application metadata is in the [http://distributions.freedesktop.org/AppStream AppStream] format (basically, an XML version of .desktop files), which is then merged with data from PackageKit to build a Xapian database. The database needs to be rebuilt completely for every change, so it is expected that the user will have both primary.xml and appdata.xml locally for the various repos. Probably, the best way to handle this is through a yum plugin, while the actual appdata file would be generated by createrepo. A yum plugin will be needed in any case if we want the software center to handle "technical items" (that is, packages that are not apps), given that softwarecenter use apt's native xapian index for this. | ||
It is unlikely that we want to consider different databases than Xapian, not only because of its unmatched natural text search capabilities, but also because it would mean rewriting softwarecenter from scratch, which is out of scope. We could still have different formats (like pkgdb) to generate the xapian data from. | It is unlikely that we want to consider different databases than Xapian, not only because of its unmatched natural text search capabilities, but also because it would mean rewriting softwarecenter from scratch, which is out of scope. We could still have different formats (like pkgdb) to generate the xapian data from. | ||
Line 33: | Line 36: | ||
== How To Test == | == How To Test == | ||
Go to your desktop app launcher. There should be a prominent "Fedora Software Center" item. | * Go to your desktop app launcher. There should be a prominent "Fedora Software Center" item. Note: the actual name is not yet specified, and it need not open "software-center", it could be apper. | ||
Opening it should reveal a set of featured applications, each with a specific icon, a localized name and possibly a rating. | * Opening it should reveal a set of featured applications, each with a specific icon, a localized name and possibly a rating. | ||
It should be possible to click on each category and see the whole list of app for each category. | * It should be possible to click on each category and see the whole list of app for each category. | ||
Click on a specific app should reveal the details about the package containing it (including description, license, size) and allow to install/uninstall it. For the most common apps, there should be a recent screenshot. | * Click on a specific app should reveal the details about the package containing it (including description, license, size) and allow to install/uninstall it. For the most common apps, there should be a recent screenshot. | ||
If more sources are configured (eg. RPM Fusion), filtering should be possible | * If more sources are configured (eg. RPM Fusion), filtering should be possible. | ||
All installed applications (including packages that are not actually applications, if the option is selected) should be visible | * All installed applications (including packages that are not actually applications, if the option is selected) should be visible in a specific view. | ||
* There should be a "history" view with all previous changes, including those made outside the Software Center. | |||
Searching should work, including by app name, package name, package description. Searching for localized keywords should work as well. | * Searching should work, including by app name, package name, package description. Searching for localized keywords should work as well. | ||
All content should be localized. | * All content should be localized. | ||
== User Experience == | == User Experience == |
Latest revision as of 22:37, 2 December 2011
Fedora Software Center
Summary
The primary way to install applications in Fedora is through the various Packagekit GUIs (gpk-application, Apper). This provide a suboptimal experience, as they're oriented towards packages, rather than applications, and expose various implementation details (repositories, dependencies, comps groups, just to name a few).
Instead, this feature is about building a software installer that is focused on applications, including the actual name and menu position as shown in the Shell/KMenu, the app icon, as well as screenshots and ratings. This system should hide technical details as much as possible.
Owner
- Name: Giovanni Campagna
- Email: scampa.giovanni@gmail.com
Current status
- Targeted release: Fedora 17
- Last updated: 2012-12-01
- Percentage of completion: 10%
- The software center is almost working, given the right metadata and some patches here and there (I'm working to get all of them upstream). A complete design for metadata generation and delivery is still missing. Also, there are issues with icons, which other distro provide in packages but would likely be a problem for space-tight spins.
Detailed Description
It's planned to use the Software Center from Ubuntu, with the recently developed PackageKit backend. The application itself has support for multiple repositories (channels, in apt parlance), including paid repositories, although this is not implemented for Fedora. It can show reviews and automatically fetch screenshots from a server shared by Debian and Ubuntu. All applications are categorized using Freedesktop menu spec, which makes it possible to use the same categories the desktop uses (although currently it uses a different .menu file).
Application metadata is in the AppStream format (basically, an XML version of .desktop files), which is then merged with data from PackageKit to build a Xapian database. The database needs to be rebuilt completely for every change, so it is expected that the user will have both primary.xml and appdata.xml locally for the various repos. Probably, the best way to handle this is through a yum plugin, while the actual appdata file would be generated by createrepo. A yum plugin will be needed in any case if we want the software center to handle "technical items" (that is, packages that are not apps), given that softwarecenter use apt's native xapian index for this.
It is unlikely that we want to consider different databases than Xapian, not only because of its unmatched natural text search capabilities, but also because it would mean rewriting softwarecenter from scratch, which is out of scope. We could still have different formats (like pkgdb) to generate the xapian data from.
Benefit to Fedora
The major benefit is for the general user, who can find and install applications more easily and more beautifully. Also, it clears out the application story, and makes Fedora a more attractive platform for app development and distribution, while bringing it on the same level as the competition.
Scope
A new set of files in each repository, called appdata.xml. A yum plugin for dowloading them and converting to xapian. Building and packaging softwarecenter to provide the UI.
How To Test
- Go to your desktop app launcher. There should be a prominent "Fedora Software Center" item. Note: the actual name is not yet specified, and it need not open "software-center", it could be apper.
- Opening it should reveal a set of featured applications, each with a specific icon, a localized name and possibly a rating.
- It should be possible to click on each category and see the whole list of app for each category.
- Click on a specific app should reveal the details about the package containing it (including description, license, size) and allow to install/uninstall it. For the most common apps, there should be a recent screenshot.
- If more sources are configured (eg. RPM Fusion), filtering should be possible.
- All installed applications (including packages that are not actually applications, if the option is selected) should be visible in a specific view.
- There should be a "history" view with all previous changes, including those made outside the Software Center.
- Searching should work, including by app name, package name, package description. Searching for localized keywords should work as well.
- All content should be localized.
User Experience
Users will find the application installer from the app launcher. From there, they can browse apps by category or search them, then finally install them.
Dependencies
infrastructure and releng need some changes to accomodate metadata
Contingency Plan
If this is not completed in time, we can simply remove the software center from the default installation, and work more for F18.
Documentation
Release Notes
- A new Software Center is provided in F17 to aid casual users with finding and installing applications.