Executive summary: App Manager doesn't provide a way to manage add-ons and associate their packages with apps. Instead, they appear in the listing with full apps. This leads to bloated, long listings of apps to install that contain non-apps.

Edit: Please read the explanation at the brainstorm page first, as that is the later evolution of this first post into an actual brainstorm proposal.

The reason for moving this from Development to Brainstorm is that

• it became clear that few developers who frequent the forum had any comments. This may be in part due to the fact that it is somewhat out of "our" hands.
• this is a general UI issue as much as it is a technical issue, thus requires input from more than just developers.
• it will require significant community consensus, backing, and effort to get the best solution to this to happen because it requires changes to a Nokia-controlled app as well as support by app maintainers. Please show your support for a proposed solution by voting for it and be prepared to code and/or implement the needed changes in the packages you maintain and/or make a lot of noise to get this added by the Nokia devs. Squeaky wheel gets the grease and all that...

If a considered, coherent, and complete solution for this issue is not implemented soon, it will be too late to save Fremantle from app manager madness and this will become another one of those "fixed in Harmattan" blots.


The problem

I've packaged up a few different games for maemo now and almost invariably run into the same problem: there's a huge gap between a full-fledged /user app that shows up in HAM's (Hildon App Manager) listing and, well, anything else. I'd like to know what methods others are using to close this gap, and perhaps discuss a wiki/guideline/brainstorm/best practices approach if there seems to be use in it.

It seems that using debian packages and related utilities is the obvious way to deliver these parts; the interface is where the problem arises.

HAM: Museum or Library?

When i open up HAM, i want to visit the Museum of Maemoware: to be able to browse through a list of complete, independent apps for my device. I suspect that is what most users also expect. This means that making every add-on and optional part of apps visible is going to be overwhelming and unwieldy to the end user, and render the UI useless. Even the number of packages in -devel right now is approaching overload given the current granularity of package cataloging.

Someone might offer an argument that HAM is actually intended to be a library, not a museum: simply an interface to the repo. Whether that's what "maemo" had in mind for it, i don't know, but i don't think that's what most people expect from it, even if it needs to serve that role, too.

Examples

Let me give a couple examples. UQM is a classic game that has (in debian) a binary package and various data packages. One smallish data package is required for the game to function. The other two larger ones are completely optional, but add substantially to the user experience.

In this case, i made the required data package a dependency of the game package, and put the other two packages together in a massive 130 MB package that shows up under Games in HAM along with the binary package. The user can add or remove this content at any time, as it should be, but it's also hanging out there for all to see, even those who don't have uqm installed. This has the additional pathological problem of testing (10 tests for a package with a single large data archive in it?), because all packages that show up in HAM (rather than just being installed as dependencies) have to go through Extras-testing.

Case 2: Doom. Prboom is one of several doom engines that could be ported to fremantle. The variants actually have fairly different capabilities (e.g. strong multiplayer capabilities, faithfulness to the original game feel, etc.) and there could be a user who would want to install more than one. These would (possibly) use the same (independent, optional) data files. Just as with uqm there are multiple data files and each is optional, and this time optional for a number of apps.

Solutions

The process of organizing my thoughts for this has made the ideal solution seem clear to me, but it's not an immediately available solution and the exact implementation details aren't important at the moment. Add a user/optional category or hierarchy of package type. Packages of this type only show up in HAM when they Provide a virtual package that is Required, Recommended or Suggested (the latter two are debian control file directives that are AFAIK currently ignored by HAM) by currently installed apps. There is the whole meta package arrangement that could assist with organizing this.

How the user would browse to the options isn't that important for the moment, but i can think of a few possibilities including showing the original app icon/entry but with an overlay on it to indicate that it will bring up an options installation menu. The options could also be given (in a list with checkboxes) in the installation dialogue for any main app package in HAM, so the user is aware of them and can install them along with the main app.

This could handle everything from small mods such as alternative config files to data to plugins without cluttering up the HAM UI and without requiring command line installation of any files. It would also alleviate the -testing conundrum, as the requirements for user/optional packages could be reduced. (They can't be installed without one of the full-class user apps that they are listed under, and that one has to go through full testing.)

What do you think?

In the meantime, what's the best way to do this? Having some extra menus and network code in the app to download data is a waste of developer time and not a consistent UI. Actually, it seems like a bad idea in many ways: it can't use apt-get or dpkg because it's not running as root, and it can't install into the program directory without modifying the default debian installer behavior to change the owner of the directory when the main app is installed...

There are script options during installation to let a user choose optional packages, but that doesn't let them add things later, or remove them later, etc.