This series of article will dive into some technical thinking, concepts, issues and solutions to understand the kind of work involved in the development of AOS Designer. This first article also gives some information on the current work going on and what to expect in the coming months.
As explained in the last progress report, there is a big work going on to re-architecture and re-design a little how AOS Designer works (or will work) and how it will look. I designed AOS Designer with strong constrains in mind which are necessary to solve the problems at hand but makes features slower to develop (by one person). Additionally, because of technical issues I under-evaluated in the previous years, I had to take the time to fix them before being able to accelerate the development of this tool and get faster to a first release.
As previously planned I worked a bit more than a month, full-time, making the fundamental changes needed to make the code base both easier to work with and more useful. Unfortunately, in the limited time I allocated to work on this full-time, I managed to achieve only around 60-70% of the changes I wanted to make. In the first week of July I had to switch back to ‘spare-time development’ which just mean the development speed that was the norm before.
Still, it’s a major improvement. Having achieved so much makes a first release closer than before. I’m not sure yet if the first release can be published before next year -which is the current objective-, but I believe it is possible and more probable than before. To solidify my estimation, I will need to finish the most a fundamental part of AOS Designer: the back-end.
The Back-end and Front-end Isolation
AOS Designer, like most applications, was always split into two parts, the back-end (previously the ‘core’) and the front-end (previously the ‘view’). The back-end is the code that really does the hidden work, like manipulating the AOSL data, or managing the projects settings. The front-end is basically all you see and interact with: the graphic interface (and some other parts which might be obscure so I’ll skip them).
However, the separation between the two was a bit blurry. There were mixed parts of code using both and making things hard to separate. This wouldn’t be a problem usually but I have potential users, including myself, who wants to build a different front-end for different purpose. For example what if you have to build a website which would do most of the work that AOS Designer does? You would have to re-implement it. It’s ok if the work is simple but in our case some manipulations might not be simple at all to grasp. I have some plans, in the future, to setup a website using the back-end code on the server, which was impossible before. The previous code also prevented potentially changing the AOS Designer interface with something specific to each OS. Qt is nice and all but it’s not always perfect.
Isolating the back-end and front-end was not really easy with the code base of the end of last year, which is why since the beginning of the year all the work done in AOS Designer was to make that separation. The changes impacted almost all the AOS Designer code.
The good news is: the separation is totally done now. Back-end and front-end are fully isolated, the back-end is even usable separately. The bad news is: there is still a lot of work to do! The back-end is currently totally rewritten and is not feature-complete yet.
The massive changes in the back-end and other work in progress will be described in the following parts of this series of articles. Stay tuned!