Polishing and fixing existing code

As GSoC is inevitably going to the end I started polishing and fixing existing code. Not all points of my initial plan was achieved but the aim for these last days is to prepare code so it can be extended to a full multi-account support in future.

Keeping roster items expanded

After implementing roster proxy model to serve multiple RosterModels I had to update RosterGroupExpandinessPersister class (that keeps given items expanded, also after Swift restart) to manage AccountRosterItems too.

Collapsed groups were stored in string list as a setting. I have implemented CollapsedRosterItemsSet where information about each account and its groups state is stored. We can get info whether item is expanded/collapsed with convenience methods. RosterGroupExpandinessPersister now uses this new set instead of string list. CollapsedRosterItemsSet is serializable so it's easy to load/save it.

Roster model proxy

It's time for roster. We want to show multiple accounts in one window. Hence we decided to make every active account being a top level element of roster and thereby downgrade group elements.

I have implemented proxy model that makes use of current RosterModel. It contains collection of <RosterModel, Account> pairs. For now, we can show one account contacts but code is more prepared to jump into multiple view.

Account serialization

We wanted profile settings to be stored using boost::serialization. It's done now for Account class (including ClientOptions serialization and other) that remember profile details. Saving and loading objects is realized in AccountsManager.

Previously, account details were stored using ProfileSettingsProvider. Now, for backward compatibility reason, they're stored in both settings provider and serialized string. When no serialization string is detected in settings, Swift obtain details using current settings provider and stores them serialized also.

Places in code using settings provider were replaced to make use of Account serialization. In future, we are probably going to avoid using ProfileSettingsProvider at all.

Login window GUI

New login window GUI is implemented. At a glance, we can see the same, single account window but there's "Use multiple accounts" link that moves a user to a list of accounts.

Every account has its name, color and login details. We can change connection options by clicking at cogwheel. There's also certificate button next to password input (as in single account view). Remove account with red cross.

Final aim is to login to each account by enabling it (checkbox next to status egg). This way we can easily choose accounts that are also automatically logged in at startup.

In this phase we can log in using only one account as roster GUI is going to be implemented. Enabling given account by ticking its checkbox effects going to roster when connected correctly.

SettingConstants::MULTIACCOUNT_ENABLED option determines wheter to use this new, experimental feature (default: false).

Account and AccountsManager classes

I have extracted some global-specific object instances out of MainController class. This way I started preparing MainController to be created for every account (we need to have multiple MainControllers and one Swift window).

We have now an Account and AccountsManager classes that control MainController instances (Account is passed for every MainController). Profile settings are loaded using current implementation of ProfileSettingsProvider and new options are set to default when loading a profile that has been created previously (backward compatibility). We can still log in into one account only but the aim was to prepare an appropriate design for multiple sessions.

I will test it more to find out potential problems and then it's time for login window GUI.

Coding started - plan for the summer

Coding started this week. This is my sketch of a plan for multi account support project:

25 May

* weeks 1-2: Extract some global-type things out of MainController so they're not initialized with every account. Change interfaces/implementation of single-account oriented classes to prepare them to multi-account use (partially).

* weeks 3-5: Accounts list in login window. Ability to change colour of account, name, connection options, select default, write and remember password. Logging in into one account from list enabled – one instance of MainController.

26 June: Mid-term

* week 6: Expandable list in roster header but changing accounts inactive. Accounts colour bar in roster.

* week 7-9: Logging in to multiple accounts (many complications expected).

* week 10-11: Edit profile, add contact, enter room, start chat, run server command – able to select account before an action. Changing status for every account at once. 

* week 12: Chat window account identifying convenience implemented. Searching contacts.

17 August: Suggested “pencils down”

* week 13: Last adjustments.

28 August: The end