sleepyswords / do_todo

Do your todos!

Hi there

• I have no idea what I'm doing
• I am currently procrastinating on a a todo list tui
• My dotfiles
• Used to use Calender + (Yabai + Spacebar + Stackline) + alt-tab on Intel Macbook Air
• Now use neovim + Rectangle on M1 Macbook Air

Some badges :)

do_todo's Issues

Rewrite the draw system

It is extremely limited right now, the pop up boxes are extremely jank. This probably should be addressed.

The technical debt is getting pretty significant, I would probably place contexts within Rc, just so references to contexts can be made without annoying the rust ownership system. However, this pattern does not account for removing a context within a closure.

The draw system may use a context-based system where the component fetches the context from the app.

Another approach is to have two separate systems, one that handles the TaskStore and another that handles the Components. The component system would probably remove stuff by adding it to a queue and removing it on the next render. This way contexts can't be randomly deleted halfway through running a closure.

Other things:

• Use a widget trait/struct, (should contain a widget method)

Change the layout when resizing for a better experience.

If the window size becomes too small, change the layout (such as remove the viewer) for a better experience.

Add workspaces

Add workspaces (ie: a different file) so people can separate different to-do lists depending on context.

The workspaces should be easily accessible and easy to switch from one to another.

Use a form for tag creation

Rather than cycling through each field one after another, all the available stuff should be displayed as one large form.

This would need to require a rewrite in the draw system to be implemented.

Add a kanban board view layout.

Custom errors

So, I've been tinkering with the get_data() and save_data() functions as well as #26 (PR incoming) and I came across an issue of whether we should implement custom errors for, let's say, data not being able to be read from the file, etc. and then panic with them (?!) ? Or can we just make get_data() return "normal" tuple and, depending on the encountered conditions, just substitute them for default values? This is what I've already implemented, before I started thinking about this) I'd note that this makes pretty nice code, like the following:

let mut theme = Theme::default();

if config_path.exists() {
    if let Ok(config) = fs::read_to_string(&config_path) {
        if let Ok(theme_config) = serde_yaml::from_str::<Theme>(&config) {
            theme = theme_config;
        }
    }
}

Instead of this.

And another question would be, more generally, should we implement custom errors with potentially custom behavior or just leave Box<dyn Error> rule 'em all? If we implement a custom error type that would have kinds for all Errs that we encounter in the codebase, we could get rid of dynamic error dispatch and use a specific type in the function signatures.

Automatic task sorting

So, I think it would be pretty nice to have a feature to automatically sort tasks as they are added by their priority.
However, I'm not sure how we should implement this. Should we replace the existing s and S key toggles for one-off sorting to toggle automatic sorting, or we should add this as a separate keybind?

Additional question: do you think lowest-to-highest priority sorting is even useful? I mean, it's easier to implement, but is it really needed. If not, we could replace, say, S to be automatic sort, making s one-off highest-to-lowest sort (or vise-versa)?

Centralize input handling

So, currently, the input handling starts in main.rs in start_app(), but then cascades into stack_layout and so on. I understand, that it's tempting to implement it in an EDD style, but I don't see any benefit to that. Like, having some update() or draw() in that way makes sense, it forces all children of a component to be updated or drawn or whatever. But, at least currently, the implementation on StackLayout literally stops searching for a component that implements a given keybind after one is found, which doesn't require the EDD approach. This can as easily be written as a method on App or something, where all keys would be handled. Not only that, but the DrawableComponent::key_pressed literally inherently requires a &mut App, so it would be much less indirection to put it on App. + we would eliminate one argument, as &mut self would be the app and we would be able to access all components without an argument.

Also, while not bringing any benefits, this only seems to create a lot of confusion for new contributors (like me), who are trying to make sense of where's happening what. Because I have lost where which key is handled for the 5th time already and it's quite frustrating and an LSP doesn't help much with that kind of stuff either.

My idea is to, as I said, put everything in one method on App, at least for key handling. Although, I think mouse events could also be pretty easily migrated to App as well.

Add undo support

Rewrite the data storage

Data should not be stored in .config.

Add migrations for local storage

Migration should be added to local storage, so new features don't break existing data.

Add backups

Add a tag system

Add a tag or label system that is easily able to filter and customise. TUI's support Unicode emojis. Take advantage of that to design pleasant-looking tags.

Extended theming

Able to customise pretty much everything.
From the layout of the application to the style of the border.
May need to write a serializer/deserializer since tui-rs does not include these traits for some things. We should serialize a style struct rather than the colour enum.

Deserialization panicking on changes

What I noticed when working on #46 is that when I tried launching the app, it panicked at deserialization because the new auto_sort field wasn't found in the old data. The only way to fix that at the moment is to manually edit the data file, which isn't what a normal person would know about.

I would say fixing this is a priority for now.

Multiple instances saving race condition

If there's multiple instances of the app open and one closes them one-by-one, the only changes that remain are the ones from the most recently closed instance.

I'm planning on implementing hot-reloading, which should fix this issue, so by now, this will probably be hanging. Although, if you have a plan on how to fix this, it would be great if you could implement it.

Add the ability to filter

The ability to filter and sort tasks based on some factor should be added.

Add CalDev support

Might also add integration to other proprietary APIs, such as todoist.

Create sublists/folders