Open Simon-Laux opened 1 week ago
AccountList
in the core, only struct Accounts
. So, i think AccountsChanged
and AccountsItemChanged
may be better.Do we need "account id" inside an event?
The event emitter that desktop uses is on the Account Manager, all events have an id field for the account id, afaik events that are emitted in the account manager have id=0.
So no we don't need it inside EventType
, because it is already "outside" in the Event
.
So, i think AccountsChanged and AccountsItemChanged may be better.
fair point, though when we add sorting you might say the order that could change makes it a list? anyways I don't really care much about specific naming in this case, so would just agree here, unless there are other better suggestions.
What?
Emit events from core when Account List items change, similar to how chatlist UI events (#4476) were added.
How?
account id = 0
-> already used to emit accounts from the account manager (todo reference?)account id = <id of account>
Update Cases for
AccountListItemChanged
:Basically when properties in the jsonrpc Account Object changes, so
config('selfavatar')
)config('displayname')
andconfig('addr')
)config("private_tag")
- not yet in account object, but should be added there soon (#6107)Why?
window.__updateAccountListSidebar
function pointer to update the account list sidebar ui when it changes, we want to remove that less than ideal workaround.Basically move the responsibility for notifying the ui of updates to the core, to reduce need for workarounds in UI. Yes in this case mostly desktop will benefit, but when android and iOS add proper tablet support/UI then they will benefit too. deltatouch also has a desktop/tablet ui mode where the account list is always shown.
Who will do it?
I'm willing to do this. The intention in making this issue instead of a private note is to get feedback early.
Why now?