Add options to show dates (esp. Due Date) as relative ("Today"/"2 days from now"/"2 weeks from now") on each item

[DeflateAwning]

Feature Request

Description: In the list item view, it would be helpful to see each item's Due Date as a relative date, relative to today. It would still be stored as a yyyy-mm-dd date in the file, but it would be displayed as a relative date.

The benefit is that it would be easier to identify intuitvely and quickly what items are due soon.

Implementation Details: Maybe this could be a setting in the settings?

[ransome1]

@DeflateAwning a first proof of concept can be found in this pre-release. It is based on what the library, which is taking care of the date processing in sleek, can do out of the box without a lot of configuring. The function needs to be turned on in the settings. Let me know what you think.

[swantzter]

@ransome1 I've tested this a bit and the following pops up for me

1. Can it be configured to never go below day precision. With todo.txt not having a time component "in 14 hours" feels worse than "in 1 day" (or ideally "tomorrow")
2. Could it switch to show the YYYY-MM-DD format on hover?
3. When it's further than a couple weeks in the future it'd be more relevant to show the date instead imo, but maybe human friendly "May 24" (or "June 25, 2025" for different year)

[DeflateAwning]

Awesome work! Tried it, and I like it very much!

Agree with the hours comment; "yesterday" and "tomorrow" are the way to go imo.

Hover could be cool, but not MVP.

Agree with the distant future thing (maybe 30 days is the threshold); also not MVP though.

[DeflateAwning]

The way this works out is a little quirky too. Would be fantastic if it could be grouped by the way the string appears though, as it makes a lot of sense. Filtering to "stuff due 4 months ago" is way more useful than picking out specific dates.

[ransome1]

I think this is the point where we need to admit we need a proper thought through concept for this.

[DeflateAwning]

I mean, I actually think we're on the right track with it, and I think this is already more useful to me than the old way.

If these things happened, I'd say it's completely valuable:

1. Make it so that hours never show. "yesterday", "today", and "tomorrow" are the only values.
2. Group together all buttons with the same "a month ago" and "2 months ago" text in the filters, instead of keeping them all separate.

What sort of concept were you thinking?

[ransome1]

@DeflateAwning @swantzter @strannik46 I continued working on this in order to make this a proper feature. It needed quite some additional logic in some places but also removed some. In any case, this needs proper testing and I could need your support here. You can find it in the latest pre-release: https://github.com/ransome1/sleek/releases/tag/v2.0.12-rc.1

In a nutshell, it should:

• add logic to display today, tomorrow, yesterday, next week & last week (that's what the library supports in terms of calendar replacements)
• add logic to summarize equal filters into one

The outcome should look like this:

Filtering, exclusion and everything else should work as before.

[DeflateAwning]

This is beautiful, and was exactly what I was envisioning. This may be even better than my date range filter request (#578). Well done!

[ransome1]

It still needs quite some refactoring and even some fixing. For instance using the attributes in the todo list, does not work yet. Feel free to incorporate it into your daily usage and let me know what else needs improvement.

[rzw]

Very nice. In line with last and next week I'd like to propose "this" in variants:

• this week
• this month

[ransome1]

We can enhance the date concept a little bit and make it work like this:

[ransome1]

There is one issue though I am not able to solve. The button this month can not include filters, which are included in other buttons.

In this example you will see that this month only contains 2 items. It does not include the ones from today, tomorrow, this week and next week.

Also does this week not include today and tomorrow.

This is confusing and I am not sure if I can solve this programmatically the way this whole system works without completely rewriting it.

[rzw]

Oh, well. It was just an idea.

I thought those "drawers" were hard-coded filters

[ransome1]

No, it's fully dynamic. Let's see what I can do about it.

[ransome1]

@rzw @DeflateAwning @strannik46 @swantzter I continued working on this feature and can use some testing and feedback: https://github.com/ransome1/sleek/releases/tag/v2.0.12-rc.3

It does not contain any enhancements on the todo list groupings, when for example due or t are used as primary groups.

[rzw]

RC3 installed. I will be using "this week" quite frequently and will give feedback.

What I noticed right upfront: "this month" is not March but March starting from tomorrow

[ransome1]

What I noticed right upfront: "this month" is not March but March starting from tomorrow

Thanks for the hint, fixed it.

[bughunter2]

The shown value seems to be off by 1. For example, an item with a due date of March 1 was shown as being 4 days ago (today on March 4), but it should be shown as 3 days ago.

Feature looks good though. Nice addition! :smiley:

For now this is what I found. I'll see if I can test some more.

[rzw]

I've worked with the RC. Here's my opinion:

As I had anticipated, this week is really useful and I use it a lot. For me personally the following human readable attributes (would) come in handy:

• overdue for everything older than today
• last week
• yesterday
• today
• tomorrow
• this week
• next week
• this month
• next month (when your beyond day 20 of the current month this seems sensible)

But as it would appear to an outsider, except for yesterday, today, tomorrow which are explicit dates, these are predefined filters and I could live without, since it used to be and hopefully will be again possible to define filters yourself. It's broken now though (see last lines).

I assume the reason is here:

The button this month can not include filters, which are included in other buttons...Let's see what I can do about it.

Logically it's also not consistent to have in 20 days describe a specific date while in 1 year is a period.

This is my point of view: It is nice to have yesterday, today, tomorrow human friendly in the date attributes. Otherwise one has to look out for the last red dots which is not very elegant. Aside from that it get's complicated programmatically and confusing to work with. I would get rid of the switch "Use human friendly dates". Just have calendar dates in the attributes with the three exceptions mentioned above. Predefined filters with weekday and month logic (see list above) would be nice but aren't vital. Filters like due: > yesterday && due: < tomorrow+6d for the next 7 days are completely fine. And the user can create these her-/himself,

But again: due: > yesterday && due: < tomorrow+6d is broken due: > yesterday && due: < tomorrow which returns today, works.

[ransome1]

Logically it's also not consistent to have in 20 days describe a specific date while in 1 year is a period.

The way it works right now is for us to define some attributes by hand (except for overdue, this has been done more or less) and then as for the rest we need to decide if either:

1. we show all future dates, that don't fit into our definition, as actual dates YYYY-MM-DD
2. or use the dayjs, the library we use in sleek for date operations, to return friendly dates.

With option 1. we will most likely dissapoint users who have many todos in the future and will then face lot's of attribute button.

With option 2. we will have the advantage of some sort of grouping, but the logic behind it comes from dayjs and as you said, might lack consistency from time to time. I am happy with option 1. since I think having many dates in the far future and wanting those to be grouped, might be rather an edge case.

Otherwise one has to look out for the last red dots which is not very elegant.

This I don't fully understand, can you elaborate please?

Just have calendar dates in the attributes with the three exceptions mentioned above. Predefined filters with weekday and month logic (see list above) would be nice but aren't vital.

It is then just a matter of time, before others will ask to have it implemented in the list itself as well as in the groupings of the list too.

Anyhow, it currently looks like this:

[rzw]

Otherwise one has to look out for the last red dots which is not very elegant.

This I don't fully understand, can you elaborate please?

Well of course if you know today's date... ;-) Otherwise: Everything after tomorrow has black dots. Before that dots are red. So selecting today without human friendly dates means look for the last two red dots.

I'm fine with everything you find suitable. BUT if these friendly dates are at the cost of breaking filtering possibilities I'd rather miss human friendly dates than filtering

due: > yesterday && due: < tomorrow+6d is broken due: > yesterday && due: < tomorrow which returns today, works.

[ransome1]

Well of course if you know today's date... ;-) Otherwise: Everything after tomorrow has black dots. Before that dots are red. So selecting today without human friendly dates means look for the last two red dots.

The color coding here is connected to the notification threshold in your settings. If a todo is below that threshold (basically the amount of days from today) a todo is let's say notification worthy and at the same time receives the red coding.

due: > yesterday && due: < tomorrow+6d is broken due: > yesterday && due: < tomorrow which returns today, works.

I believe there is another issue where this has been raised. This feature had been developed by @zerodat and maybe he can give an update on this.

[rzw]

Ah, I see. I guess you're referring to #647.

Well that shouldn't be closed then, should it?

[ransome1]

@bughunter2 @rzw @DeflateAwning @swantzter The latest progress can be found in this pre-release. Feel free to use it as daily driver and let me know, if it can be released.

[bughunter2]

Just downloaded v2.0.12-rc.4. Some thoughts:

Good idea to show 'last week' or 'next week' rather than the number of days!

Minor issue:

The 'due' text can be shown as 'overdue' even if the day falls within the 'last week' according to the calendar widget in Sleek. For instance, some regions/locales use Sunday as the first day of the week rather than Monday. That may be related, but I'm not sure. What I observed was this: I had a todo item with the due date set to March 3, 2024. At the time, it was March 16, 2024. The calendar widget in the due date picker shows March 3 in the same row as the other days of last week, but the item's due was shown as 'overdue' rather than 'last week'. If we picked March 4 (Monday), it was shown as 'last week'. The tested system had the default US region/locale settings where Sunday is the first day of the week.

[ransome1]

Yeah, this sounds like an issue with the locale setting. Let me see, if I can reproduce this.

[rzw]

1. we show all future dates, that don't fit into our definition, as actual dates YYYY-MM-DD

With option 1. we will most likely dissapoint users who have many todos in the future and will then face lot's of attribute button.

I've installed RC4 and like the date attributes very much. I don't think the above is an issue. You can't do it right for everybody. I can only recommend to use thresholds freely in order to avoid the issue of getting overwhelmed with attribute buttons.

[zerodat]

Regarding:

due: > yesterday && due: < tomorrow+6d is broken
due: > yesterday && due: < tomorrow which returns today, works.

I find that this works for me in the current version of sleek. That is, the first line is not broken, but properly returns todos scheduled for today or the next 6 days. Please provide a more detailed example of how this fails for you, including test data and query string.

[rzw]

Bug Report

App Version: v2.0.12-rc4

Platform: Windows 10 (up-to-date)

Installation Method: portable/zip extracted

Expected Behavior: Filter should do the math as described in wiki

Actual Behavior: As soon as an operator (+) is entered interim results disappear and don't come back. The setting of "human friendly dates" is irrelevant.

Steps to Reproduce: see description "Actual Behaviour"

Screenshots (on 2024-03-17):

[ransome1]

A bug report in a feature request, this is new to me ;) Also we're losing focus here!

@rzw there is an open bug report on the search expressions: https://github.com/ransome1/sleek/issues/647

[ransome1]

Just downloaded v2.0.12-rc.4. Some thoughts:

Good idea to show 'last week' or 'next week' rather than the number of days!

Minor issue:

The 'due' text can be shown as 'overdue' even if the day falls within the 'last week' according to the calendar widget in Sleek. For instance, some regions/locales use Sunday as the first day of the week rather than Monday. That may be related, but I'm not sure. What I observed was this: I had a todo item with the due date set to March 3, 2024. At the time, it was March 16, 2024. The calendar widget in the due date picker shows March 3 in the same row as the other days of last week, but the item's due was shown as 'overdue' rather than 'last week'. If we picked March 4 (Monday), it was shown as 'last week'. The tested system had the default US region/locale settings where Sunday is the first day of the week.

Could you please check RC5 and give me a quick feedback, if this solves the issue on your end?

https://github.com/ransome1/sleek/releases/tag/v2.0.12-rc.5

[rzw]

A bug report in a feature request, this is new to me ;) Also we're losing focus here!

@rzw there is an open bug report on the search expressions: #647

I apologize and agree. We're digressing in this thread but I didn't know where to put my comment. After all, it was a direct answer to @zerodat:

I find that this works for me in the current version of sleek. That is, the first line is not broken, but properly returns todos scheduled for today or the next 6 days. Please provide a more detailed example of how this fails for you, including test data and query string.

And regarding #647, I myself commented here:

Ah, I see. I guess you're referring to #647.

Well that shouldn't be closed then, should it?

I see it's been opened again. I am looking forward to testing RC5 today or tomorrow. Thanks for providing the new RC.

[ransome1]

I see it's been opened again.

Yeah, there seems to be some kind of automation, which closes features once they had been added to a release.

Thanks for providing the new RC.

@bughunter2 @rzw @DeflateAwning @swantzter if you guys give me a thumbs up here, I will wrap this up and distribute it as v2.0.12.

[rzw]

Could you please check RC5 and give me a quick feedback, if this solves the issue on your end?

This was voiced towards @bughunter2 alias Jelle Geerts from the Netherlands (Surprise here regarding his stance). There is no right or wrong regarding Monday or Sunday being the first day of the week. But Religion aside Saturday and Sunday are called weekend not weekturn ;-). Since it's a matter of taste I'd look for something to hold onto and that's ISO 8601, making Monday the first day of the week. But as long as I know I am easy with both.

Or...Time for another switch? Many calendars make this configurable. And after all, @ransome, you've programmed both already. ;-)

[bughunter2]

Could you please check RC5 and give me a quick feedback, if this solves the issue on your end?

This was voiced towards @bughunter2 alias Jelle Geerts from the Netherlands (Surprise here regarding his stance). There is no right or wrong regarding Monday or Sunday being the first day of the week. But Religion aside Saturday and Sunday are called weekend not weekturn ;-). Since it's a matter of taste I'd look for something to hold onto and that's ISO 8601, making Monday the first day of the week. But as long as I know I am easy with both.

Or...Time for another switch? Many calendars make this configurable. And after all, @ransome, you've programmed both already. ;-)

@rzw Not sure what you're surprised about? I tested Sleek in a VM that has the US locale which uses Sunday as the first day of the week, hence I observed the issue I detailed. I don't consider myself religious. I just voiced my opinion about the matter because I value consistency. If the calendar widget (in Sleek) shows a certain day as the start of the week (depending on the locale), then the whole application should be consistent with what is shown. That's all I meant to say. I don't really care otherwise.

[bughunter2]

@ransome1 Thumb-upped! :+1: :slightly_smiling_face:

[ransome1]

Quite a while ago, when implementing the date picker, we were struggling quite a bit with this. The initial idea was to decouple the 1st day of the week setting from the language with a dedicated setting. But the date picker was simply not accepting this in its latest version. The only thing it was receptive to, was the locale. This lead to the workaround that we have now, where the English setting represents en_US and hence Sunday as the 1st day of the week an English (GB) simply en_GB and Monday as the 1st day of the week. This is not my preferred solution, but at the time the only working one.

If we want to optimise this, we would need to make the date picker responding to a manual switch of the 1st day of the week. Maybe with more research and trial and error, this can be done somehow. But looking at the backlog and my current capacities (basically not existing at the moment ;)) it is one of many outstanding enhancements.

If you guys know somebody who knows hers or his way around JavaScript, HTML, CSS, Electron or React, I would be happy if you could mention this project.

[rzw]

@ransome1 Thank you for the explanation. So, by choosing either en_US or en_GB one is free to adjust the first day of the week. In my case english is not my native tongue but I choose english on my PC for an easier match between gui and manuals (sometimes only in english). Since it is possible to change the language for Sleek independently one doesn't even have to change the locale of the OS. I completely agree to categorizing this as an enhancement.

@bughunter2 I didn't understand what you were going for (receptiveness for locale plus consistency). So, I was surprised to see someone from Europe opt for (as I erroneously understood it) Sunday as beginning of the week.

[bughunter2]

@ransome1 Your stance is very understandable. Move on to more important things :+1:

@rzw Ah I see; guess I was thrown off by the reference to religion. I'm glad we understand each other better now.

Happy hacking! :smiley:

[ransome1]

@bughunter2 @rzw I think I found a solution for the week start issue, which is not a workaround. In the latest pre-release you can find a setting which helps you defining the 1st day of the week. I also removed the duplicate English (GB) entry, since its sole purpose was to provide the 1st day of the week.

https://github.com/ransome1/sleek/releases/tag/v2.0.13-rc.1

Let me know if it works as expected.

[bughunter2]

@ransome1 Cool! Just as we kind of decided to move on, you fix the problem. Hats off.

While testing I found these behaviors:

If you launch the app for the first time, when the 'Language' setting has no value yet (shown as empty), the 'First day of the week' setting has no effect.

The first day of the previous week is never reported as 'last week' but as 'overdue' instead (as reported earlier). Maybe this is a simple off-by-one error? Like using < or > instead of <= or >= ? This happens regardless of the 'First day of the week' setting.

[dlaidig]

To add the thoughts I mentioned in #511 in the appropriate place:

• sleek-2.0.12 shows "t: elapsed" instead of "t: 4 days ago" like in a previous pre-release. This is really not useful for threshold days since non-elapsed tasks are hidden anyway.
• When changing the filter to show tasks with threshold dates in the future, I noticed that for tasks with "t:2024-04-01" it shows "t: next month". I guess this is technically true, but it gives my brain the impression that I still have a few weeks before this gets relevant. I would rather prefer to see "t: in 5 days".

After reading the discussion in this issue, I understand that the rationale for the current approach is to group similar date ranges in the filter. Two thoughts about that:

• Do the user friendly dates in the filter have to be the same as the user friendly dates in the badges inside the tasks? It might be useful to filter tasks that are due within the next week, but in the task list, "in 3 days" and "in 7 days" is a big difference.
• I really do not understand the point of groups like "next month" which are calendar-based. The whole point of user friendly dates is that I don't have to remember the current date. "Next month" can mean something between 1 and 60 days. I would prefer user friendly dates based on rounding the relative number of days and showing it in the next bigger unit. This is also the case for the examples given in the issue title ("2 days from now"/"2 weeks from now").