[HN Gopher] Dijo: A terminal-based habit tracker written in Rust
___________________________________________________________________
Dijo: A terminal-based habit tracker written in Rust
Author : catacombs
Score : 199 points
Date : 2020-07-20 18:36 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ijelliti wrote:
| Cool piece
| fardeem wrote:
| Love it! Everything should live in the terminal
| dllthomas wrote:
| Everything should be _exposed to the shell_ , IMO, which isn't
| quite the same thing.
| pjmlp wrote:
| Progress, who needs it.
|
| https://gunkies.org/wiki/UNIX_Sixth_Edition
| jjice wrote:
| I think both GUI and TUI applications have their place. For
| developers and people who are comfortable with it, a CLI can
| be really extensible, allowing for every application to be
| opened or used instantly from the same location, and you can
| automate series of processes. GUIs have their place too. Some
| applications are more ergonomic with a GUI. I think the two
| of them can live in harmony.
| b3kart wrote:
| From the perspective of UX of a power user, you'd need to
| convince me that all of these Electron apps is "progress".
| fardeem wrote:
| Progress isn't about having pretty apps. It's about giving
| people what they want.
|
| I want a thing in my terminal that I can use to track my
| habits
| mynameisvlad wrote:
| Sure, that's what _you_ want.
|
| I would argue that _people_ want a more traditional app
| instead, with what I 'm sure you'd consider a bloated and
| inefficient GUI. Considering that most people don't even
| know what a terminal even is, and that form regularly
| trumps functionality in day-to-day lives.
| deadbunny wrote:
| Then they already have multiple options for them to chose
| from...
| smabie wrote:
| I'm not opposed to GUI's, but they should function like Emacs
| or the Bloomberg terminal: efficient and dense display of
| information, keybindings, and preferably some way to input
| commands directly (where each keybinding is bound to
| command). Unfortunately, GUI apps today are all slow, based
| on electron, don't have any keybindings, and are designed
| with the assumption that the user is stupid.
|
| TUIs could be designed in a similar way to GUIs, but the
| culture around their development is much different. So while
| TUIs aren't inherently better (and based on their
| limitations, they should be worse), they almost always are.
| mynameisvlad wrote:
| > are designed with the assumption that the user is stupid.
|
| Probably because the average user _is_. I don 't mean that
| offensively, but literally everyone on this site lives in a
| tech power-user bubble. The average user doesn't care to
| have a dense display of information, keybindings, and ways
| to input commands directly. They want an easy to use and
| nice looking app that does what they want.
| cat199 wrote:
| these are not mutually exclusive
| rvz wrote:
| I know right. The same old UNIX crustaceans still want to
| relive the glory days of 1970 with "Everything should live in
| the terminal" with the chaos of X11, spending countless time
| editing their dotfiles or starting silly 'Vim/Emacs is
| better' wars. That ship has sailed. If not, already sunk.
|
| I found this toy to be very cute. Too bad my friends are not
| the typical software engineer that can use this. I'll just
| point them to a native macOS habit tracker on the app store
| instead. Friendly enough for them and efficient enough unlike
| the Electron alternatives.
|
| Actual progress rather than re-creating the prehistoric 'good
| old UNIX days' or turning the users laptops into stove
| burners with many Electron apps running.
| jsilence wrote:
| Wondering if and how this could team up with orger. Could be an
| effient combo.
| didip wrote:
| wow, I had no idea terminal UI can look good.
| badrequest wrote:
| Where is this data stored? The Wiki completely glosses over this
| subject, and I cannot tell from the code where it might save
| anything to (to be fair, I have never written in rust).
| [deleted]
| estebank wrote:
| Looks like it is stored in Linux:
| /home/alice/.config/dijo/habit_record.json Windows: C:\Us
| ers\Alice\AppData\Roaming\nerdypepper\dijo\habit_record.json
| macOS: /Users/Alice/Library/Preferences/rs.nerdypepper.dijo/h
| abit_record.json
|
| https://github.com/NerdyPepper/dijo/blob/master/src/utils.rs...
|
| https://docs.rs/directories/0.8.5/directories/struct.Project...
| p0llard wrote:
| I haven't run this, so perhaps the behaviour is different to
| what I'm expecting, but since it uses `XDG_DATA_HOME`
| (`data_dir` in the `directories` crate) I'd expect it to
| appear as
| /home/alice/.local/share/dijo/habit_record.json
|
| on XDG compliant Linux.
| StavrosK wrote:
| That's where it is for me, and not under ~/.config. It's a
| bit puzzling, because that's where I expected it to be.
| p0llard wrote:
| In general ~/.config is only for config; data should be
| in ~/.local/share, but a lot of programs get this wrong
| and abuse ~/.config using it for everything.
|
| Even worse are the programs which use it to cache runtime
| data; I should be able to add the entire ~/.config to a
| dotfiles repo without accidentally including personal
| data (other than that which might reasonably appear in a
| config file) or ephemeral data.
| StavrosK wrote:
| Fair enough, I guess this is actual program data rather
| than the config, you're right.
| badrequest wrote:
| thank you!
| float4 wrote:
| On macOS/Linux you can always use opensnoop to find all files a
| process accesses. Helped me many times.
| alias-dev wrote:
| They use the 'directories' crate (https://docs.rs/directories/3
| .0.1/directories/struct.Project...) to work out where the data
| directory should be, then write out to a json file. See
| 'src/utils.rs'
| kissgyorgy wrote:
| If you are interested in a Web or Mobile (PWA) version:
| https://github.com/kissgyorgy/every-day-calendar
| lloeki wrote:
| Funnily enough "un dijo" is short for "digestif" in french.
|
| https://en.m.wikipedia.org/wiki/Aperitif_and_digestif
| dgellow wrote:
| Though that would be "un digeo" (it's mainly a saying, not
| something people write often, so it doesn't matter that much)
| fareesh wrote:
| Can it track my time spent running vim in various folders? That
| would be useful for me since in some solo projects I don't really
| commit changes often.
| cl3misch wrote:
| I guess not by itself, but you can control it externally in the
| command line. You would have to write a daemon monitoring the
| folder yourself.
|
| https://github.com/NerdyPepper/dijo/wiki/Auto-Habits
| fwip wrote:
| Or a vim plugin. :)
| eredengrin wrote:
| ActivityWatch with a custom watcher might help with what you're
| looking for. Here's a list of some existing watchers, it looks
| like there's a vim plugin for it (haven't used the vim plugin
| myself though).
|
| https://docs.activitywatch.net/en/latest/watchers.html
| [deleted]
| itwy wrote:
| I can't shake the feeling of how ugly Rust code looks in
| comparison to Python, Clojure and Go.
| untog wrote:
| A matter of perspective IMO. Before I learned Rust it looked
| messy but now that I know it I don't think that at all. In fact
| the way you can use match statements and Result<T> structs make
| it quite beautiful to me.
| ruuda wrote:
| Please note that "cargo install" is intended for installing Cargo
| subcommands and Rust-related tools for developers, not for
| distributing general software to end-users.
| https://github.com/rust-lang/rfcs/pull/1200#issuecomment-120...
| dorkrawk wrote:
| Wow, I tried to solve a similar problem in a similar way (command
| line based progress tracker) with a small personal project called
| Trackstar: https://github.com/dorkrawk/trackstar but this is SO
| much nicer!
| aswinmohanme wrote:
| Does anyone have any idea, what font the screenshot is in ?
| adar wrote:
| Looks like Iosevka to me.
| ReverseCold wrote:
| Looked up the author's dotfiles repo[1], looks like it's
| Iosevka.
|
| [1]: https://github.com/NerdyPepper/dotfiles/
| [deleted]
| dilandau wrote:
| The rust community's insistence on ending every sentence "written
| in rust" is only slightly more annoying than the python
| community's "for humans" fetish.
| lewisinc wrote:
| I kind of like each community having a shared sense of pride
| and ownership in their respective spaces.
| gameswithgo wrote:
| this is a tech forum, it is common for the tech stack to be
| mentioned here when showcasing a product, whether it was
| written in Rust or a lesser language. (last sentence is a joke,
| stay calm)
| dilandau wrote:
| I was joking in my original comment fam
| mraza007 wrote:
| I love the terminal UI how did you create that
| xwdv wrote:
| curses
| d2161 wrote:
| This^! It looks amazing.
| jnetterf wrote:
| Looking at https://github.com/NerdyPepper/dijo/blob/8b91a7c0b3d
| 9bd4fac3..., it seems like it uses
| https://crates.io/crates/cursive
| mraza007 wrote:
| It looks amazing do we have something similar in python
| setr wrote:
| In pythonland, you get a whole slew of TUI widget libraries
|
| Eg blessed https://github.com/jquast/blessed
| stingraycharles wrote:
| In other words, the author did a lot of hard work to shape a
| fairly general purpose UI library into a very neat design.
| Kudos!
| felixr wrote:
| There is also the font selection and the borderless
| terminal which improve the aesthetics Without that it could
| look like this https://i.imgur.com/TVwkQI0.png
|
| But I agree, the author did really good job in creating a
| clean an visually pleasing UI only using text and standard
| symbols
| quodlibetor wrote:
| If this is all this is it actually doesn't look like a
| crazy amount of work to make cursive look good: https://git
| hub.com/NerdyPepper/dijo/blob/8b91a7c0b3d9bd4fac3...
|
| I've avoided looking too deeply into cursive in the past
| because I naively assumed it would be difficult to make it
| look like like anything other than a late-90s BIOS, but
| this is exciting.
| StavrosK wrote:
| This looks like a "draw the rest of the fucking owl"
| thing. Yes, it's not a lot of manual work, but I wouldn't
| be able to do it at all because I don't have a sense for
| design.
___________________________________________________________________
(page generated 2020-07-20 23:00 UTC)