optimisations

rovr uses textual, which uses python, which is known for how terrible a performance it gives.
hence, rovr makes use of a couple optimisations to make it perform reasonably well

queue of length 1

used in MetadataContainer and PreviewContainer

flowchart TD
    a(receive external thread request) --> b{check for active thread}
    b --> |no thread| c[run thread]
    b --> |thread running| d{queue thread}
    d --> |no threads in queue| e[set thread in queue]
    d --> |thread in queue| f[overwrite thread in queue]
    c --> |thread end| h{check for queue}
    h --> |thread in queue| j[get thread from queue]
    j --> i[clear queue]
    j --> |use thread| c
    h --> |no thread in queue|s
    i --> s(stop)

this diagram roughly shows how the mechanism works, with the main thing being an intentional debouncer.

• having a normal queue means that it would take a while for each item in the queue to be run, hence a very noticeable lag.
• however, by having a queue of length 1, and overwriting the queue, it means that the latest added item is considered, and anything in between is ignored, greatly improving performance

debounced updates

used in MetadataContainer and ProcessBarContainer

flowchart TD
    a(start heavy process) --> c{do heavy process}
    c --> |process completed|h[force label update]
    h --> s(stop)
    c --> |process running|d{0.25s + previous_updated_time < current_time?}
    d --> |true|e[update label]
    e --> c
    d --> |false|f[skip updating label]
    f --> c

this diagram shows how it works

• when doing heavy tasks, like calculating folder size, or deleting folders, the appropriate widgets’ labels are update spammed.
• by using a ‘debouncer’, more time is spent on actually doing the process, than to update the progress of the process

I am certainly not the first person to have discovered this, but it is such a nice mechanism to have