3 ms·
my workflow is like this on OS X: 1. use hotkey to capture screen or portion of screen 2. screenshot is automatically stored as PNG on Desktop 3. click-drag
by idm 11y ago
my workflow is like this on OS X:
1. use hotkey to capture screen or portion of screen
2. screenshot is automatically stored as PNG on Desktop
3. click-drag PNG onto gthnk attachments target
4. done. now it is stored with that day's entries
Updated to add: the PNG itself is stored in a SQLite3 database. However, each night gthnk exports the database to the filesystem because, for future retrieval purposes, I think it will be easier to retrieve items from a filesystem than an obscure database format.
- hackuser 11y ago> each night gthnk exports the database to the filesystem because, for future retrieval purposes, I think it will be easier to retrieve items from a filesystem than an obscure database format. In 20 years, how do I know which binary blob goes with which text file, and also with what point in each text file? I want add: It's so wonderful to hear a developer concerned with these issues. Almost always, future-proofed data is an accident or afterthought, which means I can't depend on it being implemented well or being supported in the long term. It puts gthnk on my shortlist.
- idm 11y agoI will need to document this, but it's an important question. - All attachments are named using the datestamp, so the first attachment today would be called 2016-01-19-0.pdf or whatever. - The entries are also named using the datestamp, so we end up with a text file like 2016-01-19.md. - The markdown itself contains an explicit link to the attachment; it is automatically inserted during export. - However, datestamp acts as a primary key so that entries and attachments can be paired using another technique. Finally, attachments are linked to days. It is not currently supported to associate an attachment with a specific entry on any given day.