user interface - Is it possible to re-paint/update content in a Qt GUI application although the main thread is blocked? -

there lot of discussion (e.g. here) going on spinning or moving busy indicators in gui not find single 1 states impossible re-paint/update content in gui application while main thread blocked.

this question general 1 , not directly related qt gui applications.

when main thread of gui performing blocking operation no events processed , no content can re-painted. there 2 "recommended" approaches:

1. using worker threads
2. splitting work in chunks , updating ui "just not often"

the problem there operations cannot moved worker threads or other asynchronous mechanism. best example serialization , de-serialization of ui itself. in both scenarios user must not click happily in ui , change settings while settings, properties, etc. taken widgets (during saving) or applied widgets (during loading). true threading approach splitting chunks. edit: example application of stylesheets complete gui. imagine user wants select "dark" scheme. of widgets need updated , visible ones needs re-painted. during step event loop cannot run. similar discussion can found here.

in case i'm working on embedded device there approach:

3. directly overwriting specific region of framebuffer

this approach feels ugly , comes lot of problematic scenarios , surly involves lots of debugging.

the last sad approach:

4. do not use moving/updating content @ , show static such "...in progress..."

well, sad...

do agree on these observations? know of different approach or concept in general un-related qt?

the problem there operations cannot moved worker threads or other asynchronous mechanism.

i can't agree. these operations should split blocking , non-blocking operations. blocks should handled asynchronously, or, if no non-blocking apis available, handed off worker thread.

the best example serialization , de-serialization of ui itself.

i find particularly poor example because i've yet run need blocking gui, , serialization doesn't call it.

in both scenarios user must not click happily in ui , change settings while settings, properties, etc. saved or loaded.

construction , destruction of widgets should quick, if that's mean "deserializing" ui. recall blocking i/o , long parsing has been done in thread. qt widgets quick set up, , not necessary evil have no choice live with. if have own widgets blocking operations disk or registry access in constructors or event handlers (plenty of such "code" exists), fix them.

if you're merely talking setting widget values, again super-quick , can done in 1 batch. need viewmodel asynchronously interface between view (widgets, qml view, or qabstractitemview) , data source.

disk i/o , parsing/output of on-disk representation belongs in separate worker. once create internal representation, can passed gui thread build widget tree or populate interface.

you should implement thread-safe models using qabstractitemmodel or similar interface, , populate them in worker thread, , let gui thread react updates in real time.

if wish indicate user part of interface not usable yet, e.g. while model gets populated, via overlay, making sure temporarily disable focus on widgets under overlay. not hard , i'd find amusing if entire question reduced "how make part of ui inaccessible while it's being modified".

the key thing missing ui should handle asynchronously reacting model changing state. care, take hour load data needed populate model. doesn't mean application should unresponsive. make parts of ui can't interacted inaccessible interaction. ensure other parts of application need configuration data either inaccessible or in partially usable state asynchronously revert full state once configuration becomes available.