-
-
Notifications
You must be signed in to change notification settings - Fork 115
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
Add options to show dates (esp. Due Date) as relative ("Today"/"2 days from now"/"2 weeks from now") on each item #609
Comments
@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. |
@ransome1 I've tested this a bit and the following pops up for me
|
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. |
I think this is the point where we need to admit we need a proper thought through concept for this. |
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:
What sort of concept were you thinking? |
@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:
The outcome should look like this: Filtering, exclusion and everything else should work as before. |
This is beautiful, and was exactly what I was envisioning. This may be even better than my date range filter request (#578). Well done! |
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. |
Very nice.
|
There is one issue though I am not able to solve. The button In this example you will see that Also does This is confusing and I am not sure if I can solve this programmatically the way this whole system works without completely rewriting it. |
Oh, well. It was just an idea. I thought those "drawers" were hard-coded filters |
No, it's fully dynamic. Let's see what I can do about it. |
@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 |
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 |
I've worked with the RC. Here's my opinion: As I had anticipated,
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:
Logically it's also not consistent to have 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. But again: |
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:
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.
This I don't fully understand, can you elaborate please?
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. |
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.
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. |
Ah, I see. I guess you're referring to #647. Well that shouldn't be closed then, should it? |
@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. |
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. |
Yeah, this sounds like an issue with the locale setting. Let me see, if I can reproduce this. |
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. |
Regarding:
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. |
Bug ReportApp Version: v2.0.12-rc4 Platform: Windows 10 (up-to-date) Installation Method: portable/zip extracted Expected Behavior: Actual Behavior: Steps to Reproduce: |
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 |
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:
And regarding #647, I myself commented here:
I see it's been opened again. I am looking forward to testing RC5 today or tomorrow. Thanks for providing the new RC. |
Yeah, there seems to be some kind of automation, which closes features once they had been added to a release.
@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. |
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. |
@ransome1 Thumb-upped! 👍 🙂 |
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. |
@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. @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 @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. |
@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. |
To add the thoughts I mentioned in #511 in the appropriate place:
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:
|
… reverting default filewatcher configuration to pre 2.0.12
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?
The text was updated successfully, but these errors were encountered: