August 2016 recap

Sat 03 September 2016 ru

2016-august-recap

This article explains the most important technical details about development in August: UIQt module, its refactoring, a new feature based development approach, and its benefits.

UIQt module is a collection of UI components backed by Qt. We only use it for Editor UI at the moment.

Here is a list of UIQt module components with their description and current code size:

№ Component Description Size (B) Size (%)
1 UIQtAction Actions (events) for menus 11224 9
2 UIQtAux Initializes Qt and main window. Provides widget resolution by name to other components 15518 12
3 UIQtDock Widget docks 5273 4
4 UIQtFileDialog File selection dialogs 8960 7
5 UIQtMenu Menus for main window and pop-ups (like node's add/copy/paste/delete menu) 4566 3
6 UIQtMenuBar Menu bar for main window 4222 3
7 UIQtRunner Allows to start QApplication 2450 2
8 UIQtThumbnailDialog Dialog with thumbnail images 18615 14
9 UIQtToolBar Tool bar for main window 4276 3
10 UIQtTree Provides complex widgets like Scene tree and Property browser 51216 39
11 UIQtWidget Common widget properties like focus and visibility 5465 4

UIQt module refactoring purpose was to replace old State API with new Environment API, which allows to achieve the same functionality with less code, i.e., makes development easier and faster.

Refactoring started in July and should have been done the same month. However, we only finished the work in August. Initial plan assumed 28 hours would be enough, but we spent 65 instead. We estimated planned time by relying on the number of public API calls of each component. That worked fine for small components, because the number of their public API calls was roughly equal to the number of their features, and features themselves were very small. However, it totally failed for UIQtTree, which contains 39% of UIQt module code, because there was no direct connection between public API and features.

Feature based development approach was born as a result of UIQtTree refactoring struggle. Since Qt uses MVC, UIQtTree component consists of several classes. By the time UIQtTree could display and manage a hierarchy of items, the component was already 27K in size. We noticed UIQtTree started to require abnormal amount of development time even for tiny features. This was an obvious quantitative complexity manifestation.

We decided to separate UIQtTree into base part and additional ones. Base would only contain minimal code required by all features. Addition would contain specific feature code and could be safely modified. In the case of UIQtTree, item hierarchy display and modification is the minimal functionality, while item renaming is an addition.

Here is a list of current UIQtTree features:

**№** **Feature** **Description** **Size (B)** **Size (%)**
1 Base Allows to construct item hierarchy, modify it, and display it 26966 52
2 Item open state Keeps track of collapsed/expanded item properties 3094 6
3 Item renaming Allows to rename an item 3471 7
4 Item selection Allows to get/set selected item 2338 5
5 Item value Provides 2nd and the rest columns for items, used by Property browser 1307 3
6 Item value editing Allows to edit item values with a default editor widget 1996 4
7 Item value editing with combobox Provides combobox editor 5819 11
8 Item value editing with spinner Provides spinbox editor 5290 10
9 Menu Provides pop-up menu 1248 2

Here's an example of UIQtTree Menu feature file: TREE_MENU.

Benefits of the approach include:

  1. Faster code reading/understanding due to small size
  2. Easier and safer modification due to isolated code

There's a drawback, too: new approach requires learning.

That's it for the most important technical details about development in August: UIQt module, its refactoring, a new feature based development approach, and its benefits.

Category: News