chatmail
webxdc update events
I don't really like the event approach, how about adding it as a property of webxdc info and reusing the message changed event, or just adding one new event indicating the value was updated?
why don't you like it though?
there can be many events with this approach, also I'm not quite sure of the usecase, if its only for an icon then a getter + an update event with the messageid would be better and easier to deal with. (less to implement, and with the event triggers getter pattern there is neither outdated data, nor no data if the message was loaded/displayed between the events. an thus doesn't have any state until the next event comes in)
Should I still create one more event like WebxdcLoadingStateChanged or should I reuse MsgChanged? @r10s @Simon-Laux
for dc_get_updating_webxdc() - what is the usecase for the ui wanting an array of all webxdc that need updates?
intuitively, i'd say sth. that returns the update state for a given message is much more handy and probably what is needed by UI - of course, UI can search the array, but in general our ffi is always driven by direct UI needs :)
but maybe i also have overseen a usecase :)
we can also do an av about that tomorrow.
Yeah I also thought about that but I decided that since sorting has to be done either way (frontend or backend) it can also be done in the frontend leaving a more flexible ffi interface. But if our design guideline is focused on alignment with frontend needs I can obviously change the functions signature
@r10s does your thumbs up mean that you understand my reasoning or do you want me to change it?
both - i understand the reasoning but would still prefer a more UI-friendly function signature :)
What is better for the UI? A new event which notifies that update-state has changed or reuse of the MsgChanged Event? @Simon-Laux @r10s @Hocuri
I'd vote for new event, though I also can see points for reusing the msgs_changed event, but then callbacks that are not needed might be called too, so I think a dedicated event is better.
I'd vote for new event, though I also can see points for reusing the msgs_changed event, but then callbacks that are not needed might be called too, so I think a dedicated event is better.
yeah same
thanks a lot, for pushing that forward!
for general reasons, i'd wait until 1.34 is released. ui won't adapt to this pr sooner anyway - and this avoids unforeseeable side effects (for such reasons i am not a fan of automerge, btw)
EDIT: some quick comments: changelog entry is outdated. is is_sending and is_sent seem to be the same, so only use one wording, if "is updating" is also the same, maybe just go for that.
also wondering if there is any real benefit in having "is updating" as event-parameter (i am just wondering, i do not suggest to change that part right now :)
As I recall holger wanted to reduce open prs, so is this mergebal now @r10s. You wanted to wait for 1.34, is it out?
I thought it would be nice to have an event that notifies the ui when the webxdc update state changes because otherwise you would have to bussily check for when all updates are sent out. You could do that every second or so which would not produce such a high load but it seems more accurate with an event. @r10s
Edit: Sorry, I misred your comment. You just want to remove the is_sending flag and not the whole event. We can of course do that but having this information in the event can spare us some sql-queries in some scenarios which is why I added it in the first place. If we don't care about that the second approach might be a bit cleaner.
@r10s, I would like to finnally finish this PR. Are you also willing to push this forward? Because then I would do a rebase and look over it again