ui/keyboard: updateKeys() via signal first in constructor, deal with potential null value.

currentInputSource can be null prior to being initialized and the ibus engine is set.

_updateKeys() called by _setupKeyBoard() in the constructor can therefore crash the gnome shell if the on screen keyboard is enabled.

Setting the input source in the async activateInputSource() in InputSourceManager triggers the 'current-source-changed' signal at the correct time after awaiting the ibus-engine being set.

This triggers the signal 'group-changed' in keyboardController which is connected to the 'current-source-changed' signal.

This in turn will trigger _updateKeys() as onGroupChanged() is bound to the 'group-changed' signal in ui/keyboard constructor.

Therefore the keys will be initialized correctly at the correct time via the signals when the inputSource is set and initialized from its default null value.

There is therefore no need to call _updateKeys() through _setupKeyBoard() in the constructor as the initialization will happen correctly when the source is set.

This however assumes that we will connect to the signal before it is actually fired.

First, connect to the 'group-changed' signal from KeyboardController. Then check and see if _currentSource is set in KeyboardManger, if so call _updateKeys().

Once the source is set, _updateKeys() will be automatically called from the connected signal and the initialization will complete at the correct time.

Alternative Fix for #7912 (closed)