[maemo-developers] Beyond Application Manager Categories

[From: tz]

You could run something on maemo.org that would produce an app list in
multiple forms with all the extra data n the BROWSER, then a keyed
installation target for the app manager which would "do the right
thing".

This would require a small new API to the app manager that would allow
it to do an install of something it already has in the index, but then
would offload the fancy formatting and parsing to a periodic task on
the server and create static pages instead of having to do complex
things from within app manger.

Meanwhile, could someone get the following things copied from the
tools or sdk into where they are directly visible, perhaps
user/utilities
(feel free to add to the list)

bluez-utils-test (I really need l2ping and rfcomm)
less (I use the added features over "more" and am used to typing this
to view files)
strace
wget
nano and/or nano-tiny
tcpdump
traceroute
wget

These are all released and well debugged, and I could duplicate some
(but not all) of the functions by writing something for extras, but
why not use what is already there.

On Fri, Nov 7, 2008 at 10:01 AM, Andrew Flegg <andrew at bleb.org> wrote:
> On Fri, Nov 7, 2008 at 2:37 PM, Simon Pickering
> <S.G.Pickering at bath.ac.uk> wrote:
>>
>>> As a thought experiment, could we remove the "Browse installable
>>> applications" button from the AM and get by with just
>>> downloads.maemo.org?  Should we work on better integration?
>>
>> Definitely not until the browser works faster and it's easier to click
>> links. For me, AM is far quicker and less frustrating than having to browse
>> that site (slowly) and click the little links.
>
> Absolutely agreed. I've no problem with the AM providing a more
> compelling and rich UI (almost like an App Store or
> downloads.maemo.org), but the browser itself is such a long way from
> that (as is downloads.maemo.org, if we're honest) that the two
> interfaces are required.
>
>>> There is another angle: many applications are extensible with plugins
>>> and add-ons, etc.  There is a lot of potential there to simplify
>>> juggling with these packages.  For example, there is no point to even
>>> show the pidgin-l10n-klingon package if you don't have Pidgin
>>> installed.
>>> This add-on management is probably a bit hard to do for a portal site
>>> like downloads.maemo.org.  But the current AM is not much better.
>>
>> We spoke about this before (not sure whether it was on the list or not, does
>> anyone have a link - Jaffa?)
>
> I *think* it was on IRC, when I was suggesting somehow only showing
> sub-packages when the parent was installed. You responded...
>
>
>> I would like to be able to see what plugins an app has before installing
>> it. I might want to see if Pidgin has current support for Gadu (or any
>> other protocol, etc.)
>
> ...which makes perfect sense as a requirement.
>
> So, I'm convinced that all plugins should be viewable without
> installing the app. And I don't want `n' different apps with `n'
> different UIs for installing plugins[1].
>
> My current idea here, from a UI point of view is:
>
>  * Category list changes from large buttons to a list, *exactly* like
>    the package list; with icons, descriptions and the "size" being the
>    count of packages contained.
>
>  * The package list supporting sub-categories which should match on a
>    package name (this can then show the fuller name, if available).
>    Sub-categories should not be used to create an expandible tree: only
>    for grouping packages related to a single overall package.
>
>  * The sub-categories in a package list would look the same, and
>    use the same code, as the top-level view; tidying up the AM source
>    a little and giving a more consistent UI.
>
> How we then encode that sub-categorisation is unclear. One suggestion
> I had was to continue along the existing `Section' approach, as this
> then allows for *developer* consistency:
>
>    https://wiki.maemo.org/Task:Package_categories#Application-specific_subcategories
>
> Cheers,
>
> Andrew
>
> [1] Although, I can imagine it would be useful for an item on an app's
>    menu to open AM at a particular subset of packages (i.e. the plugins
>    for that app).
>
> --
> Andrew Flegg -- mailto:andrew at bleb.org  |  http://www.bleb.org/
> maemo.org Community Council member
> _______________________________________________
> maemo-developers mailing list
> maemo-developers at maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>