Сб 03 сентября 2016 ru
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|
|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:
- Faster code reading/understanding due to small size
- 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.