64bit/Database

Requirements

• Maximum bid USD $5,000 (fixed price for entire project)
• see further requirements
• After you've read the rest, see the Help

Deliverable

Using Qt Widgets & C++, you will create a cross-platform database (using SQLite) with GUI browser with these features:

• utilize SQLite tables and FTS if necessary for fast db searches
• 100% unicode
• “main browser” window has a “Source” list (tree view) on the left side (listing the “Library” and other “Playlists”) (single column, heirarchical, as some act as folders) (this part is working well enough but needs finishing touches)
• “main browser” window has a “Tracks” list (table view) on the right side side (showing contents of currently selected playlist) (multi-column, flat, configurable) (bulk of your work is in implementing this)
• tracks lists must use "model backed view", using QSortFilterProxyModel
• playlist may contain tracks (songs) OR other playlists (ie: like folders)
• when selecting a “Source” on the left, show the contents of that source on the right, in the “Tracks” list
• fully configurable and customizable list of meta data “sort columns” on the right, ability to hide / show / drag reorder as user wishes (old DB model & data provided, you create new DB model)
• ability to sort by any meta data column (quickly), sorts are "stable", ie: if user clicks to sort sort by artist THEN clicks to sort by song name, songs will be sorted by song name, but within each group of songs by the same name, they'll be sorted by artist. primary, secondary, tertiary etc. sort spec is remembered per playlist.
• drag and drop reordering of tracks (Rows) when sorted by “#” (no reorder when sorted by any other column), including dis-contiguous groups
• ability to drag and drop single or group from tracks list (on right) to other playlists (on left)
• searches must scale to hundreds of thousands of items, and be very quick (probably never more than 500k items, yet each item may have three dozen elements which may be strings, numbers, date / times, booleans etc)
• search function will search only the shown (visible) meta data columns, does NOT search in columns that are hidden
• search allows for these features. Specifically, support for quoted, numeric, targeted (only a specific sort column), and "exact"
• database updates / queries must never block UI thread (expensive ops must be on back thread, & obviously be thread safe)
• this is kinda done: ability to convert existing DB model to new DB model (so when new app is run, old data is sucked in and converted), then on subsequent runs it reads new DB data file(s)
• note some "playlists" are not part of the main DB (not stored in main table), and need separate persistent storage, merged in viewer upon running the app, but still separately saved. eg: music stores. users should be free to delete these DB tables in the file system between runs, and not mess up the main tables. users can turn these stores on and off at will in the preferences UI, they each have their own separate playlist (store) but also they (or a subset) MAY be included (shown) within the main Library playlist along with the rest of the user's songs (so it's a little tricky). alread kinda done: updating these stores (getting new catalog) must be done in such a way as to merge new changes without invalidating the existing song IDs)
• Similarly CDs, they have a separate playlist not shown in the library, but meta data is stored for them, so next time you put i the same CD, you see it's data
• currently the Library playlist just shows the ENTIRE (main) db table, but it should instead show a separate, curated table containing only the tracks we want to see in the Library (QSortFilterProxyModel) (ie: don't show music store songs unless the user turns that on, don't show songs from any mounted CDs)
• Bonus: ability to break out a copy of a playlist (tracks list) into separate window, showing only that tracks list, window has no adornment or other controls, but may be used for drag and drop. list shown will update if model is changed in any other viewer (renaming, add / remove / reordering etc)

In the provided VM

• you will have my already-working shell program which has:
  • menus and windows, commands are hooked up but may crash
  • “main browser” window shell where you will will find my preliminary explorations of creating the DB UI
  • old DB model code that works and loads a library, converting it. current DB stored in big binary file, current playlist data is stored in “plist” files (CoreFoundation xml) which can be read in (sample code provided)
• The reference app (kJams Pro) is already installed in the VM.

The Point of this project is to basically re-creating the kJams app functionality in Qt (64bit). This reference app already implements all of what is described above (in a 32bit app).

Milestones

10% payout at each milestone, with rest of payout at end / upon acceptance

1. convert Library playlist to showing separate Library table, instead of just showing the main (entire db) table
2. ability to configure and sort by meta data columns
   1. can load a "sort column set" via "ConfigureDataBrowser() / SetUserStateFromDict()" function, can save via CopyUserStateAsDict(), can drag reorder columns, can drag resize them, can add / remove them via context click (popup menu) in sort column header, can sort ascending and descending, sorts are stable (be sure you know what that means), and sorts are fast, obviously
3. ability to search and get search results
   1. implement all search functionality defined here
   2. search must be fast (ie: use fast search tables?)
4. ability to drag and drop a group from tracks list into playlist in sources list.
   1. Required: Implement Tree View
   2. implement playlists tables with Library being the main "playlist"
   3. also ability to drag-reorder tracks list while sorted by "#" (User Sort Order)
5. ability to load / update music stores correctly, with ability for user to delete them between runs, or turn them off / on in preferences
6. rest of work / finishing touches.