search

ransome1 / sleek

todo.txt manager for Linux, Windows and MacOS, free and open-source (FOSS)
https://github.com/ransome1/sleek/wiki
MIT License
1.28k stars 99 forks source link

Message 'No todos in this file' after a task has been completed #692

Closed mdbdb closed 3 months ago

mdbdb commented 3 months ago

Bug Report

App Version: 2.0.12

Platform: Linux

Installation Method: App Store (Flatpak)

Expected Behavior: If I mark a task as completed, it should disappear from the list - all other (uncompleted) tasks should remain visible.

Actual Behavior: I mark a task as completed, then all tasks disappear from the list and the message 'No todos in this file' is displayed. I can now close the file and reopen it - so all uncompleted tasks are back. Or I can just change the window size and all tasks will reappear.

I noticed this behavior for the first time after updating to version 2.0.12. And the error really occurs every time I check off a task.

Steps to Reproduce:

  1. open the app
  2. mark a task as completed
  3. --> List empty, message 'No todos in this file'
  4. change the window size
  5. unfinished tasks are displayed

Screenshots:

  1. before I have marked a task as completed sleek-1
  2. after I have marked a task as completed sleek-2
  3. after I have changed the size of the window sleek-3
ransome1 commented 3 months ago

@mdbdb is there by any chance some file sync happening in the background, for example Synchting, Dropbox, Google Drive and so forth?

ransome1 commented 3 months ago

@mdbdb @TriggerDingus in 2.0.12 we were tweaking the filewatcher settings a bit, because some had issues with sleek and file syncing applications. Actually this has been a constant pain for years now. We also introduced new settings to tackle difficulties, which could arise in environment, where there is file syncing involved.

@aisbergde @RobLW @42web-ch this is also a heads up for you guys. In the next pre-release (2.0.13-rc.2) I will revert the default settings of the filewatcher to pre 2.0.12 since it seemed to worked better for the majority of users. 2.0.12 has only just been released and is already producing bug reports connected to the change.

I will furthermore remove the 3 settings we introduced over at https://github.com/ransome1/sleek/issues/676.

Instead I will introduce 1 new setting named chokidarOptions. This new setting represents the chokidar options object as described here: https://github.com/paulmillr/chokidar?tab=readme-ov-file#persistence

Like this you will have all of Chokidar's options available and can adjust the filewatcher precisely to your environment. Since you might have already adapted to the 3 new options you will now need to apply your changes using the chokidar syntax. For example:

{ usePolling: false, interval: 100, atomic: true }

Chokidar has many more options, which can help figuring out a working setting for your particular environment.

ransome1 commented 3 months ago

@mdbdb @TriggerDingus before you start wrapping your head around all those Chokidar options, can I ask you to check out this pre-release and tell me if the issue still occurs? https://github.com/ransome1/sleek/releases/tag/v2.0.13-rc.2

If the config migration worked, it should regress to the behavior of sleek 2.0.11, where I understand you did not face these issues.

@aisbergde @RobLW @42web-ch you're invited to check the new option and let me know if this works for you.

TriggerDingus commented 3 months ago

@mdbdb @TriggerDingus before you start wrapping your head around all those Chokidar options, can I ask you to check out this pre-release and tell me if the issue still occurs? https://github.com/ransome1/sleek/releases/tag/v2.0.13-rc.2

If the config migration worked, it should regress to the behavior of sleek 2.0.11, where I understand you did not face these issues.

@aisbergde @RobLW @42web-ch you're invited to check the new option and let me know if this works for you.

I completed several tasks with the AppImage and no issues so far. I'll keep using it this afternoon and report if it happens again.

GaloisGecko commented 3 months ago

I have the exact same issue. I tried it with a file that is not synced to any other storage. But I observed that the issue occurs if and only if the task is recurring: If I complete the following task

2024-03-27 test  rec:+1d due:2024-03-27

the UI will show no tasks any more, but if I complete

2024-03-27 test due:2024-03-27

all remaining open tasks will stay on the UI as desired. Maybe it helps to narrow down the issue.

ransome1 commented 3 months ago

@GaloisGecko

the UI will show no tasks any more, but if I complete

What exactly does the UI show?

And how do your filter settings look like in the drawer?

GaloisGecko commented 3 months ago

This is the UI including filter settings before I complete the recurring task:

Before

And after I complete the recurring task, it looks like this:

After

If the task would not be recurring, it would vanish, but the other task would remain on the UI.

ransome1 commented 3 months ago

Is this the latest pre-release (2.0.13-rc.2) or 2.0.12? If it is the latter, does the same happen with the pre-release as well? There is an AppImage in that release for a quick glance.

GaloisGecko commented 3 months ago

I am still on 2.0.12, sorry for that. Update: Now I checked with the AppImage for 2.0.13-rc.2 and it works fine! The tasks do not vanish any more!

mdbdb commented 3 months ago

@mdbdb @TriggerDingus before you start wrapping your head around all those Chokidar options, can I ask you to check out this pre-release and tell me if the issue still occurs? https://github.com/ransome1/sleek/releases/tag/v2.0.13-rc.2

If the config migration worked, it should regress to the behavior of sleek 2.0.11, where I understand you did not face these issues.

@aisbergde @RobLW @42web-ch you're invited to check the new option and let me know if this works for you.

I just marked some of my tasks as done with version 2.0.13-rc.2 under the same conditions as before (todo.txt is synchronized via Syncthing).

➡️ The error no longer occurs!

ransome1 commented 3 months ago

@mdbdb has been released with 2.0.13. If it occurs again, check back in here. We now have several ways to adjust to your environment with these settings.

42web-ch commented 2 months ago

@ransome1 Hi, thanks for the update. I am switched from debian to arch on my work pc. All works fine on the new setup!

RobLW commented 2 months ago

Apologies I've been neglecting the app recently so not noticed changes/issues.

I've just updated Fedora from 39 to 40. The issue took place then. When I opened the app and laid my mouse over the tabs, I noticed that it was referring to a location that I think was for temporary files.(sorry I forgot to make actual note or screenshot).

Thinking about it now, I'm wondering does the app use a temporary file while open, and occasionally writes this back to the actual todo files?. If this is the case then when we reboot without closing down the app (which is always the case for me) the system will wipe the temp files and the app loads again expecting to find those files rather than loading the todo files in my home dir.? Just a thought.

EDIT: ah just run it from the command line and noticed it does: Watching new file: /run/user/1000/doc/4f9257d5/todo_2024_02.txt Which I guess is the temp file I'm talking about above.

I'm using 2.0.13 flatpak.

On a side note I also saw this error when starting, even though the file is there with setuid on it. [2:0425/122434.527260:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory