Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow priority to be user-extendable #55

Closed
LanHikari22 opened this issue Apr 13, 2023 · 5 comments
Closed

Allow priority to be user-extendable #55

LanHikari22 opened this issue Apr 13, 2023 · 5 comments

Comments

@LanHikari22
Copy link

LanHikari22 commented Apr 13, 2023

Hi!

Problem Context:
I am not sure fully the intended distinction between task and event. but I basically consider events to be things like appointments and also time blocked out as commitment to complete some task. From this perspective, I would like to know not only that I have completed tasks but that I have also met the obligation for the events scheduled. For example, like knowing whether you did make an appointment or you missed it. So for this use case of mine specifically, it would be helpful to have be able to mark events with a fourth color. (Not unimportant, important, or normal).

Suggestion:
Generally I think it would be helpful to extend the possible color-states for events and perhaps tasks also. This could allow for user granularity of priority and also gives space to implement color coding for other purposes: (backburner, unimportant, normal, important, emergency, missed, completed late, completed on time, WIP, Testing, ...). This could be a user configurable list, each with an assignable color. For the keybinding, an identifier can be given by the user with the color state, like LO, HI, WIP. DONE. Then a key binding like L could be pressed and the user can type the identifier.

Thanks!

@LanHikari22
Copy link
Author

Let me know what you think of this, and if you would like me to implement and open a PR for it possibly.

@anufrievroman
Copy link
Owner

anufrievroman commented Apr 14, 2023

Let's see, now the possible statuses are provided in the Enum Status and can be:

  • NORMAL
  • DONE
  • IMPORTANT
  • UNIMPORTANT

These are common for both events and tasks, just events don't have a keybinding to change the status to DONE. But the use case you describe makes sense, so I think DONE state for events could be easily introduced (it's just that v is already occupied, but still). I'll do that, or if you have time, feel free to make a PR for that.

On the other hand, I'd strongly prefer to keep the predetermined statuses, because it is used in all kinds of imports and .csv reading (certain statuses in other programs are mapped to these statuses). If we allow users to rewrite these statuses, it will be difficult to maintain all that functionality. Plus, I am not sure how many people would really need such a precise control.

I think the functionality that you describe could be implemented with a system of tags. In config, user can create custom tags (or icons) and corresponding colors. Then, everything can get a tag (or a few tags). I am just not sure how to visualize the tags in TUI interface (Maybe with some icon or something).

On this topic, as discussed in #45 I also plan to introduce DOING status to create Kanban workflow.

@anufrievroman
Copy link
Owner

So, in version 2.9 I made it so that events can also be marked as "done" with d key. This basically only changes the color, but I'll also add the strikethrough decoration later, like in tasks.

@LanHikari22
Copy link
Author

Sorry I didn't see. Marking an event as done adds underscores everywhere:

image

It makes it a bit hard to read. I assume only a color change was intended, or maybe an underline? Also I noticed the Go to date functions implemented, that's very useful thank you!

@anufrievroman
Copy link
Owner

anufrievroman commented May 26, 2023

Oh, I see, it is intended to be like this:
image
However, looks like your terminal does not like that, so you can switch it off in your config.ini:

[Styles]
strikethrough_done_tasks = No

Or on the most recent version 2.9.3 it's renamed and switched off by default:

[Styles]
strikethrough_done = No

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants