Hacking:Technical decisions

This page describes technical decisions that stand behind Seamly2D. It will be useful for those who want to know why and which tools we have been using.

The Seamly2D is a standalone project. The reason for such a decision was lack of options. None of projects satisfy our needs: GUI, parametric patterns, support formulas, a pattern format and cross-platform solution. Instead we concentrated on low level blocks.

Historical background
Very often the reason of using one tool or another came before actual start developing a project. It based on founders experience and likes.


 * First prototype was made on Pascal.
 * Next try was made on C and GTK+. It was time when we describe a pattern in C, instead of using normal interpreter language like Python for example, and export a pattern to png, pdf and ps.
 * That prototype than was ported to C++ and GTKMM.
 * Next logical conclusion was to separate the data and program. This is where we came up with the idea of a pattern file format based on XML.
 * Next thing that you usually want is to have a nice GUI, and here is the time for Qt to show up.

C++ and Qt
When you decide to use Qt you also want to decide which language to use too. There are several bindings, but was decided to use a native one - C++. C++ language itself has a lot problems and some criticize it a lot. But still it is good language if you need speed and your application is very complex (many CAD systems written on C++). Of course, as was mentioned before, Qt itself is also a big reason why we use C++.

Qt's killer feature for us was Graphics View Framework. This set of classes allow us quick build GUI for manipulating objects. A lot developer teams do own research in this area, but we decided not to reinvent a wheel and concentrate on more important things. Of course this is not all. Qt is a standalone cross-platform framework with very good documentation and a lot examples. It brings almost all classes and abstractions we need to build Seamly2D. Almost all because additionally we adopted muParser library for our formula parsing.

In the end it allows us build project that has only one external dependence Qt itself. And this fact make maintaining very easy. Some users appreciate this fact very much.

Mercurial
For our work from the beginning we have been using Mercurial. Why? No big reasons. It's more matter of tastes. It just work, it cross platform, it has very nice GUI TortoiseHg. And because of mercurial our main repository lives on Bitbucket. Probably in future we will migrate to git, but only if most developers will want it.