search

banji-project / ring-issues

Old issues before it was moved to kde.org
0 stars 0 forks source link

ring-id "phone number" is sometimes shown, sometimes not, even though the system knows it #39

Open star-buck opened 6 years ago

star-buck commented 6 years ago

here one can see that the number of ronaldpb is known at the side, but not at bottom: screenshot_20180220_173741

for the other contact it is shown both times fine: screenshot_20180220_174226

Elv13 commented 6 years ago

What's your expected behavior here? The big hash is quite unless and scary for the regular user and the registered username is already displayed in the header.

Currently, it is "randomly" shown dependending on the existence of a vCard. That's obviously a bug/oversight one way or another.

If I had to choose, I think I would always hide it. It provides little value when there is only one. On the other hand, if the contact has multiple RingID (one for home and one for mobile?), then it might be worth showing them.

star-buck commented 6 years ago

Lets always show the ring ids there, even if only 1.

Elv13 commented 6 years ago

"done" (I think)

hopefully always there, maybe there is still a couple corner case. In any case, the new under the hood changes took care of 90% of the case where it used to be broken.

star-buck commented 6 years ago

it is still completely broken. It changes randomly, splits users into "unkwnown" and real ring-kde ident-name, sometimes with or without the number, so this results in up to 3 contact entries for the same user... where then the chat is split on one contact-entry, the call info on another, etc... This is creating a chaotic experience with ring-kde, so it needs to be solved the most urgent.

Elv13 commented 6 years ago

Don't worry, I have been hard at work on these for a month. In retrospective it was probably madness and I should have whack-a-moled all the instances of these bugs instead of fixing the legacy design decisions that cause them. However the (very boring and invisible) work I am currently finishing could not have been delayed much further as upstream changes would have forced them anyway. The bad news it that it's been a month. The very good news are that some very nice features are now closer to being enabled:

None of that is yet visible in the GUI and I don't plan of spending time making them visible unless/until you ask for them (and hopefully after 3.0 because it's long overdue). I could go on and explain all the small details like I did for the first phase, but that would be a very long and boring read about distributed systems and standard protocols. The short version is that the old timeline was completed in very a very short time because the (summer 2017) contract was expiring and was stacked on top of a phone design instead of integrated deeper. It worked, but was redundant with other features like the history and kept regressing and exposing bugs like this because it was essentially an hack made to get a working version out of the door faster. It worked fine enough until you asked me to move the chat tab to be the first one displayed because it was made visible and loaded long after all the data was processed, but now triggers even more race conditions and had to be done properly (aka rewritten). The new design is future proof, unit testable and better suited for a Skype like multimedia app rather than a phone.

edit: added multi-party chat in the newly possible feature list, it's the most important one...