Extend .info file

[vinnie]

http://forum.tinycorelinux.net/index.php/topic,11562.0.html see my topic to read in detail what the problems are for me,
I do not understand why you think it is better not optimize the way already taken by the decision to integrate the "keyword" in the appbrowser search.

[hiro]

Actually from reading this it seems like you didn't really use the search as it is supposed?

I won't discuss this any further as I think our versions of tinycore differ too much. I still use 3.x and there when I use ab search the .tcz name, parts of it and the description is searched.
And the Comments field doesn't get searched (contrary to what I believed before).

I don't know, there's no clean and simple way to do search correctly in my opinion.

[vinnie]

except that if I search Tyrian in standard search type i find nothing and if i search desktop manager (like gnome) in "keyword" mode  i find freerdp, cairo-dock, desktop-file-utils, droplineneu, e-module, efreet, fbreader, gedit, gion-icon-theme, gthumb, jpilot, kdetoys, libnotify, lxinput, lxrandr, lxpanel, lxsession, me-tv, minitube, notify-sharp, rdesktop, qalculate-gtk, qtfm, recordmydesktop... and more all.

[coreplayer2]

A prompt for keywords in the info file would clearly be an improvement, yet a function exists already that satisfies this whole debate which is unfortunately currently underutilized.   
So call it keywords, call it Categories, either will suffice although really "tags"??   just saying is all,  that "Tags" might not be the most appropriate phrase to use.  The phrase "Tags" is informal and personal, more importantly does not portray a professional tone.   IMO "Tags" does not reflect the Core integrity.

"Categories" sounds good, though in practice acts as a divider like a pigeon hole and fails I think to enhance the existing keyword search.





 

[gerald_clark]

Tag is a perfectly accurate term, both in English and in the computer industry.

[Rich]

coreplayer2: Semantics. It doesn't matter what you call it, the concept is still the same.

vinnie: Had a keyword system been in place, you could have done a search for  game  and received
           maybe 50 to 100 results. Had you searched for  game shooter  the list would have been even
           shorter. Either way you could have found  opentyrian  with little effort.

curaga: Thank you for providing some constructive input.

I don't know, there's no clean and simple way to do search correctly in my opinion.

I thought what I suggest was fairly clean and simple. It needs to have a few categories altered and
added, but even as it stands now, it should handle a large percentage of applications.

[coreplayer2]

So when are we going to see an enhancement of the Keyword search system with a "Keyword" entry within the info file?

[Rich]

Hi coreplayer2
Without some participation, never. I already offered a starting point in the attachment in reply #24.
If members are willing to look at the list and comment on it, I'm willing to maintain and keep it updated.
Comments could range from adding or removing  CATEGORIES/FUNCTIONS  to mentioning particular
extensions that can't be described by the current list.

Alternatives include, adopt curagas suggestion of using the freedesktop standard, or maybe
someone can offer a better proposal.

[vinnie]

vinnie: Had a keyword system been in place, you could have done a search for  game  and received maybe 50 to 100 results. Had you searched for  game shooter  the list would have been even shorter. Either way you could have found  opentyrian  with little effort.

This does not change the fact that the normal search (in the field of name) should search also incomplete parts of the name, that you can not object.
However, mine was a response to hiro in reference to the imperfection of the system.

However Rich, you should answer me this: http://forum.tinycorelinux.net/index.php/topic,12499.msg68015.html#msg68015
If you do not plan the shooter category do not think I can use it to find Tyrian.
So for thousands of other words that even we can't imagine that may be of relevance key.

If you want to make a tree of macro categories (like games, education, windows manager...) is welcome, but if this is inhibiting the use of custom keywords, I consider this a mistake.

About to the name to be used, "tags" and "keywords" are both good word but I think it is better to keep what we can keep and I vote for keywords (and I like more the sound).
Also "categories" is god word but that reflects more what Rich want to do instead of a "keyword" or "tags" in the common meaning.

[Rich]

Hi vinnie

This does not change the fact that the normal search (in the field of name) should search also incomplete parts of the name, that you can not object.

Although you pointed out an exception to the rule, I think that if you know the name of the package,
scrolling down to it should be adequate.

However Rich, you should answer me this: http://forum.tinycorelinux.net/index.php/topic,12499.msg68015.html#msg68015
If you do not plan the shooter category do not think I can use it to find Tyrian.
So for thousands of other words that even we can't imagine that may be of relevance key.

If you want to make a tree of macro categories (like games, education, windows manager...) is welcome, but if this is inhibiting the use of custom keywords, I consider this a mistake.

While  shooter  does happen to be in that list, that is a very good point. If a year from now someone
added the  distcc  extension, the word  distributed  could be added to the  development  category
since it allows you to spread the compilation process over multiple machines.

If you want to make a tree of macro categories (like games, education, windows manager...) is welcome, but if this is inhibiting the use of custom keywords, I consider this a mistake.

As I said in a previous post, this is a suggest list of words for searching for and describing of
extensions. Its purpose is to encourage a common syntax. As mentioned above, if a relevant search
term is requested, it will be added. Trivial search terms should be avoided to keep the list
manageable and easy to read. Adding weasels, ducks, and gnomes to games would be an example
of this as it describes the characters in the game rather then the style of the game.

About to the name to be used, "tags" and "keywords" are both good word but I think it is better to keep what we can keep and I vote for keywords (and I like more the sound).
Also "categories" is god word but that reflects more what Rich want to do instead of a "keyword" or "tags" in the common meaning.

As I said, semantics, I don't care what the field is called. Yes, what I would like to do is use the first
word to serve as a rough index of where the application is used, followed by one or more words
to better describe its attributes. No, I am not trying to play god.

There is no reason someone submitting a package can't add extra words in their tags (or keywords)
field. For example, for geany, the tag field might read something like  editor text tabbed programmers.
The order of the words following  editor  is not important. While the meaning of the first three words is
obvious, programmers  tells me it does something with the formatting of the text. Whether that is
indenting, closing matching braces, color coding words, or whatever, does not matter. What matters
is that the search will return a plausible candidate to choose from. While the maintainer is free to add
c++ fortran html  to his field, those terms would not be in the suggested list as they get into specifics
as opposed to the primary purpose of the editor, however, in that case, a search for  editor c++
would still return geany.

The job of the search function should be to return a reasonable list to choose from, your job should
be to decide if any of those choices meet your needs.

[vinnie]

Although you pointed out an exception to the rule, I think that if you know the name of the package,
scrolling down to it should be adequate.

life is also made of exceptions:
1)if you know the package name you do not have any problem caused by partial word search;
2)If the package name is not so implied the lack of a partial search will create problems;
3)does not mean that the keyword field will be of help;
This means that there is no reason to oppose this change.

While  shooter  does happen to be in that list, that is a very good point. If a year from now someone
added the  distcc  extension, the word  distributed  could be added to the  development  category
since it allows you to spread the compilation process over multiple machines.

I do not know if I understand this but it sounds like "complicate something that is easy"
Kiss solution: simply count the occurrences of word in the field "keywords" (or "tags") in the info package files, publish this list is the trace for the package manager.

As I said in a previous post, this is a suggest list of words for searching for and describing of
extensions. Its purpose is to encourage a common syntax. As mentioned above, if a relevant search
term is requested, it will be added. Trivial search terms should be avoided to keep the list
manageable and easy to read. Adding weasels, ducks, and gnomes to games would be an example
of this as it describes the characters in the game rather then the style of the game.

Instead it seems to me a way to impose their vision of what should and should not be used as a keyword. The solution I've written above is simpler and more liberal.
I do not understand why give trust to anyone to submit packages but do not trust their common sense for the keywords.

As I said, semantics, I don't care what the field is called. Yes, what I would like to do is use the first
word to serve as a rough index of where the application is used, followed by one or more words
To better describe its attributes. No, I am not trying to play god.

here we agree, tags and keywords are synonyms are therefore irrelevant to the choice.
I suggested to use the  keywords because there is no reason to change it.

...
While the maintainer is free to add
c++ fortran html  to his field, those terms would not be in the suggested list as they get into specifics
as opposed to the primary purpose of the editor, however, in that case, a search for  editor c++
would still return geany.

If you want appbrowser showing panel of the main categories or sections in addition of "shotgun" search type of keywords, you not find me disagreeing.
However I would not want something simple as moving the target of the search type keyword in another line of .info become a mammoth task.

The job of the search function should be to return a reasonable list to choose from, your job should be to decide if any of those choices meet your needs.

In the moment I find "battle of wesnoth" listed in conjunction with "warzone 2100" I am coming to pick you at home!

P.s. to leave no doubt, I'm kidding, hypothesizing the pessimistic future result of your last say, be too serious is bad for health 

[Rich]

Hi vinnie

Kiss solution: simply count the occurrences of word in the field "keywords" (or "tags") in the info package files, publish this list is the trace for the package manager.

Yes, you could simply let everyone choose keywords, but as you yourself said:

So for thousands of other words that even we can't imagine that may be of relevance key.

So now we get windowmanager, winmanger, and wm. Filemanager, fm, diskexplorer, diskutilty, and
diskmanager. The number of permutations could be endless, and the list would likely keep on growing
as more extensions were added. I don't consider a list containing thousands of keywords appealing.
Plus, as an added bonus, now you get to search through the list of keywords trying to find every
permutation and synonym for the term you are searching for.

Instead it seems to me a way to impose their vision of what should and should not be used as a keyword. The solution I've written above is simpler and more liberal.

Impose? In reply #37 I ask for comments for adding and removing items from the list. As far as the
keywords in that list is concerned, the only thing  "my vision"  has to do with it was my looking through
the info files of several hundred applications to pick out those words.

I do not understand why give trust to anyone to submit packages but do not trust their common sense for the keywords.

It's not about trust or distrust. It's about trying to standardize the list of keywords to simplify the search
process.

If you want appbrowser showing panel of the main categories or sections in addition of "shotgun" search type of keywords, you not find me disagreeing.

I don't think AppBrowser should have to know anything about keywords or categories, which are really
just keywords themselves. Ideally the list should be concise and fit on a small wiki page,

[coreplayer2]

List?   A'aaagh! I must have missed something..

I thought this whole thread was a debate for a new field within the info file, to which extension maintainers may add keywords which describe an app function.  This being an aid to the existing  keyword search feature in producing comprehensive results.

We learned early in this thread that app browser's  Keyword feature searches the entire info file, this being the case keywords can be used anywhere within the info file for example the comment section.     In the strive for an organized resolution the field name "Tag"as suggested.  If this was the right choice it would not need defending.  Therefore my feeling is why change an already established search name; "Keywords"  Stands to reason if you already have a Keyword search feature it should be augmented by a keyword Field in which to place keywords.

Yes I agree the word "Tag" is as valid as any other but this is not about semantics, this is a bout finding a name for a field which is worthy of association with the Core.    Tags are for HTML and Facebook,  whilst the Core deserves better is all.

[Rich]

Hi coreplayer2
Yes, it is about adding a keyword field, however, there seems to be a difference of opinion in how
it should be implemented.

[vinnie]

So now we get windowmanager, winmanger, and wm. Filemanager, fm, diskexplorer, diskutilty, and
diskmanager. The number of permutations could be endless, and the list would likely keep on growing
as more extensions were added. I don't consider a list containing thousands of keywords appealing.
Plus, as an added bonus, now you get to search through the list of keywords trying to find every
permutation and synonym for the term you are searching for.

This is partially true, i wrote count the occurrences not casually, the most frequent words are the most representative.

Impose? In reply #37 I ask for comments for adding and removing items from the list. As far as the
keywords in that list is concerned, the only thing  "my vision"  has to do with it was my looking through the info files of several hundred applications to pick out those words.
...
Ideally the list should be concise and fit on a small wiki page,

well, if it is just a list of keywords "Recommended".
I apologize for having misunderstood and thank you for your initiative.
But at this point the technique of counting keywords is valid to keep you from this ingrate work.

Another request direct to listening developers (by the way, you give us some sign of life?), and how they plan to allow the use of multiple-word keyword.
Currently the keyword type of search considers only the first word entered (ignoring all others), but there could be multiple-word keyword (significant only in that case) like "file manager".
You consider to front this problem?