Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: bmarkus on February 04, 2012, 07:14:23 AM
-
.info file structure is unchanged since TC 1.0 and still OK. However number of available extensions are growing and if you do not know exactly name of a package not so easy to find one, specially when useful information is missing in .info saying description like 'Latest abcd package' for abcd.tcz
Lets add a tag line to info file with free content, however with a published guidelines with propesed tags to make it unified. I think it wouldn't break current applications processing .info files. Also, it doesn't force to recreate .info files, can be introduced during regular updates and still keep optional. Also, AppBrowser search can use it as it is now.
Just an example:
Title: unixcw.tcz
Description: Morse code library and applications
Version: 3.0.1
Author: Simon Baldwin, Kamal Mostafa, Kamil Ignacak
Original-site: http://sourceforge.net/projects/unixcw/ (http://sourceforge.net/projects/unixcw/)
Copying-policy: GPL v2
Size: 61k
Extension_by: bmarkus
Tags: CLI HAM RADIO CW
Comments: Binaries only
----
Compiled for TC 4.x
----
PPI compatible
Change-log: ----
Current: 2012/02/03 First version, 3.0.1
-
Why not just write them into the comments field?
-
Why not just write them into the comments field?
Comment is a free form for any additional info, like configuration, usage notes, etc. Tags are like multiple categories. They are different. You can efficiently filter based on tags if they are used properly with a simple tool defining criterias like any or all tags must be found, tags to exclude, etc. Tagging is widely used solution in IT world to help finding pictures, books, software in fact anything instead of searching notes.
The question is not to find arguments against doing something but how to make something better :(
-
Yes! please please please :-X
In regard to this topic http://forum.tinycorelinux.net/index.php/topic,11562.0.html (http://forum.tinycorelinux.net/index.php/topic,11562.0.html)
I think it's important to have an entry in .info corresponding to the button "keyword", I'm doing the latest packages so arranged as I have specified here
http://wiki.tinycorelinux.net/wiki:creating_extensions#tczinfo_example (http://wiki.tinycorelinux.net/wiki:creating_extensions#tczinfo_example)
-
Yes! please please please :-X
In regard to this topic http://forum.tinycorelinux.net/index.php/topic,11562.0.html (http://forum.tinycorelinux.net/index.php/topic,11562.0.html)
I think it's important to have an entry in .info corresponding to the button "keyword", I'm doing the latest packages so arranged as I have specified here
http://wiki.tinycorelinux.net/wiki:creating_extensions#tczinfo_example (http://wiki.tinycorelinux.net/wiki:creating_extensions#tczinfo_example)
Please, do not mix description with tags and please, do not advise to do so in the wiki! ??? Description is not for tags! In fact, there are no place for tags, this why I'm advicing to introduce it. To fix a bug with an another bug which compensate it is a bad practice.
-
bmarkus, please, not take a contrasting position with me, is quite evident that with my actions I tried to patch up grossly and not to vandalize the wiki and waste best practice method.
The proposed solution in wiki is brutal but functional (and frankly do not even like me), but if you look my topic date, I have written two months before the wiki edits, when I had lost hope that someone was interested to solve this (what I believe) problem.
To be honest, I was hoping that someone complained about the editing of wiki (noting the incoherence with the description field criteria) to reopen the discussion.
Was not this the course of things, but the result is the same.
-
Why not just write them into the comments field?
1. A lot of extensions lack useful information in this field making it unsuitable for this task.
2. Unrelated extensions may contain the keyword in a different context.
If a Tags or Keyword field were to be added it would make sense to do a little planning first to
make it efficient and user friendly. Possibly something like this:
Tags: SUBJECT FUNCTION [FUNCTION] [FUNCTION] [FUNCTION]
This way, when doing a search, if there is no match on SUBJECT, you don't any waste time looking at
the other tags. A standard table of SUBJECTs and FUNCTIONs would make it easier for an end user
to find things and easy for the extension maintainer to pick standard keywords. Example:
SUBJECTs FUNCTIONs
compiler c c++ fortran ada cross assembly
driver audio video tablet network firmware
editor text hex audio video picture programmers tabbed html office spreadsheet
filemanager small twopanel dragdrop ftp
fileutil compress expand sort search backup
game text graphic network
library math audio video network fortran
network monitor fileshare ftp discovery client webserver
player audio video networkSo if someone is looking to play music over the network, they would search for player audio network.
If they simply want to know what players are available, they would search for player, and all players
would be returned by the search. There is an implied and in the search, meaning all keywords must
match, as I have my doubts as to how much value would be added by an or function.
Although not perfect, I think the above example, while far from complete, has some merit. The difficult
part is coming up with a list of SUBJECTs and FUNCTIONs that:
1. Everyone can agree upon.
2. That are generic enough so the list of choices does not get out of hand. For example, if you are
looking for a math library, the only choice for FUNCTION is math. No trig, float, integer, etc.
keywords, as the search will already have narrowed the field to find what you are looking for.
3. That can handle applications that may not fit neatly into one SUBJECT.
-
IMO only extra Keywords to help in search function would be helpful, although I feel this option exists already but is just under utilized by the extension creator.
-
Hi coreplayer2
And where would you place those keywords?
-
Hi Rich, yes I knew I was going to get cornered on that one. ;D
Assuming keywords are searched for within the description or comments fields, I'd put them there. I'd be grateful for more keywords anyhow. :)
-
I introduced keyword search with the release of v4.0. The Description field is currently used.
But, it is mainly ignored. I don't care what field or if a new field is used, as long as extension makers use it!
If a new field is used then it will take a long time for keywords to be useful. This is one of two areas that the infrastructure is waiting on good data. Otherwise garbage in, garbage out.
-
Hi coreplayer2
TC3.x appears to search the entire info file. Do a search for backup and you will get back every
extension that tells you to backup your user settings. It also does partial matches so a search for
email will return autoconf-2.13.tcz because one of the authors is named Akim Demaille. Granted
it is in the Author field but it demonstrates how you can get results you are not looking for. If a
Comment field contained the phrase "change the config file using a plain text editor" you would
receive that extension whether it was relevant or not.
TC4.x appears to search only on the Description field, also with partial matches.
In either case, try doing a search for an extension that provides file sharing without using the terms
Samba, Windows, or NFS and see how that works out for you.
-
Hi roberts
I want to begin by saying that none of this is a criticism of what you have done. A good search system
requires a lot of work to be done well, along with cooperation by extension makers.
If a new field is used then it will take a long time for keywords to be useful. This is one of two areas that the infrastructure is waiting on good data. Otherwise garbage in, garbage out.
Agreed. If a new field were introduced for keywords, the description could be used as a fallback
to maintain compatibility with extensions that do not yet contain the new field. As new extensions
are added and existing ones are updated, the submitqc script could verify that the field is present
and contains at least two entries, though syntax would not be checked as the list of keywords is
liable to change over time.
-
I think keywords could be used that are not part of the description. So it is ideal to have it separate.
Why not encourage people to update files, adding keywords. Then include a keyword search.
The method suggested in the previous post is a possible temporary option.
-
Hi Guy
In an ideal world, it would be nice to do this in one shot. Having only one extension in the repository,
it would be very easy for me. However, some members maintain upwards of 300 extensions, and
I would not expect them to start updating them all for this change. I don't think of this as a temporary
option, rather, I consider it to be a gradual upgrade path that could accommodate both existing and
newly submitted packages. This would allow package maintainers, should they choose to, to gradually
upgrade their packages over time, preferably starting with applications and leaving libraries for last.
Not to mention, if everyone upgraded their packages at once, JasonW would get swamped by all the
resubmissions.
-
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.
-
+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.
-
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!
-
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.
-
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.
-
+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
-
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 (http://standards.freedesktop.org/menu-spec/1.0/apa.html)
-
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 (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
-
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.
-
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.
-
Personally I won't change my .info files,, as I implied earlier I feel there's hardly any value in this complication.
-
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?
-
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
-
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 (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.
-
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.
-
http://forum.tinycorelinux.net/index.php/topic,11562.0.html (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.
-
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.
-
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.
-
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.
-
Tag is a perfectly accurate term, both in English and in the computer industry.
-
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.
-
So when are we going to see an enhancement of the Keyword search system with a "Keyword" entry within the info file?
-
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: 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 (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.
-
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 (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.
-
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! ;D
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 :P
-
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,
-
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.
-
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.
-
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?
-
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.
-
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
????
-
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?
-
combo3
Add an additional line just for listing keywords - not in a sentence.
-
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.
-
I like categories.
-
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.
-
also for this decision would be helpful to have a poll (since I prefer keywords for an issue of retroactive coherence)
-
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?
-
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.
-
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):
-
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
-
I hear the footsteps of a mammoth :D
-
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.
-
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.
-
I thought it was headed in a good direction with bmarkus' suggestion of tags and with Rich's suggestion of a wiki page with recommendations of tag sequences. We should not go overbaord with too many words, a single line in the info file should suffice.
-
... 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.
Fine by me, just tell me the name and the place in .info where to put that line and I begin to use it.
However, it may take some time before the occurrence of the data is relevant and since we decides to take the big step will undoubtedly many applications remain excluded.
Is there some reason that escapes me why this solution is not feasible?
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
-
My original proposal was discussed widely and deeply, it is the time to stop talking and implement. Here is the action plan.
1) Keep description line one line, use for short verbal description of package, if possible using text from upstream. Do not mix with keywords.
2) Add a single line Tags: line as below. While it is a free content line, to keep consistency and usability use tags according to guidelines and proposed tags published in WIKI.
Title: unixcw.tcz
Description: Morse code library and applications
Version: 3.0.1
Author: Simon Baldwin, Kamal Mostafa, Kamil Ignacak
Original-site: http://sourceforge.net/projects/unixcw/ (http://sourceforge.net/projects/unixcw/)
Copying-policy: GPL v2
Size: 61k
Extension_by: bmarkus
Tags: CLI HAM RADIO CW
Comments: Binaries only
----
Compiled for TC 4.x
----
PPI compatible
Change-log: ----
Current: 2012/02/03 First version, 3.0.1
3) Rich will create the WIKI page of tags and guidelines (thanks!)
4) Extension makers start using it in next regular updates or submitting nemw extinsions
5) Robert, please add searc in Tags: line to AppBrowser and ScmBrowser in next RC to get it implemented in final 4.3 To avois the chicken and eggs syndrome please do not postpone it till it will be used, otherwise no one will add tags if search not implemented.
Thanks to everybody contributing :)
-
This is keyword occurrence in (all) description field for rich, is the best I could do,
-
Hi bmarkus
The question that has not yet been answered is whether it is acceptable that the first keyword in the field be used
as a primary index. Using unixcw.tcz as an example, I have added hamradio to the audio category as well as
the video category should a SSTV application be added. While I have no objection to adding a hamradio category,
this seemed like a good way to include it, as I could not find many applications in the repository. So search would
look like this:
audio hamradioThis way the search function would only check the remaining tags if the first one is audio which would mean
faster searches. I would also like to hear roberts opinion on this.
While it is a free content line, to keep consistency and usability use tags according to guidelines and proposed tags published in WIKI.
And that is exactly the point. By starting with a suggested list of standard tags, the search returns relevant results.
Taking the previous example a little further, a ham adding an extension would still be able to add terms like
cw, ssb, morse, etc. to their tags field, since these are specialized terms that a ham would be aware of. Yet a
novice not familiar with those terms could still find out what ham related extensions are available.
I've started cleaning up my list as well as looking at the WIKI. Reading the WIKI syntax page and using the WIKI
playground I'm getting a handle on how to do this. Any suggestions and warnings on editing the WIKI would be
appreciated.
@vinnie: Thanks for the list.
tc@box:~$ wc -l Caseinsensitive_occurrences
3957 Caseinsensitive_occurrencesShouldn't take to long to get through that. :)
-
@Rich, I am in agreement with you. It is what I had described as tag sequences.
It will result in faster searches.
We don't need to hold up the release of 4.3 for this. Most of the coding is done on the server side.
As soon as I see even a sampling of data, I will begin to revisit the server side code.
Hopefully this will come together for 4.4 release. But in the meantime we can test sample data and use cases.
Looking forward to the Wiki item followed by some sample items posted in the repository.
-
I have done and uploaded this for the mozilla web browsers, ntfs-3g, gtk2, and a few others.
Though we would normally wait on each extension maker to edit his info files, we have seen that this is not going to happen quickly. I personally see no issue with a volunteer or a group of volunteers editing and submitting info files with Tag: fields to jump start the process. If an extension maker disagrees with a tag in his info file, then he can edit and send in what he likes.
-
This way the search function would only check the remaining tags if the first one is audio which would mean
faster searches. I would also like to hear roberts opinion on this.
And if in case the keyword that comes to mind is not the first, research continues or stop?
I think there may be many ambiguities concerning the keywords most representative.
For example jason has put "windows" as the first word of ntfs-3g and "web" for firefox, I would put "file" and "browser" but is not that there is a more reasonable choice.
Shouldn't take to long to get through that. :)
not so much because it is one word per line, however, with search function (or grep) you may use it as a reference when you have doubt about which word is used more :)
I personally see no issue with a volunteer or a group of volunteers editing and submitting info files with Tag: fields to jump start the process. If an extension maker disagrees with a tag in his info file, then he can edit and send in what he likes
+1 and also an equal number of people could make a more uniform work
-
Hi everyone,
I've written a small WIKI page that shows a suggested way of setting up and searching for tags. After looking at it,
if anyone feels:
1. A category needs to be added
2. A function needs to be added to a category
3. A function needs to be removed a category
4. An extension cannot be categorized with the list of categories and functions
Please speak up, make suggestions, or give examples. Keep in mind, the table presented is intended to perform
a searches for a specific type of application, not every feature it may contain.
I've included a handful of examples at the end of the page.
http://wiki.tinycorelinux.net/wiki:finding_applications (http://wiki.tinycorelinux.net/wiki:finding_applications)
-
Hi vinnie
And if in case the keyword that comes to mind is not the first, research continues or stop?
If the first keyword does not match the search moves on to the next extension until it finds one where the first
keyword matches. It then compares the remaining keywords in your query with those in the applications tag field.
I think there may be many ambiguities concerning the keywords most representative.
I believe this where you and I differ in opinion. The point of the WIKI page is to try to establish a BASE set of
keywords capable of describing an applications purpose. Just being able to search for "web browser" or
"audio player" and receiving only relevant applications is big step in the right direction. The list is intentionally
kept short and as generic as possible to minimize being ambiguous. While using the most common keywords
and simply searching the info files may seem like a good idea on the surface, it will miss extensions not containing
any keywords that are relevant. Not to mention if for example you want a list of web browsers, you will also get back
every extension that mentions web browser including cups1311.tcz.
For example jason has put "windows" as the first word of ntfs-3g and "web" for firefox, I would put "file" and "browser" but is not that there is a more reasonable choice.
I guess I should have gotten that WIKI page up faster.
-
Now i doing info file of one package:
- http://unpaper.berlios.de/ (http://unpaper.berlios.de/)
I looked at the tags to wiki in search of tag utility and i found category "fileutility",
What happens if I search only "utility" keyword?
And if i search "scanner" "image" "utility" (in this sequence) ?
I'll clarify the question:
we suppose a repository that contains 3 total tags ("A" "BC" "DEF")
If I search keyword A must come to me only show packages that contain A
If I search E and A I have to find only those packets that contain A + CDE (and not only A or only CDE)
I think that the research work in this way (should be the logical "and" but looking also partial word) it is ok, otherwise I'm in doubt about which keywords to put (for now I put it without thinking, after I replace just in time)
-
Hi vinnie
First of all, thank you for providing a solid working example. That was the purpose of reply #68 and I hope a few
more people will participate.
While the unpaper program basically does "post-processing" of data, most people won't think of it in those terms.
How about if the tag enhancement were added to the printer functions? Then your tag field could read:
printer scanner enhancement or printer enhancement scanner as most people would probably associate this
function with a scanner anyway. While a search on printer enhancement or printer scanner would still return
your extension, searching on all three tags would narrow the list further.
As far as partial matches are concerned, my preference would be to match from the beginning of the tag so that
the person doing the search could type enough characters to uniquely identify it, though the complete tags should
still be used in the info file. I don't like the idea of word inside of word matches as that may result in undesirable
matches.
Yes, searches should definitely be a logical AND.
Come to think of it, maybe data is the wrong place for the ocr tag, printer would make more sense.
-
I approximately agree with you, only one thing I disagree with your thinking, research of partial word.
continue with an example.
hypotheses tag of a package: fileutility archive packer compress
hypotheses of research: "archive "utility"
Result: the first word is present, and therefore the package is listed, the second word is not present and if the search does not include partial words the package is not listed!
in essence I believe that includes the search for partial words ruin a little the results but that does not include it would do much more damage.
I think that the optimization has already taken place (and sufficient) limiting the use of keywords due to the field tags
When you do a search I think a person should be able to travel with her intuition, not to be aware that there are limits which bound, because the majority of cases people will not be documented on how to do the research.
In italian we say "meglio abbondare che deficere" which in English translates same as "better too much than not enough" ;)
-
Hi vinnie
While I feel my reasoning on partial matches is sound, It's only an opinion. I suspect roberts will make the final
decision on that.
I get the feeling you are still not grasping that the first tag is used as an index and must come from the CATEGORIES
column.
When you do a search I think a person should be able to travel with her intuition, not to be aware that there are limits which bound, because the majority of cases people will not be documented on how to do the research.
That's why the WIKI page is there, to guide people when searching for an extension. If necessary, a link could be
added to the Tinycore website to make its existence more obvious.
-
Personally I don't see the logic in cutting keywords into categories, or putting emphasis on the first keyword. all and any keywords need only to carry the same weight to be effective. I understand the intentions but why make it more complex than it needs to be?
Just my opinion is all..
A wiki to give examples of keywords is all that is necessary to get things moving in the right direction. Extension creators are going to use there own keywords anyhow.
-
You have a good starting point, but I think the list in the wiki can be improved and added to.
For example, I suggest
Include the category - office
Change web to - internet
-
My original idea was a simple tagging with no categories. However if community is preferring categories, why not use freedesktop.org categories (including sub-categories) instead of reinventing the wheel? Even if this is not perfect is ready and for sure they went through the pain. And it woulb be useful in DE supporting freedekstop.org like LXDE, Xfce4, KDE? Gnome.
-
Personally I don't see the logic in cutting keywords into categories, or putting emphasis on the first keyword.
....
A wiki to give examples of keywords is all that is necessary to get things moving in the right direction. Extension creators are going to use there own keywords anyhow.
My original idea was a simple tagging with no categories
+1
While I feel my reasoning on partial matches is sound, It's only an opinion. I suspect roberts will make the final
decision on that.
Undoubtedly the decision remains in those who develop, this does not mean that the discussion can not make him focus on ideas.
I get the feeling you are still not grasping that the first tag is used as an index and must come from the CATEGORIES column.
It does not matter if I did not understand it, is important when thousands of people will not understand it (not because what you say is strange, but it's simply a fact of randomness) :P
That's why the WIKI page is there, to guide people when searching for an extension. If necessary, a link could be added to the Tinycore website to make its existence more obvious.
I think the guide could be a good thing for those who want to learn more (user or packager that is), but make the reading of a guide obligatory for the use of a search field would be like to ask anyone necessarily the use of a reference for use google (for example).
It is best to leave the order on their own judgment rather than risk the incomprehension of the search function.
All this always imho, of course
-
Personally I don't see the logic in cutting keywords into categories, or putting emphasis on the first keyword.
Categories serve two purposes:
1. It provides a keyword that defines what you are interested in doing, then guides you to a few more keywords to
narrow the search a little further.
2. It speeds up the search function. Since it sounds like the search will be implemented on the ibiblio server, speed
matters. As a shared resource, you don't want the server performing more work than necessary.
A wiki to give examples of keywords is all that is necessary to get things moving in the right direction. Extension creators are going to use there own keywords anyhow.
If "Extension creators are going to use there own keywords anyhow", then there is no point to the WIKI page or
this discussion.
For example, I suggest
Include the category - office
Change web to - internet
I placed office under editors because that's what those packages are used for. They just contain multiple editors
for handling formatted text, spreadsheets, PDFs, etc., and to the best of my knowledge there are only 2 or 3
packages. Having said that, if you feel breaking out office into a separate category would be more intuitive, I'll
be happy to do that.
I used web because web browser and web server sounded more natural, but internet is fine too.
My original idea was a simple tagging with no categories. However if community is preferring categories,
Which so far does not seem to be the case.
why not use freedesktop.org categories (including sub-categories) instead of reinventing the wheel? Even if this is not perfect is ready and for sure they went through the pain.
Actually, I used freedesktop.org as a source for ideas and tags. What they call Main Category and Additional
Category I called CATEGORIES and FUNCTIONS. I just tried to make the list concise to try to avoid the question
of whether xyzzy.tcz belongs in category A or category B. The freedesktop.org standard allows for a lot of ambiguity.
And it woulb be useful in DE supporting freedekstop.org like LXDE, Xfce4, KDE? Gnome.
I'm sorry, I don't understand the question.
Undoubtedly the decision remains in those who develop, this does not mean that the discussion can not make him focus on ideas.
Agreed.
It does not matter if I did not understand it, is important when thousands of people will not understand it (not because what you say is strange, but it's simply a fact of randomness) :P
Then I apologize for proposing such a random search idea.
I think the guide could be a good thing for those who want to learn more (user or packager that is), but make the reading of a guide obligatory for the use of a search field would be like to ask anyone necessarily the use of a reference for use google (for example).
It is best to leave the order on their own judgment rather than risk the incomprehension of the search function.
You are right, making the reading of instructions on how something works obligatory is simply wrong. Yes, Google
is good example of how this should be done. Search for sed command and you get 2,130,000 results. Search
for sed command linux and you get 15,700,000 results, narrowing my search down very nicely. And luckily, you
don't need to read any instructions on how to tell Google not to remove one of your search terms so it can return
more results.
You seem to be focused on the searcher to be free to pick any words to find an app, the packager is free to pick
any words to describe the app, and there should be no rules or restrictions. Fine, please explain the magic that
will be used to match the two.
I'm at a point where I'm starting to feel obligated to take up a collection to buy a seatbelt for roberts chair, so that
does not fall out of it from laughing so hard.
-
Based on search performance, I can see the merit of using categories. Maybe I don't fully understand the concept but I foresee a conflict when matching an extension description to a category, to some degree all is good if the app description fits many categories but it's the extension which don't fit any category that presents a dilemma?
How to resolve that?
-
Tag squencing will not be enforced.
-
My original idea was a simple tagging with no categories. However if community is preferring categories, why not use freedesktop.org categories (including sub-categories) instead of reinventing the wheel? Even if this is not perfect is ready and for sure they went through the pain.
It think this is a good idea. It is good to have a standard guide, so everyone takes a similar approach.
If someone has an app which is best described with a word or words not included in the list, those words can still be used. But the key words should come from the list.
-
Rich, everyone appreciates the time and effort you have put in, but what do you think of replacing the info on the wiki page with the categories from freedesktop.org?
If users think we can improve on the freedesktop.org list, share your ideas. But it is a good starting point.
-
Rich, everyone appreciates the time and effort you have put in, but what do you think of replacing the info on the wiki page[1] with the categories from freedesktop.org?
If users think we can improve on the freedesktop.org[2] list, share your ideas. But it is a good starting point.
one thing i would be very sorry to see go (before it even realy appeared) if this was to happen is the 'driver' tag/category
from my view
separation of
-system-specific
things that are needed for basic system functionality (aka drivers: eg disk,video,network,printer,ect) .. things most "normal/casual" users are less aware of *
and
-user-specific
non system critical processes aka application's that are things that are entirely optional and wide ranging (eg, browser and wireshark both need network)
seems to offer advantage
for example
if im looking for wireless support , i dont need to know about any applications , i just want to connect to my network!
and if i have my wifidriver + connection-mgr (presumably after being pointed to the wiki) , i no-longer need lists of wifi network-drivers
wireless i think is a good example as it has come up on the forums
and because connection manager needed by most to make use of the connection , but it is user choice which to use
so it seems (to me at least) to fit some place between " system-specific " and " user-specific "
hope some of the above is intelligible
.. in case it is not
i think we need a "drivers" TAG! for modules especially as they are mostly created by the tc-team
[1]http://wiki.tinycorelinux.net/wiki:finding_applications (http://wiki.tinycorelinux.net/wiki:finding_applications)
[2]http://standards.freedesktop.org/menu-spec/1.0/apa.html (http://standards.freedesktop.org/menu-spec/1.0/apa.html)
*(yes some driver modules are already included included with in core out of necessity/convenience )
-
What would happen if at some point the list should change at the appearance of new issues?
Tag squencing will not be enforced.
If I understand this is good news, means to support both the optimization performance of Rich and the fanciful estrus of myself? ;D
-
If someone has an app which is best described with a word or words not included in the list, those words can still be used. But the key words should come from the list.
Which is why I included optional tags in my examples, to allow someone to add specific details. My intent was to
make it easy to find applications based on what you want to do, not how it is implemented.
Rich, everyone appreciates the time and effort you have put in, but what do you think of replacing the info on the wiki page with the categories from freedesktop.org?
(freedesktop.org) If that's what everyone wants, thats fine. While it is intended to define how a desktop menu is
laid out, it could be made to be workable. I suggest that anyone who thiks this is a better approach read that site
very carefully. Don't just read the categories. Read the rules they give and look at the way they interrelate those
categories. Then think about the actual implementation. I'll give a few examples.
Under Main Category:
AudioVideo, Audio, Video. Really?
Graphics. OK, maybe I want to edit, view, whatever. Now lets see whats under addition categories:
OCR Optical character recognition application Graphics;Scanning
Photography Camera tools, etc. Graphics or Office
Publishing Desktop Publishing applications and Color Management tools Graphics or Office
Viewer Tool to view e.g. a graphic or pdf file Graphics or Office
We get multiple choice for the Main Category to put something under. Continuing under addition categories:
Amusement A simple amusement
There's a nonsensical category for you.
Electronics Electronics software, e.g. a circuit designer
Engineering Engineering software, e.g. CAD programs
And these two they couldn't even figure out what Main Category to put them under. My personal opinion is that
if the consensus is to adopt this as a standard, you look before you leap.
@dubcore: I agree, drivers is an important category.
What would happen if at some point the list should change at the appearance of new issues?
If an application can not be properly classified, categories and/or tags can be added. Moving, changing,
or removing of categories/tags, while not impossible, is much more difficult to do once a system is adopted.
This holds true for the freedesktop.org list as well as my own.
If I understand this is good news, means to support both the optimization performance of Rich and the fanciful estrus of myself?
No, it means that search speed will be sacrificed so that you can put tags in any order. The first tag would NOT
have to be from the column labeled CATEGORIES.
-
No, it means that search speed will be sacrificed so that you can put tags in any order. The first tag would NOT have to be from the column labeled CATEGORIES.
Well I got it wrong, I are still happy that we can do research in any order (I'm sorry that things do not can coexist)
If an application can not be properly classified, categories and/or tags can be added. Moving, changing, or removing of categories/tags, while not impossible, is much more difficult to do once a system is adopted.
This holds true for the freedesktop.org list as well as my own.However, according to the decision just above, this should not cause failure during the search.
Regarding the list, I do not pronounce, though I think the freedesktop list is valid only for programs with starters.desktop
-
Hi vinnie
However, according to the decision just above, this should not cause failure during the search.
Probably not.
Regarding the list, I do not pronounce, though I think the freedesktop list is valid only for programs with starters.desktop
As I said, that list was intended to define how the desktop menu should be laid out.
-
Where's the beef? I cannot start cooking without the main ingredient!
So far 23 out of 3689 extensions have a Tags item.
I have already stated that each word will be evaulated so lets get started..
-
I didn't realize that a decision had been made. I'll try to email new *.info files for my packages by the end of the week.
Here is what I've deduced from the preceding discussion:
I should add a single line starting with "Tags:" underneath the "Extension_by:" line.
This line should contain a list of space separated keywords following the guidelines here (http://wiki.tinycorelinux.net/wiki:finding_applications), but not limiting myself to those.
Also, it wouldn't hurt to follow the ordering specified on at the link I supplied, because even though the search function doesn't currently pay attention to ordering now, it will make updating the *.info file easier.
I hope that I've not misunderstood anything too badly,
Nomer
-
Hi nomer
I don't know whether my list has been accepted or whether members would prefer to try to adapt the freedesktop.org list.
-
Why not go with your list, but look at freedesktop.org and see if you get any ideas to improve your list.
-
Hi Guy
That is the approach I would like to take, though I will acknowledge that my opinion on the matter is biased.
I will be changing the web category to internet and add web to the functions field as well as chat.
I gave my reasoning on why I placed office under editors in reply #78, though I neglected to mention I'm
also trying to make it difficult for an application to fall under two different categories, not an easy task. I am
still interested in your opinion if you feel this should be changed.
@ALL: If there are any objections, please present them now so we can move forward.
-
@Rich
I have no objections
@anyone
How should *-dev.tcz, *-doc.tcz, and *-locale.tcz files be tagged? Should they inherit the tags from their parent? (When I say their parent I mean the package named *.tcz) Or should they have no tags? If we don't choose either ov those options then we'll have to create a new category or function, since these types of packages don't seem to fall under any of the chosen categories.
Personally, I would prefer inheriting the "parent's" tags.
-
I do not think we need a tag for local dev doc,
If the search for the tag works like keywords, is included a partial search of the package name, that is equivalent to entering the package name (with any dev local doc) in a tag.
-
I have been giving that some thought, particularly because some extensions have separate dev packages and
some extensions include their dev headers and libs in the same package. In both cases the packager is free
to add optional tags, such as dev or headers for example.
If dev, doc, and locale are submitted separately, I think that using the same tags as the main extension is a
good way to go, since that way they would all show up on a search, and their name should make their
purpose obvious.
-
95 replies and little actual data. This is what I am going to do....
Keyword is the concept that I seeded and some found useful.
I am going to force a Tags line into each and every .info file that does not have an existing Tags line.
Currently there are only 25 extensions that have a Tags line.
The forced Tags line will be based on the Description with many throw away words removed.
I have been testing this and it seems to be a good jump start that is needed to get this moving.
I want to try to get this in version 4.4.
Of course, any extension maker can update their .info files with better and more useful Tags.
Over time and with community involvement the Tags will improve.
-
I am happy, as I'm concerned it could not have a better ending :)
-
Forced tags inserted for tczs.
-
Hi roberts
I noticed something odd. In my extension:
Title: nvidia-96.43.20-3.0.3.tcz (TESTING)
Description: nvidia legacy video driver
Tags: nvidia legacy video drive
driver was changed to drive
In Arslans extension
Title: nvidia-glx.tcz
Description: NVIDIA Linux Drivers, Xorg driver.
Tags: NVIDIA Drivers Xorg driver
The word driver was unaffected.
[EDIT]: I've already submitted a new info file, but this might effect other extensions.
-
Looks like the last char was chopped let me see if I can fix it.
-
Hang on regenerating and will repost shortly.
-
Fixed!
You might have to delete /tmp/tags.db so that appbrowser/search.sh will re-download the updated tags.db.
-
Hi roberts
Thanks, looks good.
-
;) Thanks for catching that!
-
Hi roberts
I'm only reporting this in case you ever find it necessary to run a forced update of tags again.
The extension thunar-plugins.tcz wound up getting multiple tag entries. I believe that may be because the
Comments: field contains the term Description: several times, as this snippet shows:
Extension_by: Arslan S.
Tags: Thunar file manager plugins.
Tags: Create extract archives context menu**
Tags: Tags editing thunar properties menu.
Tags: Generate previews certain file types.
Tags: Set pictures wallpaper context menu.
Tags: Advanced Properties Plugin.
Tags: Simple Builtin Renamers.
Comments: This extension consists of the following plugins:
thunar-archive-plugin:(tested ok)
Description: Create and extract archives from the context menu**
version: 0.2.4
recommended: file-roller, squeeze or xarchiver*
thunar-media-tags-plugin:(tested ok)
Description: Tags editing from thunar properties menu.
version: 0.1.2+svn-r04939
thunar-thumbnailers:(testing)
Description: Generate previews for certain file types.
version: 0.4.1
recommended: ImageMagick
thunar-uca:(tested ok)
user defined custom actions
version: distributed with thunar file manager
thunar-wallpaper-plugin:(tested ok)
Description: Set pictures wallpaper from the context menu.
thunar-apr:(testing)
Description: Advanced Properties Plugin.
version: distributed with thunar file manager
thunar-spr:(testing)
Description: Simple Builtin Renamers.
version: distributed with thunar file manager
-
Since Arslan S. is currently serving his country, I've submitted a corrected version of the info file
on his behalf.
-
Good work Rich ;)