[HN Gopher] Show HN: Grit - a multitree-based personal task manager
___________________________________________________________________
Show HN: Grit - a multitree-based personal task manager
Author : climech
Score : 107 points
Date : 2021-04-02 16:54 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| nojvek wrote:
| Omg! This is an exciting idea. I want to build a small react
| version of this. Tree based tasks list are a thing I've always
| wanted to build.
| tingletech wrote:
| cool. Is there a way to convert a sub-task to a sub-sub-task?
| Where does it keep the local sqlite database file?
| kbd wrote:
| How do you handle ordering?
|
| I noticed: $ grit add -p 5 Bread (5) ->
| (6) $ grit add -p 5 Milk (5) -> (7) $
| grit add -p 5 Eggs (5) -> (8)
|
| led to: +--[ ] Get groceries (5) |
| +--[ ] Bread (6) | +--[ ] Eggs (8) | +--[ ]
| Milk (7)
|
| And I didn't see anything about reordering tasks in the readme.
| Is everything sorted by title?
| climech wrote:
| Yes, it's sorted by name in natural order. I haven't decided
| yet which would work best as default (this vs insertion order)
| -- feedback is welcome. This works well for numbered book
| chapters, something I personally find useful. In any case, the
| defaults will be configurable -- when I implement config :)
|
| (Another thing on the TODO list is adding an optional priority
| score for each task, and sorting those on top of the list in
| all tree views.)
| tunesmith wrote:
| What's the difference between a dag and a multitree? The
| wikipedia article was confusing - it seems that it prevents
| diamond shapes? Like where 1 leads to both 2 and 3, and where 2
| and 3 both lead to 4?
| climech wrote:
| >prevents diamond shapes
|
| Pretty much this, unless I'm missing something. An earlier
| version of the program actually used DAGs, but I found it a
| little underconstrained. I got pretty excited when I discovered
| multitrees, as it seemed to be exactly what I needed the whole
| time.
| gradys wrote:
| Why is the no diamond constraint useful here?
| climech wrote:
| Without it, the structure allowed the user to create a
| graph like this: [x] Task +--[x]
| Sub-task (1) | +--[x] Sub-sub-task (2)
| | +--[x] Sub-sub-task +--[x] Sub-task (3)
| | +--[x] Sub-sub-task (2) | +--[x] Sub-sub-
| task +--[x] Sub-task
|
| by creating a link from (3) to (2). The tree command would
| actually omit the second occurrence of (2), since the
| algorithm visited each node just once.
| ssivark wrote:
| Precisely; a multi-tree has a unique path between two nodes.
|
| On the same note, I wonder what is the relation between
| dags/multitrees and semilattices. They seem to be very similar
| concepts afaict.
| tunesmith wrote:
| Oh, so you can only crosslink from different root nodes. That
| makes sense.
|
| There are so many ways to structure todos. In this case, it
| appears to be using subtasks specifically to break things
| down in various ways, and it's a cool implementation.
|
| I personally think of todos as having dependencies, like a
| simplified PERT chart, which would more require a DAG. If I
| brought in the ability to generalize groups of that graph (or
| in the other direction, take a general node and "break it
| down" into a group of nodes), I guess I'm thinking of a
| multi-graph there. That sounds really hard. :)
| renewiltord wrote:
| I use a flat text file with exactly this structure, just
| indenting when I need a new layer.
|
| I tried fiddling with it with vim folds but in the end just ended
| up deleting things I finish.
|
| I learned this from a friend at work.
| frutiger wrote:
| From a quick glance at the README this supports a slightly more
| interesting structure than an indented text file: it's actually
| a DAG where large subgraphs are trees. This allows links
| between different nodes. That's not possible in an indented
| text file.
| slaymaker1907 wrote:
| TiddlyWiki uses a similar data model for table of contents by
| default and I love it! I think the multitree constraint is a good
| idea over a general DAG.
| stilisstuk wrote:
| Tiddlywinks is one of those things that is too good to actually
| monetize. It's amazing software. In you can run on it on a
| server or on an a flasdrive. Or just from dropbox.
| Flockster wrote:
| Wow a very cool idea. The idea of many root nodes for different
| views seems interesting. Unfortunatly it does not build on my pc,
| it seems to import an absolute path in the go build command of
| the Makefile, which it can not do. (cannot import absolute path)
|
| Since I never really worked with go, I don't know where to start
| here.
| climech wrote:
| Thanks! Please open an issue on github if have an account
| there. System information would be particularly helpful.
| fluidcruft wrote:
| This looks pretty interesting! How is the data stored? Would it
| be difficult to sync among different machines?
| morsch wrote:
| Seems like it uses sqlite. Presumably it's trivial to sync
| using whatever file sync tool you want (Dropbox, or whatever)
| as long as you're fine without concurrent editing. For that
| you'd need application support or a more amenable data
| structure.
|
| https://github.com/climech/grit/blob/master/db/db.go
| climech wrote:
| Just SQLite - two tables, one for the nodes, one for edges +
| some fancy constraints and queries. I was tempted to make a
| custom binary format, but that's a big task, and it seems to
| work fine as it is.
|
| As for the syncing, that would be really nice, but I haven't
| come up with an elegant way to do it yet. Suggestions welcome,
| if anyone has ideas!
___________________________________________________________________
(page generated 2021-04-02 23:00 UTC)