- Status Closed
- Percent Complete
- Task Type Feature Request
- Category QCAD (main)
-
Assigned To
Andrew - Operating System All
- Severity Low
- Priority Very Low
- Reported Version Development
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Attached to Project: QCAD Bugtracker
Opened by Anonymous Submitter - 27.05.2011
Last edited by Andrew - 12.06.2012
Opened by Anonymous Submitter - 27.05.2011
Last edited by Andrew - 12.06.2012
FS#108 - Library Browser keywords, tags, improvments
Sample RDF File
'1.0' <!-- copyright 2010 by RibbonSoft GmbH --> "http://www.w3.org/1999/02/22-rdf-syntax-ns#""http://www.ribbonsoft.com/rdf/library" "Public Domain" "en""Bike" "de""Fahrrad" "http://www.clker.com" "Giant" "MTB 327" "en_US" "en" "bike" "vehicle" "outline" "architecture" "de" "fahrrad" "zweirad" "de_CH" "velo"
Open
Postponed
- To discuss: Save the license as tag instead of a special field. Pure tag searching is awesome fast. The more special cases that have to be handled different, the slower the search. License tags are quite unique. If something is tagged with “GNU”, it is very likely that the license is meant (expect for the animal named gnu). Same for BSD, Public Domain and CC licenses.
Done
- Mark (gray out) tags that are not available anymore due to the already chosen tags.
- Handle double click / rename
- if a RDF is present, change the item title
- if no RDF is present, add a new RDF and set the the title there
- Edit Meta Data dialog
- add title (both dialog and newly created RDF files)
- Stemmer: Stemming is usually done at the indexing stage.
- additional field in table keywords (type: 0=word, 1=stem)
- don’t show stems in completer and tags lists
- Provide “radio button” tags, e.g. “license” or “modification time” cannot have more than one selection.
- rebuild (clear) library browser DB on start if language was changed
- Provide meta information for directories
- The idea: One can have a directory and assign the author “Donald”. Every item in this directory will have assigned the author “Donald” automatically.
- This is all RDF based, not editable by the user other than by editing the RDF file.
- Problems
- How can that be shown to the user? E.g. someone tags a directory called “architecture” by mistake with “mechanical”. Every item in this directory will now be found for “mechanical”, and will confuse the user.
- → not shown to the user
- Author and license could be overridden (if wanted) be setting them in a item. But what about tags? Tags actually just can be added, not replaced. It that comprehensible for the user?
- → tags that are set on the directory level apply to all items in that directory
- Stored in a directory named “_META”.
- Inside “_META”, there’s the RDF file called “meta.rdf”.
- Let’s keep this simple:
- When an item’s RDF is parsed, the RDF of the directory is parsed first, then that data is replaced / extended by the item’s RDF. This way we only have to change things in one place (RDF parsing). DB, queries, etc. remain the same.
- the quick info (shown on item mouse over) should show additional information
- the license
- the author
- GUI changes according to the attached file
- every tab should have its own list view (based on RListView) / model / splitter
- RListView, LibraryBrowserView: use signal / slots mechanism instead of inheritance
Automatic Translation
Tags
- RDF: add title
- add item title and use it instead of the file name (avoids “bear01”)
- add item locale
- add authors as tag
- add license as tag
- perspectives (top, side, front)
- make it possible to easily combine common tags, e.g. “DIN-912”, “top viewing direction”, “high level of details”
- Tags are searched with exact match (in opposite to the “normal” keyword search, which is “*keyword*”).
- Drawings have additional tags to match this exact search, e.g. a drawing with the tag “DIN-912” has also the tag “DIN” assigned. These additional tags are made programmatically while parsing the RDF.
- [old] This could be achieved by defining some standardized tags with a special meaning, e.g. viewing direction “view:top”, “view:front”, “view:side”; level of detail “lod:low”, “lod:medium”, “lod:high”. The user interface could show these special tags as filters for the current view or search view.
- see also http://www.chefkoch.de/rezepte/ for an interesting approach to the problem
Favorites
- favorites (saved in .ini file as list of paths)
Table "keyword"
COLUMN_NAME TYPE_NAME id INTEGER text VARCHAR locale_id INTEGER
Table "locale"
COLUMN_NAME TYPE_NAME id INTEGER text VARCHAR
- “locale independent”, always included in search
Filename based Keywords
- filter filename
- replace ‘_’ with " "
- replace ‘-’ with " " leave “-”
- replace numbers [0-9] with “”
Closed by Andrew
12.06.2012 20:52
Reason for closing: Implemented
Additional comments about closing:
12.06.2012 20:52
Reason for closing: Implemented
Additional comments about closing:
mostly obsolete due to refactoring
The problem with "favorites": For most Windows users QCAD is installed in the program folder, which is read-only except during the installation. So if favorites are implemented with a tag, they are only available for the user's part libraries (which would be a bit weird).
Possible solutions:
How about saving the user's favorites in the ini file (list of paths)?
I cannot see the possibility to work with combined common tags on www.chefkoch.de. To me that looks like words as pure text (same applies to delicious, flickr etc.). The relations between the words are based on the amount of usage, e.g. "Pizzateig" is very often used with "Backen" (in the tagged recipes). So chefkoch.de shows the tag "Backen" very large after one has chosen "Pizzateig". As far as I understand that's different from what we want (as described above), or am I wrong?
Wouldn't it be easier to have pre-defined tags instead of standardized tags with a special meaning? What is the advantage if we save "view:top" as keyword instead of simply "Top View"? These "standard tags" could be hold in a ComboBox as simple text. Do I miss something? Maybe we can discus this tomorrow.
On chefkoch.de, one can choose different 'paths' to the same result, for example:
or:
What looks like a path (/Vegetarisch/Hauptspeise/Kinder or /Hauptspeise/Kinder/Vegetarisch) is really just a combination of tags to search for.
In our case, that would mean that the user can for example click "Vehicles" - "Detailed" - "Top View" or "Top View" - "Detailed" - "Vehicles" and get the same result.
It looks like path based navigation but it's actually a way to click search terms or tags together rather than typing them into the search field.
We need to discuss this further before starting anything.