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

increasing the recurrence value beyond 9 makes the unit specifier disappear #665

Closed bughunter2 closed 3 months ago

bughunter2 commented 4 months ago

App Version: 2.0.9

Platform: Linux

Installation Method: Direct Download (AppImage)

Expected Behavior: Expect to be able to use any recurrence value like 5 or 10 or 999 whilst retaining the chosen/existing unit specifier.

Actual Behavior: When either manually editing the recurrence value to '10d' (or '10m'), or when doing this via the UI with the up arrow button, you can see the unit specifier ('d' or 'm', etc) disappear in the todo item text as well as in the little recurrence UI widget. Values like '1d' or '9d' work fine, but values beyond 9 like '10d' seem to be problematic.

Steps to Reproduce:

  1. Open the app.
  2. Click on a todo item to edit it.
  3. First set the recurrence value to 5d and save the todo item. No problem.
  4. Edit the item again and use the recurrence UI widget's up arrow button to increase the value to 10d, and notice it transforming from '10d' to '10'. At this point you can see that the recurrence value in the todo item text has also changed in the same way (the unit specifier 'd' is gone).

Screenshots: Left blank.

ransome1 commented 4 months ago

@bughunter2 can you please check if this issue is resolved in the latest pre-release: https://github.com/ransome1/sleek/releases/tag/v2.0.12-rc.3

I can also need some testing of a new feature, which is discussed over at https://github.com/ransome1/sleek/issues/609.

Feel free to participate, if you have the time to do so.

bughunter2 commented 4 months ago

The problem seems to be partially solved:

On real hardware, I don't notice any problem with v2.0.12-rc.3 but I do with v2.0.9

In a virtual machine however, the problem is still there: once you increment beyond 9, the value keeps switching back/forth in the GUI. No graphical artifacts though, just a glitching UI element (you see the text in the todo item glitch as well, constantly switching). When you finally click Update it will choose a value at random from the range of values that you've been using by pressing the up/down arrows.

About testing, sure. I'll see what I can do.

ransome1 commented 4 months ago

On real hardware, I don't notice any problem with v2.0.12-rc.3 but I do with v2.0.9

In a virtual machine however, the problem is still there: once you increment beyond 9, the value keeps switching back/forth in the GUI. No graphical artifacts though, just a glitching UI element (you see the text in the todo item glitch as well, constantly switching). When you finally click Update it will choose a value at random from the range of values that you've been using by pressing the up/down arrows.

The text confuses me a bit. Are you using 2.0.9 or 2.0.12-rc.3 in that virtual machine?

bughunter2 commented 4 months ago

On real hardware, I don't notice any problem with v2.0.12-rc.3 but I do with v2.0.9 In a virtual machine however, the problem is still there: once you increment beyond 9, the value keeps switching back/forth in the GUI. No graphical artifacts though, just a glitching UI element (you see the text in the todo item glitch as well, constantly switching). When you finally click Update it will choose a value at random from the range of values that you've been using by pressing the up/down arrows.

The text confuses me a bit. Are you using 2.0.9 or 2.0.12-rc.3 in that virtual machine?

Oh I'm sorry. To clarify: that was with v2.0.12-rc.3 as well.

Edit: The VM is a Debian 12 system without virtual hardware acceleration. The system doesn't have any problem in other applications like browsers.

bughunter2 commented 3 months ago

Maybe found a new symptom. If we trigger this issue, and then close the todo editor widget by pressing Cancel, and then open it again by hitting the + (new) button, a leftover is visible: the new todo item widget contains a text like 'rec:4d' or 'rec:3d' (can be any number) rather than an empty line. This was with v2.0.12-rc.4