Extend .info file

[bmarkus]

Reading all comments I'm more convinced that the way is to add 'Tags: ...' line to info and to add search to AppBrowser.

The single description line is not for tagging. It is for description, to give a short verbail description what the package is for. Tagging is different stuff, but I already explained why proposal was made.

As an extension maker I will never put tags to description due to above reason as it breaks the original concept of .info and if used for tagging makes it worst. There is a reason, why it is not used for this.

For sure, a single 'Tags: ...' would be much widly used by extension creators and wouldn't break existing system. Only change required is to add search in to AppBrowser. Takes time to accept? For sure. As all change. But would help.

[roberts]

+1 as shown in post 1 of this thread.
A single Tags: line just before Comments would be ideal as it appears not to break any existing code.

[vinnie]

You could make the search "keyword" has two alternatives:
- if exist the field "tags" in the .info file the search is done them
- if does not exist filed "tags" the search takes place as is currently

if this could be cumbersome in alternative keyword may search simultaneously in both fields (up to when you will feel sufficient the presence of the field tags in the packages repository, thereafter you may drop the search for keywords on description field).

I believe that if you do not encourage the use of this new field will never be adopted.
 
Secondly, the introduction of "keywords" type of search has also changed the function of the normal "search" making it less "effective", this is good (even if I think it should be allowed to search for partial part of name) but "keyword" search must compensate otherwise the overall result was obtained is not positive.

Edit:

+1 as shown in post 1 of this thread.
A single Tags: line just before Comments would be ideal as it appears not to break any existing code.

+1 also for me!

[coreplayer2]

Appbrowser has had the keyword search for some time now, maybe not everyone is aware of the existing feature? 

I really like the "Keyword" and "Search" features  they work as intended, no problem there.   The issue as I see it is simple, folks will use different keywords to describe the same app so unless all the numerous possible variations are included as keywords in the info file some if not all applicable apps will never be detected.

eg:  Lets say I'm looking for a text editor, I'm lazy so my first search will be "text" which yields many results, many email clients etc, not exactly what I am looking for so expanding on the search I'll type "editor" but still not all text editors are included,  next we try "text editor" things are looking up! we have narrowed down the search, but an mp3 player? what..    Maybe I know of an editor but just can't remember the name, yet I still can't find it in the results..   I could choose Geany, unfortunately the most full featured editors still have failed to be found.

I'm not picking on a specific app here, knowing how to search is a valid argument.  However much like a web site, if you want your site to be found provide as many keywords as possible which describes the product.   I think most folks would give up before trying these keywords  "Office" or "Processor"   Which indeed would produce results not yet seen by either "text" or "editor", perhaps even the app I've been looking for.

My point is;  currently a search will rarely yield 'all' applicable apps, some but definitely not all.     Keywords can be added apparently anywhere in the info file since the whole file is read,  However a keyword field might serve as a prompt to add keywords.?

Tag, keyword, sounds like a plan.  Though Keyword is consistent with the search feature.   

[Rich]

Hi coreplayer2

However much like a web site, if you want your site to be found provide as many keywords as possible which describes the product.

That is about advertisers trying to get your attention, this is about finding what you are looking for.
A shotgun approach is not very efficient, and the individuals creating the keyword fields should not
have to anticipate every possible keyword that might be used. Not to mention the search function
would have to look at all those keywords for every application. The search function should not be
about trying to find that perfect application for you, rather it should be about returning a reasonable
list of applications relevant to your search. Two of Tinycores attributes are that it is small and fast.
There is no reason why a search function can not follow that same model. By making the first keyword
a SUBJECT (or CATEGORY) you quickly eliminate applications not relevant to your search. The FUNCTION
(or CAPABILITIES) keywords would be used to narrow that search (see reply #6). A suggested list of
keywords organized by SUBJECT (or CATEGORY) and FUNCTION (or CAPABILITIES) could be listed on
the wiki. This would serve to guide the user how to find an application and guide the maintainer as to
which keywords to include.

[mocore]

+1

Reading all comments I'm more convinced that the way is to add 'Tags: ...' line to info and to add search to AppBrowser.

thanx for making tags suggestion !
fyi i have been convinced even before you post some sort of taging system will be a good thing

[curaga]

I suppose we should pick some existing standard for the tags, maybe the freedesktop categories?

http://standards.freedesktop.org/menu-spec/1.0/apa.html

[vinnie]

I suppose we should pick some existing standard for the tags, maybe the freedesktop categories?

http://standards.freedesktop.org/menu-spec/1.0/apa.html

I think it's too limiting, I think it's best to let everyone enter the keyword that it considers most appropriate

[bmarkus]

I do not like freedesktop.org categories. In practice extensions are using only main categories which are too less. However there must be guidelenes otherwise  it will be useless. For example a command line tool will be tagged as cli, console, commandline, etc.

[Rich]

Hi bmarkus
Thank you, that's basically what I was going to say, but you were to quick for me.
I spent some time looking through AppBrowser and made up the attached file as a possible starting
point. It's not perfect, and some things could probably be placed better, but for the most part it tries
to remain fairly generic to minimize the number of search terms.

[hiro]

Personally I won't change my .info files,, as I implied earlier I feel there's hardly any value in this complication.

[vinnie]

I do not understand, because you are creating a list of tags?
not enough that there is a field called "keywords" or "tags" to function as it currently operates search type "keyword" in the first line of the description?

[bmarkus]

I do not understand, because you are creating a list of tags?
not enough that there is a field called "keywords" or "tags" to function as it currently operates search type "keyword" in the first line of the description?

Read previous posts

[vinnie]

but if I want to add a tag that is not in the list as I do?
Sometimes there are programs that deserve more characterization.

I do stupid example, i love turn tactics game, but most if not almost everyone uses category "strategic game" to label, example: http://standards.freedesktop.org/menu-spec/latest/apa.html

1) strategic != tactics
2) turn != realtime

I assure you that I do not like strategy games in real time!

This can apply to every specific areas where maybe only those who are passionate understands the difference; however, we are all able to say that the subject of the example is it's a game, I do not need someone showing me a list.
This is the same for macro categories like editor, video, audio, emulator...

Now if the list of tags is intended to be an addition to the possibility of putting keyword ok, but if it replaces I do not like it.

[hiro]

I know how simple and seemingly elegant ideas like tables, folders, tags, xml,...  can make you believe there's a simple answer to all IT problems. It's wrong though, because it's much more difficult to create actual information than a specification of it's form.
It's also notable that the difficulty mostly doesn't depend on the form (not much that could be more powerful than text).

I don't have technical arguments against actually adding such a new field to .info files, only what I said, the content is important. Sometimes less is sometimes more.

Perhaps you could request .info file changes for extensions you'd like to have more information, you had difficulties to find.
I never had problems finding extensions. I optimize mine and try to note it's alternatives or "competition" in the Comments field.

Also you can always use a real search engine and other knowledge bases like this forum to find the right app to suit your needs.