Strange behavior of property in callback

[DaMilyutin]

Hi all,

I've compiled and ran cpp-template.
And I've changed it as follows to emulate async job.

appwindow.60

import { Button, VerticalBox } from "sixtyfps_widgets.60";

export AppWindow := Window {
    preferred-width: 400px;
    preferred-height: 600px;
    
    property<int> counter: 42;
    property<float> progress: -1.;
    callback request-increase-value();

    VerticalBox { 
        Text {
            text: "Counter: \{counter}";
        }
        Button {
            text: "Increase value";
            clicked => { 
                request-increase-value();
            }
        }
        Text {
            visible: progress >= 0.;
            text: "\{progress}";
        }
     }
}

main.cpp

#include "appwindow.h"

#include <future>
#include <iostream>

int main(int argc, char **argv)
{
    auto ui = AppWindow::create();

    auto do_job = [&ui]{
            ui->set_progress(0.f);
            for(int i = 1; i <= 100; ++i)
            {
                std::cout << "at i = " << i << std::endl; 
                // some data processing here (file reading, etc.)
                std::this_thread::sleep_for(std::chrono::milliseconds{100});
                ui->set_progress(float(i));
            }
        };

    ui->on_request_increase_value([&]{
        //std::async(do_job).get(); // this actually behaves same
        do_job();
        ui->set_counter(ui->get_counter() + 1);
        ui->set_progress(-1.);
    });
    
    ui->run();
    return 0;
}

I expect progress to change and text with progress percentage to appear in window but nothing happens.
Am I doing something wrong?

Moreover, close button is not responding when do_job is running, but I think this is expectable.
However, I'd like to have property or signal on ui close/stop/cancel. So I can cancel do_job.

[ogoffart]

You are not supposed to block the UI thread or the eventloop will not run. So you must do the processing operation in a different thread, and use sixtyfps::invoke_from_event_loop from the other thread to communicate back to the UI thread.
Example: (I did not test it so you might need to do some fixes)

int main(int argc, char **argv)
{
    auto ui = AppWindow::create();

    auto do_job = [&ui]{
            sixtyfps::invoke_from_event_loop([&ui] {
                ui->set_progress(0.f);
            });
            for(int i = 1; i <= 100; ++i)
            {
                std::cout << "at i = " << i << std::endl; 
                // some data processing here (file reading, etc.)
                std::this_thread::sleep_for(std::chrono::milliseconds{100});
                sixtyfps::invoke_from_event_loop([&ui, i] {
                    ui->set_progress(float(i));
                });
            }
        };

    ui->on_request_increase_value([&]{
        std::thread(do_job);
        ui->set_counter(ui->get_counter() + 1);
        ui->set_progress(-1.);
    });
    
    ui->run();
    return 0;
}

I hope this helps

[DaMilyutin]

I've managed to get it working. Changed some code in main

int main(int argc, char **argv)
{
    auto ui = AppWindow::create();

    auto do_job = [&ui]{
            sixtyfps::invoke_from_event_loop([ui] {
                ui->set_progress(0.f);
            });
            for(int i = 1; i <= 100; ++i)
            {
                std::cout << "at i = " << i << std::endl; 
                // some data processing here (file reading, etc.)
                std::this_thread::sleep_for(std::chrono::milliseconds{100});
                sixtyfps::invoke_from_event_loop([ui, i] {
                    ui->set_progress(float(i));
                });
            }

            sixtyfps::invoke_from_event_loop([ui] {
                ui->set_counter(ui->get_counter() + 1);
                ui->set_progress(-1.); 
            });
        };

    ui->on_request_increase_value([&]{
        std::thread(do_job).detach(); // <---- detach required!
        //std::thread(do_job).join(); // not working (effect as decribed above)
        //do_job(); // not working
    });
    
    ui->run();
    return 0;
}

Please clarify, how does property system work in sixtyfps?
I expected to set new value to property without any wrapping and do it freely in any thread.

[ogoffart]

The handle to the window is not thread safe and you can only use it in the UI thread.
To help, you can send event to the main thread using sixtyfps::invoke_from_event_loop and the lambda will be run in the event loop.
In the lambda you can set the properties, then the UI will be redrawn at the next iteration of the event loop.

[DaMilyutin]

Reasonable.

Seeing this pattern in code, I think about set_property_safe calling sixtyfps::invoke_from_event_loop with set_property under the hood. For less code with explicit callbacks.
Ex.

            for(int i = 1; i <= 100; ++i)
            {
                std::cout << "at i = " << i << std::endl; 
                // some data processing here (file reading, etc.)
                std::this_thread::sleep_for(std::chrono::milliseconds{100});
                ui->set_progress_safe(float(i)); // <--- 
            }

with impl in AppWindow something like

void AppWindow::set_progress_safe(float val)
{
        auto ui = this;  // for lambda capture
        sixtyfps::invoke_from_event_loop([ui, val] {
             ui->set_progress(val);
        });
}

However, I see that use case ui->set_counter(ui->get_counter() + 1); can't be turned to _safe call, since I read and then write.
so I have to block until both operations are done.

[ogoffart]

there is also a blocking_invoke_from_event_loop function that returns a value So you can do:

int counter = blocking_invoke_from_event_loop([ui] { return ui->get_counter(); });
counter = counter + 1;
invoke_from_event_loop([ui, counter] { ui->set_counter(counter); });

Adding these _safe getter and setter is not a bad idea. I'm a bit worried that it bloats the API a bit and it is still better to have everything within a invoke_from_event_loop scope because then we don't get intermediate state being shown.
But we should consider it.

[DaMilyutin]

To keep API smaller for user I'd make public properties but with extra functionalities on them.
I'd hide all read/write blocking operations under the hood of setter and getter.
And I'd add safe methods for case ui->set_counter(ui->get_counter() + 1);
void Property::safe(Functor f);
with call like
ui->counter.safe([c = ui->counter](){ c = c + 1; }); // if property has reference semantics
To my understandint property in C++API has reference semantics. It is reference to data stored in "AppWindow".

or for value semantics
ui->counter.safe([&c = ui->counter](){ c = c + 1; }); // capture reference

upd: probably better API is like with non-blocking calls
ui->counter.safe([&c = ui->counter](){ c.unsafe_set(c.unsafe_get() + 1); });

Cases for operator+=, operator-=, operator*= and similar can be also implemnted as for operator= without calling safe.

Another option is to provide changing functor like
ui->counter.update([](T const& old_val) -> T { return c + 1; });
With impl like:

void Property<T>::update(F f) 
{
       auto p = this;
        sixtyfps::invoke_from_event_loop([p, f] {  // blocking or not?
             auto new_val = f(p->unsafe_get());
             p->unsafe_set(new_val);
        });
} 

I've seen come generated code and properties are private members.

[DaMilyutin]

I'm afraid this code might shoot

int counter = blocking_invoke_from_event_loop([ui] { return ui->get_counter(); }); // ok
counter = counter + 1; // if there are multiple threads trying to deal with counter they can change while this operation is running
invoke_from_event_loop([ui, counter] { ui->set_counter(counter); });  // overwrite changes by other threads

I was playing with cpp-template.
I'm trying to implement somethging like this

In this case there can be no guaranty about counter.
Actually I have some difficulties there. I'd probably write some questions later.

[bjorn]

Maybe I missed something, but why not like this?

blocking_invoke_from_event_loop([ui] { ui->set_counter(ui->get_counter() + 1); });

[DaMilyutin]

Initially Oliver avdised me to use sixtyfps::invoke_from_event_loop. I'm not sure, how big difference is.
Maybe he'll give you better answer, what is better in this case?

Check the docs
https://sixtyfps.io/releases/0.1.4/docs/cpp/api/function_namespacesixtyfps_1a60bd318798158c03db499054d4586aa7.html
https://sixtyfps.io/releases/0.1.4/docs/cpp/api/function_namespacesixtyfps_1acfc4b71092d63a5fbd0cbc8471e4da52.html

[ogoffart]

I mean, the question is if the example the " + 1" is meant to be running in the thread or not.

// +1 is cheap and run in the UI thread:  then no need to block
invoke_from_event_loop([ui] { ui->set_counter(ui->get_counter() + 1); });

// we want to run the +1 in the worker thread, but yes, we assume that we are the only worker thread going to change the data
int counter = blocking_invoke_from_event_loop([ui] { return ui->get_counter(); }); 
counter = counter + 1; 
invoke_from_event_loop([ui, counter] { ui->set_counter(counter); });  // assume that no other threads where changing the counter, or that it is fine to overwrite