[Gammaray-interest] Getting rid of "Loading..." on client side models

[Christian Gagneraud]

On Thu, 6 Jun 2019 at 01:54, Christian Gagneraud <chgans at gmail.com> wrote:
>
> Hi there,
>
> When programmatically using remote models to build my graphs, i have
> to deal with a very annoying "feature": the lazy loading.
>
> The problem is that i need to filter out these cases as a node in a
> graph is uniquely identified by its object ID, and this object ID is 0
> when the item/row is in the "Loading.." state, which breaks
> "everything" (I need all my data sources to be complete, fully
> resolved, synchronised and ordered).
> So far i'm unable to "stream" the graph data (changes). I need to
> rebuild it continuously, which is rather inefficient.
>
> Is there a mechanism to be notified of a loading -> loaded transition?
>
> Let's dream for a moment: Wouldn't it be nice to have deferred
> notification of  item/row/column/... inserted/removed/changed, instead
> of asynchronous content?

B/c i don't have connect notify, my approach so far was to
incrementally build the list of connected objects by using a sample
timer, and scanning all (pre-filtered) objects [1].
This sort of worked, but i realised that model and remote object
signals are received on the client side out-of order.
For example at sample time, server side,  the code update the
connection list, and then emit a "sampling done" signal.
On the client side, remote model changes are tracked by setting a
simple "need sync" flag, and then when the "sampling done"
notification is received, the sync is applied if needed.
This have gave me a lot of head-ache, as it turns out that the model
signals can be delayed-emitted after the "sampling done" signal.
It looks to me that there's some "aggregation" process going on
somewhere, i don't know if it's from GammaRay or Qt.
But what i've notived, is that if i reset a model a then insert rows,
and then emit the "done" signal. The server will receive, the reset
signal, then the "done" signal and then the aggregated "rows inserted"
signal.
This whole process is done with the object lock on, as it has to be an
instantaneous snapshot.

Maybe i should create a PR with my server side code, so that you can
have a better picture of what i'm trying to do.

Chris.

[1] The original idea was to store sender/receiver objectid/threadid,
plus number of connections, but it turns out that it is impossible to
track connections this way, for example you cannot detect duplicated
connections w/o resetting the connection model before-hand.

>
> Thanks,
> Chris