ToDo List

[jarun]

Continued from #135.

Notes

The list below is a growing one. While suggesting new features please consider contributing to Buku. The code is intentionally kept simple and easy to understand with comments. We'll be happy to assist any new contributor. We need your help!

Some of the fresh-baked features may not have been released yet. Grab the master branch for those.

Identified tasks

• [ ] Android app (using the same database) (probably a distinct project)
• [x] Text-mode user agent for Buku
• [x] Read default Firefox profile name from profiles.ini (see #212, thanks @alex-bender)
• [x] Support --format in search results (ref, thanks @mosegontar)
• [x] API documentation (comments need to be in NumPy format) (thanks @mosegontar)
• [x] Auto-import: optionally add parent folder name as tag, ask for unique tag [like importdb()]
• [x] Support custom colours (thanks @shv-q3)
• [x] Generate packages on Travis-CI using PackageCore (see #189) (thanks @shaggytwodope)
• [x] Search multiple tags, exclusion in tag search (thanks @mosegontar)
• [x] Auto-import Firefox and Google Chrome bookmarks (thanks @alex-bender)
• [x] Suggest tags those go together
• [x] Append/overwrite/remove tags from prompt
• [x] Rest API for webapps (thanks @kishore-narendran)
• [x] Add more tests (ongoing activity @rachmadaniHaryono)
• [x] A browser plugin (thanks @SamHH for bukubrow)
• [x] Text editor support (thanks @ZwodahS)
• [x] Need a PyPI maintainer (thanks @shaggytwodope)
• [x] Make refreshdb faster using threads (record updates should be synchronized)
• [x] Show usage count in tag list
• [x] Proxy support (thanks @denisfalqueto)
• [x] Continuous search at prompt
• [x] Add prompt help
• [x] Specify custom DB file to class BukuDb (library usage, no exposed option)
• [x] Move to urllib3
• [x] Handle redirects using referrer masking. Example URL. Fixed with urllib3.
• [x] Support URL shortening. This helps to share URLs. (see #92 for limitations)
• [x] Make a bookmark title immutable via refreshdb()
• [x] Markdown import/export
• [x] Regex search
• [x] Ubuntu PPA (thanks @shaggytwodope)
• [x] Export specific tags to HTML
• [x] Exact word match using REGEX. Make substring match optional.
• [x] Delete all records based on a search result
• [x] Delete multiple items, support combination of indices and ranges
• [x] Append tags
• [x] Travis CI integration
• [x] Ubuntu deb package generation on new tag
• [x] Merge bookmark database files (for users who work on multiple systems)
• [x] Export bookmarks in FF or Chrome html format.
• [x] Option to add folder names as tags while importing HTML (thanks @mohammadKhalifa)
• [x] Check and show upstream version
• [ ] Anything else which would add value (please discuss in this thread)

[rachmadaniHaryono]

@jarun sorry it may take some time as i focus on other things on these recent days

[jarun]

Sure! Please take your time.

[jarun]

@questor are you working on the plugin framework?

[jarun]

Also @questor, please raise a PR for the template stuff so we can review it.

[questor]

I'm thinking through the stuff and the things I want to have (which of course might not necessarily is the same the rest want to have). my current idea is to have a template-output (already done, will make a PR later) with the possibility to have a static webpage with the output and some javascript code to make filtering in the page (something like filtrify). here bringing plugins into play would mean (when I want to use additional infos in the html-export) that I have to make special handling of template export for plugins (which also would mean bigger changes needed) or I can somehow put the additional infos into the main database of buku and the export-plugin can use the "normal" database to do the export with the additional information from other plugins.

I opted for the "template-export" orthogonal to "plugin-concept" approach simply because it's easier to code as I'm not a python-guru myself. but I can push what I have so far (but I have to admit it's not that much up to now). the more extensive option would be to make the template-export somehow aware of plugins and make the export query the plugins for more information (more work, but cleaner design).

[jarun]

If the requirement is to have a template from which a static webpage can be generated I don't think we would really need a plugin. Have the template and build it up by fetching data from the webpages separately. What one really needs is the links. Why would we need to store additional data for this requirement in the Buku database. If you want a cool page, you need to ave the thumbnails which would need page fetches anyway.

[questor]

okay, you are thinking about a datascraper-plugin and another export-plugin or something combined thinking about an export-plugin using the buku-db-url, downloading some more data and doing the export? having two separate plugins would allow to use custom data-scraping plugins also for normal database population, but having the additional data in an extra database would mean that using the special data in an export plugin creates an dependency hierarchy (export plugin X needs scrape-plugin A and B to be able to work correctly).

my approach would have been to make separate scrape-plugins (with the tables in the main-database) and an generic export-plugin where you can specify from where to take the data to insert into the page (and the possibility to specify multiple tables in one page).

To get things going I try to do an complete example to be able to transport my idea what I want to have and then you can decide if you want to go that way or another one.

[jarun]

My idea is pretty straight for this plugin (set of plugins): get the urls from the DB and do whatever you want with your own data.

[jarun]

Rolled at #233.