sliding sidebar: add account info

[star-buck]

add account info of user who is using this account somewhere in that sidebar (above or at bottom):

[Elv13]

[Elv13]

I am doing making most of the related classed QML firendly. There is a little Kirigami issue where the action handles y position currently depend on the item height. This causes them to be misaligned when the height isn't constant. I will submit a kirigami patch for and wait until the next framework release before applying the change to ring-kde to avoid a dependency on Kirigami2-git

The Kirigami actions on swipe are:

• Reload now
• Delete
• Share (dummy button, not ported to QML yet)
• View logs (currently being implemented)

To do:

• Add a "reload all" button next to the (+) button
• Remove the wizard entry at the top since it's now redundant with the (+)
• Add a status icon (as requested in #17 / IRC and by Uri) in the sidebar/dockbar
• Add some very evident visual cues when an account goes down

Edit (Thursday), more issues in need of attention:

• Fix the profile support, it seems to have some serious issues / regressions
• Make sure the presence support really works rather than look ok

Edit (Monday):

• Fix accounts own presence support [done]
• Port the presence status model to QML
• Add a QItemSelectionModel for accounts own presence
• Add a GUI for the presence
• Add an availableProfileModel [done]
• Make sure the account contacts always match their profile [done]
• Optimize the AccountModel to reduce the rows (inserted|removed) signals

[Elv13]

This was quite a rabbit hole and it's still is. To get the "spirit" of the issue, it pulled quite a lot of things. So the account in the sidebar is implemented and now is correctly updated when there is issues.

Then I went further and implemented the mockup part with the profile status in the dock bar so it becomes visually obvious when there is a problem. I knew the profile support was in bad shape, but this was beyond bad. 3 people implemented part of the stack and had 3 totally different understanding of the "correct behavior":

• One (and me) associated profiles with accounts. This is what the wizard does when it allows you to setup the details.
• One assumed there is always a single profile and always picked the first one
• The last way it was implemented is a "selected profile" regardless of accounts preferences

All 3 are defensible as "good ideas". However all 3 were assumed in different part of the code. The result was that a random profile was sent depending on how the person was reached. So private data could simply be uploaded randomly, including to strangers. That's fixed.

Then I went further and tried to fix the account presence so it could be controlled from the sidebar too (present, away, busy, etc). That's in spectacularly bad shape and the more I look at it, the more it seems the way the whole protocol extension has been designed is one giant leak of personal metadata. I will take another look tomorrow to make sure I didn't miss anything, but it doesn't even look like it's fixable at all while supporting existing GNU Ring users.

So the issue is mostly done, but I would still like to implement better problem mitigation so issues like #28 are easier to diagnose.

After that, unless you ask me to keep going, I will call this complete since otherwise it will take an undefined amount of time for a diminishing return on investment. The whole account subsystem is still using the old QtWidget dialogs and everything and I still plan to keep it that way for 3.0 and 3.1.

Changes since alpha3:

• There is a combobox to select the profile (per account)
• The multi profile support was restored and fixed
• The account list is correctly updated when there is issue
• The account status color was restored (it was lost when the old GUI was removed)
• The profile meta availability was implemented
• The ContactMethod availability was extended to better support it's own account availability
• The presence is now better forwarded between accounts, contacts and access points
• The Frankenstein selected profile override was removed (profile selection is possible, but in only one way, not 3 incompatible ones)
• The account can be enable, disabled, reloaded and deleted be swiping the account in the sidebar.
• The profile wizard and account dialog has been visually enhanced to look pretty and follow the newer mockup styling conventions
• The security status of the account is now correctly updated
• Some QML hash collisions have been fixed
• Some small account configuration issues were fixed along the way