On 6/4/20 5:00 AM, Jonathan Purol wrote:
I understand your problem. I've not been in your situation, but how about
- Change server to emit before and after events, plus a cancel event.
- Upon receiving a before event, call beginInsertRows,
- Upon receiving an after event, call endInsertRows,
> I understand your problem. I've not been in your situation, but how about
>
> - Change server to emit before and after events, plus a cancel event.
>
> - Upon receiving a before event, call beginInsertRows,
>
> - Upon receiving an after event, call endInsertRows,
>
> - Upon receiving a cancel
Den tors 4 juni 2020 kl 09:00 skrev Elvis Stansvik :
>
> Den ons 3 juni 2020 10:38Jonathan Purol skrev:
>>
>> Hello everyone,
>>
>> I've been in a bit of a tough spot recently with `QAbstractItemModel`.
>> I'll try to delineate my situation, then my problem, and then the
>> potential solutions and
Den ons 3 juni 2020 10:38Jonathan Purol skrev:
> Hello everyone,
>
> I've been in a bit of a tough spot recently with `QAbstractItemModel`.
> I'll try to delineate my situation, then my problem, and then the
> potential solutions and why I think they're all inferior to what I wish
> to have.
>
>
> So, is the issue that the client might attempt to modify some data which
> is already old (because there is some change coming from the server to
> the UI, which hasn’t reached the UI yet)?
>
> In that case I’d use optimistic locking, i.e. assign a version number to
> the data. Upon each data c
On 3 June 2020 at 12:52:01, Jonathan Purol (cont...@folling.de) wrote:
> why not cache the bulk changes received from server, and only after
> observing a complete set of changes you begin updating the Qt model?
> i.e. you should first receive a complete bulk of changes from server
> like <“before
> why not cache the bulk changes received from server, and only after
> observing a complete set of changes you begin updating the Qt model?
> i.e. you should first receive a complete bulk of changes from server
> like <“before”, “change item i1”, “change item i2”, …, “after”> and only
> at that po
On 3 June 2020 at 10:38:30, Jonathan Purol (cont...@folling.de) wrote:
Now you might say "why not just have the server emit both a "before" and
a "after" change event for whatever happens.
Yeah, I would love to do that - but with Qt's current setup it just
isn't possible.
What Qt is missing is an
Hello everyone,
I've been in a bit of a tough spot recently with `QAbstractItemModel`.
I'll try to delineate my situation, then my problem, and then the
potential solutions and why I think they're all inferior to what I wish
to have.
We have a desktop applications using QtWidgets, however instead
