E.g. when the user triggers the Add button by keyboard focus or mouse,
the button has focus when it gets disabled in the addItem() handler.
Which results in the focus being passed on, to whatever next widget
in the tab focus order(?) which can get focus. Inside KEditListWidget
these are only the other buttons, which are usually disabled when an
item is added, so the focus is moved out of the KEditListWidget.
Which usually makes no sense, as the user may want to do more actions
on the list, until explicitly leaving the scene.
Same for Remove button, which on removing the last item before also
dropped the focus to the outside.
There is some flawed logic in updateButtonState() WRT up/down button
enabling compared to enableMoveButtons(), but to fix/improve this
is left to another patch/person.

Usages of KListEditWidget in KDevelop's "New from Template..." dialog,
e.g. in the test cases of class data pages, no longer are frustrating,
as no longer will the focus move to the "Back" dialog button after
clicking "Add" or when removing the last item by the "Remove" button.