nightlies or weeklies (keep open for new releases in the comments)

[Elv13]

To track the changes planned for the next build. The changes are mostly based on the reported issues and their under-the-hood impact.

Nightly builds will be provided as comments in this issue

[ starbucks changes ]

• Test better on weaker hardware [DONE]
• Port the bookmark and history panels to QML
  • Add QML support to the bookmark API [DONE]
  • Add a timeline filter only showing bookmarked elements [DONE]
  • Create a QML bookmark panel [DONE]
  • Make the search overlay global
  • Refactor the timeline list into a template
  • Add bookmarks and contacts filter to the completionmodel
  • Add the "bookmarks by name" list [DONE]
  • Enable searching in the addressbook and bookmarks [POSTPONED]
• Reorder the dock tabs [DONE]
• Begin porting the account subsystem to QML
  • Fix the account and account model QML bindings [DONE]
  • Add QML bindings for the account status and error subsystem [DONE]
  • Add the current account to the sidebar
  • Create a QML/Kirigami widget to access the account status logs
  • Add the account list to the Kirigami global drawer [DONE]
• Enable the systray again (lost when Kirigami became the default TK)
• Fix typos [DONE]

[ KDEreview changes ]

• Remove of the remaining QtCreator tr() calls

[ Uri changes ]

• Make the dock icons smaller

[ infrastructure changes ]

• add the icons to the appimage (was done only for alpha1)
• Port the NightlyBot to create AppImages instead of .deb
• add an integration test for the Ring account creation [DONE-ish]
• run the clazy builder on each commits again [DONE]
• add a new debug appimage with no hardening and unstripped [DONE]

[Elv13]

https://drive.google.com/open?id=1XlDiZ3Pa588tigP410I30sKe-EYpJ6eq

[Elv13]

Beta 1 is not done yet, this issue will be for nightly links going forward

[Elv13]

Apparently google drive keeps the same link, but this is todays nightly https://drive.google.com/open?id=1XlDiZ3Pa588tigP410I30sKe-EYpJ6eq

I will try to find a better hosting. GitHub don't allow nighties unless you pay for extra space.

[star-buck]

@Elv13 : any update on the nightlies?

[Elv13]

tl;rd: I need some time to make deep changes to deemphasizing SIP and improve WhatsApp like workflow. I was hoping I could avoid them, but as the issue you reported show, they have to be done.

Historical background

For the last 75 years, this has been done exectly the same way. Everybody, including Apple/Google/Skype have the same separation of conceptual concerns.

A phone book contains some volatile data and meta data to reach someone. An address book contains data the owner associate with a person.

A phone book data is "owned" by its operator while the address book data is owned by it user.

If someone gets married and decides to change his/her family name as it is usual on some countries, then the phone book manager will make the change and the address book manager likely wont.

This is why not everybody "deserve" to be in the address book. Managing address book entries it harder than consuming phone book entries. The former is prone to merge conflicts and user interventions while the later does not.

Terminology

ContactMethod: phone book entry + statistics (usually a registered username and a Ring-ID)

• It has some names (registered Ring name or phone display names (CallerID)

Person: Addressbook entry (usually a vcard)

• A person has a list of ContactMethod (phone numbers)
• A person has random contact attributes as defined in IETF RFC6350

What does it have to do with the open Ring-KDE issues?

Most open issues are actually the consequences of the same limitation rather than individual oversights:

• The interface often displays ContactMethod and silently convert them to person only when manually changed.
• The Person template is hardcoded for SIP phones connected to LDAP systems

The consequences of that are the bugs:

• There is useless fields hardcoded in the GUI instead of relevant and flexible ones
• The phone number list is empty when it is a contact method
• The profile edition is unreliable
• The GUI "history" tab is very limited, incomplete and inflexible compared to the timeline while in theory lenses on top of the same data (but in practice is not due to one being for Person list of ContactMethod and other other on a single ContactMethod)
• There is a lot of SIP related concepts leaking on the GUI due to protocol and database design limitations

How do you fix it

The "database" of:

ContentMethod/Person/Account/Call/(Text|Audio)Recordings/Certificate

have not changed in many years and it's cardinalities mapped perfectly the phone use cases. However it does not map all that well to WhatsApp/Skype for dummies.

The main problem is that silent "upgrade" from ContactMethod to Person that magically enable new capabilities. It's impractical to just upgrade everything to Person by default. This will create an unlimited number of synchronization bugs we really, really don't want to deal with. The number of Person must be kept to an absolute minimum. However, the capabilities of the Person object must be available all the time to keep the GUI consistent. That set of capabilities must also be flexible and not hardcoded to the SIP use case.

The new database concepts

ContactTemplate: A set of properties to be displayed in the GUI. It is independant from the actual spec / protocol and is designed for offering user facing profile / contact editors. That template is responsible to silently map things so the GUI and protocol don't interfer with each other.

Individual: Split Person in half. All user facing capabilities get moved there so the user interface has a standard object to display instead of a mix of ContactMethod and Person depending on the context. This will fix the occasional inconsistencies. The Individual inherit all the responsibilities related to managing it's contact methods while the Person only keep the burden of storing the fields recommended by its ContactTemplate.

• The Individual: is the new owner of its timeline
• Manage all things related to the different way or reaching him/her/it

The "problem" is that such changes are low level and affect just about everything. It's not the end of the world, only 3-4 days of work, but it will allow the flexibility required to simplify the workflow by deemphasizing the protocol related quirks. So far I just ignored the consequences of not doing that, but as you reported the issues, it's obviously not a good idea to keep the head in the sand any longer.

I am 2 days in, it compiles with all the changes, but there is still changes and some severe regressions to fix.

[star-buck]

any nightly to test? nightlies or at least WEEKLIES should be done regardless if all things work or not.

[Elv13]

Yes, only 1 day was skipped due to some network issue. The current one was uploaded a couple hours ago. It has a nasty issue where sometime the timeline does not show up when the application is loaded and you have to click on another contact to fix it. Beside that it works. Only missing from the open issues are the search changes and history changes. Both are in branches and not ready for testing.

There is also the bug with the video on some systems, I started bisecting all dependencies yesterday. The bot makes about 4 builds per hours so it's gonna take another couple days before I find the culprit. There is ~200 indirect dependencies. It doesn't seem to be ffmpeg or an obvious one. Maybe it's a combination of multiple things. In any case, the script is going to find it eventually. If I tell it to build the January 20 nightly, it works.