Well I haven’t blogged in a while (read ever since I started coding for GSoC), but then it has been an eventful month with myths being debunked. Before this, I believed that if you just sit down and and start writing lines of code, you will get somewhere and there will be some order out of chaos. Guess what didn’t happen while I was putting my half-baked ideas to code ?
But my mentor came to my rescue and I am a wiser man now 🙂
So, what have I been working on ? Well, as in the first post, I mentioned Dirty Presets. So basically, a user can temporarily save his tweaks to a preset during a session without actually overwriting it.The tweaks stay till the user reloads the original preset from the file.
That was about the usability of the feature. But more importantly, I wanted to write about the design that is behind it and why it is important to get it right before the actual coding.
Initially, I was going with the idea that I can create a temporary file for each loaded preset and using the load and save methods would get the temporary tweaks. But soon I realized that that particular way of doing things required unnecessary massive refactoring of existing classes. Also, I realized that it wasn’t as if the tweaks were already not saved. they were just overwritten by the original settings somewhere in the workflow.
So, the next obvious solution that came to mind was to skip that portion in the workflow. Once I did that — Dirty Presets came to life. Just with about 10 lines of code — I was able to keep all tweaks made in a session till the end. However – now came the two more important parts — adding a Reload functionality( making the presets clean again) and marking a preset when it is dirty.
Hence began a week full of qDebugs and git resets. While DmitryK, my mentor, kept advising me against it — I kept working on a model based on UI signals. Using these signals, I developed a way to detect when a preset is dirty and when it is made clean again by reloading.
However, the thing with UI signals is that — they are completely unreliable and there is no predefined order by which they are executed. So while I got the code working on my system, it just crashed on DmitryK’s system.
Here is where Object Oriented Programming concepts come into play and all those long hours in the lecture hall come in use. DmitryK explained to me — that at a logical level, the fact that a preset is dirty or not should remain within the Preset object itself : Basic rule of Encapsulation. So that logic should pervade through to the code and that is where design of the code is as important as the code itself. Hence — the opening paragraph of this post.
So I started again. With parts from the previous implementation and a firm design, in another two days, the feature was completed.We also refactored the code so as to remove all clones of preset objects. It was a days work with DmitryK providing the template by using a policy based design to handle both shared pointers and normal pointers. Another new thing learnt 🙂
The feature is available in the git repository under the branch “krita-mohit-testing” for all of you who are active in the development and testing of Krita 2.9.
That’s all for now. Will post something new about Locked/Shared Settings really soon. That feature is also almost complete and this time — we started with a Proxy Pattern Based Design. More on that in the next post 🙂