Extend .info file

[roberts]

I seeded keyword four months ago with v4.0 with no discussion or data ensued.
Therefore when there is data to process the code will be updated.

[vinnie]

um I do not understand fine, we do a poll like this?

opt1: do anything
opt2: link "keyword" search in a new field in .info
opt3: link "keyword" search in a new field in .info and in first line of description for the time required for the info are all adequate
opt4:...proposals in this topic to other users

?

[combo3]

I'm confused as well.

Using edna.tcz (my extension) as an example, the description reads:

Edna lets you access your MP3 collection from any networked
computer with a media player that supports streaming audio.

... which is fairly descriptive, but because it takes up two lines, the "Keyword"
search only parses the first line. (Previously the search function parsed the entire info file)

So should I stick everything on one line (forcing the user to scroll horizontally), condense the description, or add another "Description:" header on the second line?

[Guy]

combo3

Add an additional line just for listing keywords - not in a sentence.

[Guy]

I think most people agree it is a good idea to have an additional line for searching keywords.

Just that no decision has been made as to what to call the new line.

It could be

tag
tags
keyword
keywords
category
categories

Others may even have other ideas. If you have other ideas, please share them.

Then let's make a decision to decide what to call the new line.

Then it can be implemented.

[Guy]

I like categories.

[bmarkus]

I like categories.

Category means a fixed predefined list and a bit misleading one can relate it to freedesktop.org menu categories. Tag means more flexibility and it has a known meaning for most new users.

[vinnie]

also for this decision would be helpful to have a poll (since I prefer keywords for an issue of retroactive coherence)

[Guy]

In addition, I think there should be the option to list only apps, not dependencies.

I know some apps are dependencies of other apps. They can still be listed as apps.

There are many different ways this can be done.

One method would be to add an extra line calling it "app or dep:" Then the option to list only apps can be implemented.

There are also many other ways this could be done.

What are the thoughts of others?

[Guy]

I think the tag - keyword - category thing is a good idea.

bmarkus, do you want to set up a poll?

I suggest include "other" and let them say what it is, in case someone thinks of a good idea.

[vinnie]

What are the thoughts of others?

technically could be useful, but I do not know if it is necessary.
another much simpler method would be to use the tag library or software in new field for tag.
this if we can find more than one keyword at once (now it is impossible):

[mocore]

In addition, I think there should be the option to list only apps, not dependencies.
....
What are the thoughts of others?

+1
 this would be a useful addition

both tag/keword(or what ever its named) and app/dep filter
give opportunity to reduce large list(set?!)
into a smaller more human friendly sized collection ,
 this sort of 'filtering'
should make finding relevant items from the repo simpler

a filter for extensions that simply used the first letter of the extension name  ( currently this falls within  [A-Za-z0-9]  )
 could also have similar benefit of giving user smaller collection to select from
 

[vinnie]

I hear the footsteps of a mammoth 

[roberts]

And here I thought TAGS was to be the field name. Is this what you call design by committee?
If my prior post was confusing, what I meant is that appbrowser keyword search will be revisited, if and when there is actual data to be processed, i.e,, the "new field" exists and is populated in the repo.

[Rich]

And here we are, very much like a bunch of bureaucrats, who need to come to an agreement. Rather than just
sitting down together and resolving their problems, they first need to argue about the shape of the table they
will sit at.
The field merely serves as a way of sorting a big list into a smaller one. Which acronym it is named as is not very
relevant. It is the end users responsibility to read the info tab, and since the field will be visible there, I think its
purpose will be clear. One good point that I think vinnie made indirectly is that the text in the button in the dropdown
at the top of AppBrowser should match match the name of the field (tags, keywords, whatever).
The way I see it, there is no reason why roberts would or should modify a single line of code to implement this
change until some agreement is reached on a clear path forward.
For starters, since roberts will most likely do the coding, I propose we let him decide what field name he wants to
parse for, we accept it, and sit down at the table and move on.