Re: What category should network filesystems like OpenAFS go under?
Hi, ext Mike Lococo wrote: But I do think that there should be a category specifically for command line tools so that people who do not use the command line don't have to waste time on them. And I also agree that a GUI configuration dialogue for a system tool is much better than expecting someone to edit a config file. This stikes me as a similarly flawed approach. Terminal-based applications have the same range of functionality that graphical applications have, so you either need to duplicate your category list in two places (and force users interested in both types to look twice), or you stop categorizing terminal-apps altogether (and leave users that use them with the bad categorization problem we have now). Some alternate approaches... - Standard labels: A -cli suffix at the end of each app name would allow users to quickly recognize and skip terminal apps if they aren't interested in them. Even just including a note in the description would be sufficient in my mind. Most of these packages come unmodified from Debian, so changing the package name is not really good solution. Having this in description is even worse, AM couldn't filter them out for normal users (aunt Tilly). - Debtags-based searches: Give AppMgr a real search facility, and ship canned-queries like graphical apps, terminal apps, etc. - Advanced-Browsing mode: With proper package classification and the existence of extras-devel to hide truly dangerous apps, red-pill (or something similar) could be made into a more discoverable advanced browsing mode that hides end-user apps that are likely to be uninteresting to grandma-types that folks seem so concerned about. Give it a normal preference checkbox, and have it do some debtag or other magic to hide complicated stuff, while making it easy and safe for users who want to see the full range of available software. I do think any binary solution like this which is aimed at hiding apps that are too hard will ultimately prove to be unscalable and unhealthy for the community, which depends on folks discovering challenges which interest them and choosing to learn something new. If the binary filtering is at least easy to disable/ignore, as proposed above, the damage will be minimal though. Showing by default only packages with certain tags and having some UI for configuring which to show sounds fine to me, but upstream Debian compatibility should be kept in mind when designing this (which tags to use, propagating tag changes back to Debian etc). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What category should network filesystems like OpenAFS go under?
Hi, ext Andrew Flegg wrote: On Fri, Nov 7, 2008 at 10:47 PM, tz [EMAIL PROTECTED] wrote: This is a problem since there may be various enhancements which are part of an EXISTING interface. Consider media codecs like ogg support If an ogg support package instantly provides ogg capability in existing media players, without any further configuration; no further GUI is required and it can go directly in user/multimedia. Problems should be solved properly, not with user unfriendly kludges. How aunt Tilly would know which codec package to install? For the media codecs, the device should detect that a currently unsupported codec is needed and ask user whether one should be downloaded. filesystems. Or for example I ported WebDav so I have access to my mac.com idisk from my tablet. I could write a trivial user/password popup, but that is the tail wagging the dog. No, it's not wagging the dog. If a user needs to open a terminal, create a configuration file and run something from the command line; I *strongly* believe it's outside the scope of the Application Manager. Since there's a requirement to use the terminal to configure it, it is no extra step to require the user to use apt-get to install it. Agree. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What category should network filesystems like OpenAFS go under?
Marius Vollmer wrote: ext Mike Lococo [EMAIL PROTECTED] writes: - Debtags-based searches: Give AppMgr a real search facility, and ship canned-queries like graphical apps, terminal apps, etc. I like this best. I'm cool with this as long as I can put openafs in some reasonable category and install it without resorting to apt-get on the command-line. Jason ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What category should network filesystems like OpenAFS go under?
On Saturday 08 November 2008 19:28:57 Mike Lococo wrote: This stikes me as a similarly flawed approach. Terminal-based applications have the same range of functionality that graphical applications have, so you either need to duplicate your category list in two places (and force users interested in both types to look twice), or you stop categorizing terminal-apps altogether (and leave users that use them with the bad categorization problem we have now). Good point. I withdraw the suggestion for a category for CLI tools. I like your suggestion of standardising on some debtags to indicate a CLI tool as I am hoping that, one day in the future, AppMgr will gain a debtags search function. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What category should network filesystems like OpenAFS go under?
On Sat, Nov 8, 2008 at 2:02 PM, tz [EMAIL PROTECTED] wrote: If the whole application manager apt-get dists debian system is going to be so brittle that the only SAFE way to get an application on to your system is with Application Manager in blue-pill mode, then there should be a user/cli category or something. apt-get upgrade wont break your system if you're not fetching from every insane repository you can find. An apt-get dist-upgrade, on the other hand, will break things when it pulls in coreutils if you have the SDK repository enabled, but Nokia is very clear about that not being intended for the device. Red Pill and SDK repos are a misdirection, please leave them out of this discussion, as they aren't relevant here. The question is: Should console-only applications be sorted into a user/-prefix category? Yes, but the distinction should be between root and non-root packages. Stuff like SSH, nano, rootsh, zip/unzip, irssi, etc.--clearly user-oriented applications should appear in user/*, but stuff like bluez-utils-test, and developer-oriented stuff really shouldn't. Again, if you've got issues with the setup of the SDK repo, or your particular decisions regarding dependencies, then those are separate issues than whether certain system and CLI packages should be user-visible. Either get the Tools repo moved to Extras, or upload the dependencies you need yourself, but don't be user-hostile by trying to solve these issues breaking the categorization. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What category should network filesystems like OpenAFS go under?
ext Mike Lococo [EMAIL PROTECTED] writes: - Debtags-based searches: Give AppMgr a real search facility, and ship canned-queries like graphical apps, terminal apps, etc. I like this best. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What category should network filesystems like OpenAFS go under?
On Saturday 08 November 2008 08:56:28 Andrew Flegg wrote: No, it's not wagging the dog. If a user needs to open a terminal, create a configuration file and run something from the command line; I *strongly* believe it's outside the scope of the Application Manager. Since there's a requirement to use the terminal to configure it, it is no extra step to require the user to use apt-get to install it. I see your point but I don't quite agree. Xterm is a standard part of the tablet and I think command line utilities have a place in AppMgr. An obvious example is ssh! And possibly most of the applications which will go into the developer tools category. I don't think we really want to be encouraging people to use apt-get, particularly while apt-get upgrade can break your system. But I do think that there should be a category specifically for command line tools so that people who do not use the command line don't have to waste time on them. And I also agree that a GUI configuration dialogue for a system tool is much better than expecting someone to edit a config file. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What category should network filesystems like OpenAFS go under?
On Fri, Nov 7, 2008 at 10:47 PM, tz [EMAIL PROTECTED] wrote: This is a problem since there may be various enhancements which are part of an EXISTING interface. Consider media codecs like ogg support If an ogg support package instantly provides ogg capability in existing media players, without any further configuration; no further GUI is required and it can go directly in user/multimedia. filesystems. Or for example I ported WebDav so I have access to my mac.com idisk from my tablet. I could write a trivial user/password popup, but that is the tail wagging the dog. No, it's not wagging the dog. If a user needs to open a terminal, create a configuration file and run something from the command line; I *strongly* believe it's outside the scope of the Application Manager. Since there's a requirement to use the terminal to configure it, it is no extra step to require the user to use apt-get to install it. If there's a GUI configuration, and it can be started either manually or automatically without having to open a terminal; it can go in user/system (for WebDav and OpenAFS) and be visible in the Application Manager. There needs to be at least one category visible (sans red-pill) in the application manager for system enhancements which do not have something DIRECTLY visible to the user. I agree: as long as the user is not REQUIRED to use terminal to do anything with it. Cheers, Andrew -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ maemo.org Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What category should network filesystems like OpenAFS go under?
I would have to agree with Graham's point. If the whole application manager apt-get dists debian system is going to be so brittle that the only SAFE way to get an application on to your system is with Application Manager in blue-pill mode, then there should be a user/cli category or something. Having something that is otherwise useless without doing CLI interaction is different than something that is specifically useful on the CLI itself. If I port Kismet, it might automatically open an Xterm from a script, but it will run in text mode until a GTK frontend or something else is done. And some things are diagnostic that you want to be available for when something does go wrong. You can't possibly build everything into the apps or add enough things on. The problem is that INVISIBLE EQUALS UNINSTALLABLE and VISIBLE EQUALS USER/* as far as the Application manager is concerned. Well, not quite, but I can't create an X.install file or anything else except an isolated .deb if it is not in user/* Since there is no clean way of doing this, either user/whatever gets cluttered up with a bunch of things simply to make them safely installable, or everyone uses apt-get, dpkg, or red-pill mode and breaks their tablets, or you create junk meta-packages that install a very short doc file but depend on the real file solely for the purpose of pulling that file in. Right now all three manners of ugliness are being used, and I think there have been enough pleas to get it fixed. The worst possible outcome is for whatever reorganization, refactoring, etc. to happen and yet we will still be stuck with all three hacks after it was supposedly fixed. Call it user/advanced, user/powertools, user/dangerous or whatever, or create a second major category to make things visible and safely installable, poweruser/*, etc. or something. Let them be disabled by default like Extras is now, but so that it can be turned on. On Sat, Nov 8, 2008 at 5:29 AM, Graham Cobb [EMAIL PROTECTED] wrote: On Saturday 08 November 2008 08:56:28 Andrew Flegg wrote: No, it's not wagging the dog. If a user needs to open a terminal, create a configuration file and run something from the command line; I *strongly* believe it's outside the scope of the Application Manager. Since there's a requirement to use the terminal to configure it, it is no extra step to require the user to use apt-get to install it. I see your point but I don't quite agree. Xterm is a standard part of the tablet and I think command line utilities have a place in AppMgr. An obvious example is ssh! And possibly most of the applications which will go into the developer tools category. I don't think we really want to be encouraging people to use apt-get, particularly while apt-get upgrade can break your system. But I do think that there should be a category specifically for command line tools so that people who do not use the command line don't have to waste time on them. And I also agree that a GUI configuration dialogue for a system tool is much better than expecting someone to edit a config file. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What category should network filesystems like OpenAFS go under?
Since there's a requirement to use the terminal to configure it, it is no extra step to require the user to use apt-get to install it. snip I don't think we really want to be encouraging people to use apt-get, particularly while apt-get upgrade can break your system. Absolutely agree. While I understand the impetus to save users from having to wade through lots of apps that don't interest them, handling the installation of some applications very differently than others is a non-scalable approach to the problem. But I do think that there should be a category specifically for command line tools so that people who do not use the command line don't have to waste time on them. And I also agree that a GUI configuration dialogue for a system tool is much better than expecting someone to edit a config file. This stikes me as a similarly flawed approach. Terminal-based applications have the same range of functionality that graphical applications have, so you either need to duplicate your category list in two places (and force users interested in both types to look twice), or you stop categorizing terminal-apps altogether (and leave users that use them with the bad categorization problem we have now). Some alternate approaches... - Standard labels: A -cli suffix at the end of each app name would allow users to quickly recognize and skip terminal apps if they aren't interested in them. Even just including a note in the description would be sufficient in my mind. - Debtags-based searches: Give AppMgr a real search facility, and ship canned-queries like graphical apps, terminal apps, etc. - Advanced-Browsing mode: With proper package classification and the existence of extras-devel to hide truly dangerous apps, red-pill (or something similar) could be made into a more discoverable advanced browsing mode that hides end-user apps that are likely to be uninteresting to grandma-types that folks seem so concerned about. Give it a normal preference checkbox, and have it do some debtag or other magic to hide complicated stuff, while making it easy and safe for users who want to see the full range of available software. I do think any binary solution like this which is aimed at hiding apps that are too hard will ultimately prove to be unscalable and unhealthy for the community, which depends on folks discovering challenges which interest them and choosing to learn something new. If the binary filtering is at least easy to disable/ignore, as proposed above, the damage will be minimal though. Thanks, Mike Lococo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What category should network filesystems like OpenAFS go under?
This is a problem since there may be various enhancements which are part of an EXISTING interface. Consider media codecs like ogg support, or filesystems. Or for example I ported WebDav so I have access to my mac.com idisk from my tablet. I could write a trivial user/password popup, but that is the tail wagging the dog. There needs to be at least one category visible (sans red-pill) in the application manager for system enhancements which do not have something DIRECTLY visible to the user. user/ category should be used only by packages that provide user something visible; has an UI, can be started from the applications menu etc. Anything else should come as dependencies of such packages or be installed with apt-get from command line. Maybe there could be additional developer/power-user category which visibility can be toggled from AM options (without resorting to the red-pill hack), but such packages shouldn't be visible by the default, they just confuse normal users. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What category should network filesystems like OpenAFS go under?
Hi, ext Andrew Flegg wrote: I need to upgrade the OpenAFS package. The package is in the user/support category. Is that the right category? It's a network filesystem. Should it be under support, network or some other category. Feedback on this or any other part of the package is welcome. This is currently in flux, see: https://wiki.maemo.org/Task:Package_categories The Maemo Packaging Policy does not currently have a user/network category; the closest being user/communication or user/support. Neither fulfill the purpose very well (hence the new rationalisation). Personally, I'd stick with user/support for now and move it to a better category when the new categories are decided upon. user/ category should be used only by packages that provide user something visible; has an UI, can be started from the applications menu etc. Anything else should come as dependencies of such packages or be installed with apt-get from command line. Maybe there could be additional developer/power-user category which visibility can be toggled from AM options (without resorting to the red-pill hack), but such packages shouldn't be visible by the default, they just confuse normal users. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What category should network filesystems like OpenAFS go under?
On Mon, Oct 27, 2008 at 8:05 AM, Eero Tamminen [EMAIL PROTECTED] wrote: [snip] user/ category should be used only by packages that provide user something visible; has an UI, can be started from the applications menu etc. Anything else should come as dependencies of such packages or be installed with apt-get from command line. Indeed. A point well worth making, I had assumed (perhaps mistakenly) that the OpenAFS packages would provide a GUI configuration. Cheers, Andrew -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ maemo.org Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What category should network filesystems like OpenAFS go under?
Andrew Flegg wrote: On Mon, Oct 27, 2008 at 8:05 AM, Eero Tamminen [EMAIL PROTECTED] wrote: [snip] user/ category should be used only by packages that provide user something visible; has an UI, can be started from the applications menu etc. Anything else should come as dependencies of such packages or be installed with apt-get from command line. Indeed. A point well worth making, I had assumed (perhaps mistakenly) that the OpenAFS packages would provide a GUI configuration. Eventually, I would like to have a GUI config tool, but it has yet to materialize. Jason ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
What category should network filesystems like OpenAFS go under?
Hi all, I need to upgrade the OpenAFS package. The package is in the user/support category. Is that the right category? It's a network filesystem. Should it be under support, network or some other category. Feedback on this or any other part of the package is welcome. Thanks, Jason ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What category should network filesystems like OpenAFS go under?
On Sat, Oct 25, 2008 at 8:36 PM, Jason Edgecombe [EMAIL PROTECTED] wrote: I need to upgrade the OpenAFS package. The package is in the user/support category. Is that the right category? It's a network filesystem. Should it be under support, network or some other category. Feedback on this or any other part of the package is welcome. This is currently in flux, see: https://wiki.maemo.org/Task:Package_categories The Maemo Packaging Policy does not currently have a user/network category; the closest being user/communication or user/support. Neither fulfill the purpose very well (hence the new rationalisation). Personally, I'd stick with user/support for now and move it to a better category when the new categories are decided upon. HTH, Andrew -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ maemo.org Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
