Profile list in the main window are not kept sorted when adding/renaming entries

[Parnassius]

Description

Creating a new profile adds the new profile at the bottom of the list in the main window. Similarly, editing an existing profile doesn't change its position in the list. I think that in both cases the list should be kept sorted. Restarting Vorta correctly updates the positions of the profiles to be sorted alphabetically.

This was recently noticed during the review of https://github.com/borgbase/vorta/pull/1899#issuecomment-2029914025

Steps to reproduce the behavior:

1. Create a new profile using the menu in the main window
2. The profile is added last on the list, even if it should sort before other entries

Alternatively:

1. Rename an already existing profile
2. Its position in the list doesn't change, even if the new alphabetical ordering is no longer valid

Environment

• OS: Linux
• Vorta version: latest commit (9b8dbcecfbab7e7492e05f5e0ae22a2631335718)
• Installed from: pip
• Borg version: N/A

I see two possible solutions for this:

1. Add some additional handling in the profile_add_edit_result function to keep the list sorted. This is a quick commit that does that: https://github.com/Parnassius/vorta/commit/59661f937b25670e0bb40362a696693aa01bbf90

2. Use the sortItems method of QListWidget to sort the list after every update, thus removing the need to use the order_by sql method.

The two solutions cannot co-exist since the sql ordering is case-insensitive while QListWidget.sortItems is case-sensitive. In the second case additional care should be taken to ensure the use of sortItems doesn't break anything. From a quick glance I think the way current_profile is set during the initialization of the main window should be updated, and maybe some additional changes are needed as well. https://github.com/borgbase/vorta/blob/9b8dbcecfbab7e7492e05f5e0ae22a2631335718/src/vorta/views/main_window.py#L66-L68

What do you think? Let me know if I should create a small pull request with the commit linked above or if a solution based on option 2 should be preferred

[m3nu]

Yeah, we can make this change. Thanks for even considering a solution.

Regarding the 2 options: Choose the one that's easier to understand later and adds less code to the project.

[Parnassius]

Sure, in that case I've created #1986 with option 1