GNOME Bugzilla – Bug 765268
Bundled, helper apps
Last modified: 2018-01-24 17:05:26 UTC
Some projects provide a main app and one or more related helper apps. For example, GCompris and its admin tool. In a package based scenario, it's easy to just generated different packages for the main app and helper app(s) as dependencies will keep them compatible. However, in an xdg-app scenario those should instead be inside the same bundle because: 1) there are no dependencies between xdg-apps so there'd be no way to maintain a helper app compatible with its main one; 2) if helper apps need to change some files that belong to their main app, then having in a different sandbox is not right. Taking into account how the above may create two desktop files for the same app, maybe we should have a way to show those helper apps in their main app's details page, and allow the user to launch them from there. In terms of code/appstream such helper apps could be "detected" by being of kind desktop and extending another app. In terms of UI, I am thinking that we could have a section in the main app's details page called "Provides" (or something much better than that) and the info of the helper apps, with their icon, description and launch button. The main motivation for having this feature is that it makes it easier for users to discover these helper apps since they will know about them from the place they chose to install the main ones, instead of having to find them in their desktops which is less direct.
Adding design folks to the loop.
(In reply to Joaquim Rocha from comment #0) > Some projects provide a main app and one or more related helper apps. For > example, GCompris and its admin tool. Honestly this sounds like terrible application design and not something particularly interesting to be worked around in Software. Are there any other applications where this issue exists?
if there needs to be a separate admin app, just add an item to the app menu for "Administer" or something like that. I don't think this belongs in the application installer.
iOS has been offering bundled apps for a year or too. It makes some sense because they offer a bundle of apps that work well together or are from the same developer and discount the bundle off the total price. That makes sense there because the apps (usually) cost money so bundling them at a discount provides a benefit and an incentive to the user. example: https://www.dropbox.com/s/vddt7nvif7ax99k/Photo%20Apr%2021%2C%2011%2019%2043%20AM.png?dl=0 If the apps are free there is less benefit to bundling the apps. I do think it is helpful to point users to related apps, or apps that work well together. Maybe there can be a related apps or developer apps section in the App Detail page? examples: related: https://www.dropbox.com/work/EM_EOS/app_center_migration/2_material/research/References/app_bundles?preview=Photo+Apr+21%2C+11+19+47+AM.png apps by same develper: https://www.dropbox.com/work/EM_EOS/app_center_migration/2_material/research/References/app_bundles?preview=Photo+Apr+21%2C+11+20+22+AM.png There are some issues with this experience in iOS, but I have found it useful. Often when I really like a particular app I am curious to see what other apps have been made by the same developer because chances are I might like them or find them useful. It could be nice to surface this information instead of just providing a link to the developers website, leaving it to the user to search for related apps themselves.
Bundling multiple .desktop files may or may not be "terrible design," but it *is* a fairly common one. The LibreOffice team, for example, provides one flatpak for all applications in the office suite. And the RPM version of plenty of applications in Fedora include multiple .desktop files -- for example the Calibre ebook management suite (provides multiple binaries from a single package), and the Phatch batch photo processor (package provides only a single binary, but two .desktop files where the Exec tags use different command line options).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-software/issues/52.