> Sorry, no patch yet - I'm running late for once and haven't been > keeping up with revisions. [...] > Given that there's no guarantee that its previous state is "enabled", > I think this should be: > > __Choices: enable, disable, lock I think that almost everytime this configuration process is triggered with questions shown to the user the previous state will be "enabled", but you are the specialists > > | _Description: Choice for downloads of new data by kstars users: > Could we make that something like > > _Description: User data downloads for kstars: > | By default, unless the feature is locked or disabled, each user will be > | able to enable data downloads. > | . > | If you choose "keep enabled", users will be able to download data > | files. If you choose "disable", each user can re-enable data download > | (for instance to download data from other catalogs than Tycho2). If > | you choose "lock", no user can enable data downloads. > > Well, the "by default" part is true if there's no config, but the > default *here* is "lock". Perhaps start from describing it as a > feature of KStars: > > KStars has a download feature allowing users to download extra data > files for their own use. Since packaged catalogs can be handled more > efficiently by installing a single central copy, you may wish to > restrict the use of this feature. > . > * enable - users will be able to download data files; > * disable - individual users can re-enable data downloads (for > instance to download data from other catalogs); for instance to download other datafiles > * lock - users cannot enable data downloads. > > (Oh, handily I've anticipated the s/Tycho2//.) Cool, i very much liked this rewording. Should we say that "individual users can re-enable data downloads _by tweaking their .kstarsrc files_"? > [...] > Then the package description: > > -Description: Tycho2 star catalogue for centralized install of KStars > > It isn't a "centralized install of KStars"; in fact I can't find an > accurate explanation that fits in the synopsis, so save it for the > long description. Oh, and google tells me "Tycho-2" with a hyphen. I thought about a typical use case (the one that twice triggered me to create this package): a computer room, where installation of packages is centralized on the sysop > > +Description: Tycho-2 star catalog for KStars > [...] > > The "download it" is inaccurate, since KStars wouldn't offer to > download this .deb file. KStars offers each user to download the datafile, not the .deb file. The .deb provides just that datafile (and some surroundings as this configuration). > > If this package can configure whether I want something, I don't want > it anywhere near me. > Quite true :) > How about: > > + This package contains the data of the Tycho-2 star catalog for KStars, > the + desktop planetarium for KDE. It allows users to use a central shared > catalog + instead of each needing to download their own personal copy of > the whole + catalog. It can also configure KStars to disable these user > downloads. I like it Noel
Attachment:
signature.asc
Description: This is a digitally signed message part.