search

thombruce / toodles

✅ A super simple todo app
https://toodles.thombruce.com/
GNU General Public License v3.0
0 stars 0 forks source link

[Feature]: App Features #116

Open thombruce opened 1 month ago

thombruce commented 1 month ago

Feature request

Features present on packages/web which are not yet ready on packages/app

  1. Search/query todos from multibar
  2. Filter by open/closed (navigation via progress bar)
  3. Coloured tags
  4. Todos are editable inline
  5. Works in browser, using IndexedDB (though LocalStorage/other would also suffice)

Necessary features which are new to packages/app

  1. Select/manage multiple files/lists
  2. Child todos can be added/edited inline
  3. Interactive tags allow the creation of tallies, timers and repeatable todos
  4. Web version requires means of outputting the Toodles text format (possibly also of accepting it via copy/paste)
  5. Electron app requires icon, possibly also window sizing/restyling considerations
  6. PWA support ?? Would also require icon + additional considerations (not a priority)

Code of Conduct

thombruce commented 1 month ago

We're also using a form to add new todo items. This should make use of TntForm (with fixes) and accept a validation object.

We also need to be able to set:

And we need to add various page templates for filtering by...

  1. Focus (State)
  2. Open / Closed
  3. Priority
  4. Completed ?
  5. Created ?
  6. Due (this one definitely is useful - due this week? due today?)
  7. Project
  8. Context
  9. Hashtag
  10. Tag (of the form tag:value)

Ideally these filters would navigate to routes like /!, /*, /x, /(A), /+Project, /@Context, /#hashtag, /tag:value, however I know that hashtag one isn't going to be possible, I have doubts about others and I haven't provided any suggestion for the date-based routes (one date type would be easy, but there are three; maybe something like: /completed/2024-08-07, /created/2024-08-07, /due/2024-08-07 where the date part in each case could be a specific date, a partial date or a date range. Maybe these "smart paths" are attempting to be too clever. Maybe standard URL query parameters are actually the way to go? Downside? We wouldn't be separating out page logic. Upside? Filters would be more easily combined.

Note: I looked it up. Colon is valid in URL, so the only one suggested above that won't work is /#hashtag. In that case, we probably need to fall back on /tags/hashtag... and if we're doing that, we should probably also have semantic URLs for the others too; e.g. /projects/Project and priorities/A. But if we call hashtags "tags", what do we call tags of the form tag:value? /attributes? /properties? I think "properties" sounds the most right, and we could abbreviate it to /props too... We'll figure it out.