QCAD Bugtracker

  • Status Closed
  • Percent Complete
    100%
  • 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

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:  

mostly obsolete due to refactoring

Anonymous Submitter commented on 03.06.2011 07:48

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:

  • install libraries somewhere else, e.g. in "My Documents"
  • break the rules of using the DB only as a cache (which means favorites will be lost on update)
Admin
Andrew commented on 03.06.2011 07:52

How about saving the user's favorites in the ini file (list of paths)?

Anonymous Submitter commented on 07.06.2011 14:55

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.

Admin
Andrew commented on 07.06.2011 15:22

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.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing