Bachelor Thesis - Computer Graphics Group
Bachelor Thesis - Computer Graphics Group Bachelor Thesis - Computer Graphics Group
Chapter 3 Technologies used The application has been developed in C++, as already mentioned in the Introduction. The main reasons for choosing C++ were high performance and the ability to write low-level system code easily. After selecting the programming language, the development tools and libraries had to be decided. C++ is an extremely widespread language offering dozens of development environments and thousands of different libraries and toolkits. 3.1 Visual Studio 2008 + Feature Pack The choice of the integrated development environment (IDE) was straightforward. Microsoft Visual Studio is a quality product, probably the best choice for Windows development. A student license for non-commercial purposes is available through the MSDN Academic Alliance program. The C++ compiler offers very good performance of the generated binary code. MSDN provides extensive documentation of the Windows API, which cannot be avoided. The program has to interact with and control other user’s applications in ways not offered by higher-level frameworks. Smart pointers, included in Technical Report 1 (TR1) [35], have been used. TR1 is an addition to the Standard Template Library (STL). By using the shared ptr template class, the majority of explicit object destruction could be eliminated. This helps to avoid potential memory leaks and problems related to passing of object instances. There are two ways how to get TR1. Either from the Visual C++ 2008 Feature Pack [24], which has been released recently and will be a part of the upcoming Service Pack 1. The second possibility is to use Boost, a collection of free high quality C++ libraries for various purposes. 16
3.2 Graphical user interface toolkit The decision which graphical user interface (GUI) toolkit to use was harder. Nevertheless, the choice that has been made proved to be the right one. The main requirements imposed upon the toolkit were: • native look & feel, matching dedicated Windows applications as closely as possible • clean object-oriented design allowing simple extensibility • well documented, examples and sample applications should be provided • must be free for use in non-commercial applications; no particular type of license is demanded • a cross-platform framework is a big plus, as it allows potential porting to Linux or Mac OS X in the future • extra functionality such as network and XML support would be appreciated, to eliminate the need to use other libraries with a different naming conventions, data types, etc. There are many widget toolkits and frameworks available for C++. The major ones include: Qt, wxWidgets, GTK+, Microsoft Foundation Classes (MFC), Windows Template Library (WTL) and Windows Forms. All of them have both pros and cons: • GTK+ [14] does not provide the level of conformance to the Windows user interface guidelines [27] as users would expect. Widget rendering differs from the native look & feel. Buttons in dialog boxes are ordered differently and they use non-standard icons and labels. A custom file open/save dialog, which is confusing and less capable, is used instead of the standard one provided by Windows. One of the limitations could also be the use of UTF-8 encoded strings, which have to be converted into the native UTF-16 representation used by the native Windows API functions • wxWidgets’ [39] design dates several years back, when C++ compilers were much less capable than they are today. Therefore, the library lacks support for modern C++ features, such as templates or the STL library. The code is not exception safe; the programmer has to be careful to avoid program crashes. wxWidgets do not implement their widgets from scratch, but rather wrap the native ones provided by Windows. This approach offers high performance and native look on one hand, but on the other hand, it limits the possibilities. Moreover, the library does not have a full-featured painting system with vector graphics support. This is essential in order to create appealing user interface elements 17
- Page 1 and 2: Charles University in Prague Facult
- Page 3 and 4: Contents 1 Introduction 6 1.1 Motiv
- Page 5 and 6: Title: Mouse Gestures Author: Milan
- Page 7 and 8: 1.2 Existing solution Still, one su
- Page 9 and 10: Right clicking the icon will displa
- Page 11 and 12: Chapter 2 Gesture recognition Our m
- Page 13 and 14: vector of fixed length, called the
- Page 15: measure, we get K nearest objects.
- Page 19 and 20: • QObject instances are organized
- Page 21 and 22: 1. the most naive idea is the user
- Page 23 and 24: e supported too • the user must b
- Page 25 and 26: Global uniqueness of the statically
- Page 27 and 28: The function supposed to invoke the
- Page 29 and 30: Chapter 5 Main application 5.1 Appl
- Page 31 and 32: The gesture capture library identif
- Page 33 and 34: is given the opportunity to perform
- Page 35 and 36: shape of the gesture. It can also c
- Page 37 and 38: 5.7 User interface Universal Gestur
- Page 39 and 40: Figure 5.6: Pattern Editor window T
- Page 41 and 42: steps would have to be taken: 1. mo
- Page 43 and 44: tion can be exploited in some parts
- Page 45 and 46: menu. One of the main goals was mod
- Page 47 and 48: [13] FireGestures, http://www.xulde
- Page 49: Appendix A User documentation 49
3.2 Graphical user interface toolkit<br />
The decision which graphical user interface (GUI) toolkit to use was harder.<br />
Nevertheless, the choice that has been made proved to be the right one. The<br />
main requirements imposed upon the toolkit were:<br />
• native look & feel, matching dedicated Windows applications as closely<br />
as possible<br />
• clean object-oriented design allowing simple extensibility<br />
• well documented, examples and sample applications should be provided<br />
• must be free for use in non-commercial applications; no particular type<br />
of license is demanded<br />
• a cross-platform framework is a big plus, as it allows potential porting<br />
to Linux or Mac OS X in the future<br />
• extra functionality such as network and XML support would be appreciated,<br />
to eliminate the need to use other libraries with a different naming<br />
conventions, data types, etc.<br />
There are many widget toolkits and frameworks available for C++. The major<br />
ones include: Qt, wxWidgets, GTK+, Microsoft Foundation Classes<br />
(MFC), Windows Template Library (WTL) and Windows Forms. All<br />
of them have both pros and cons:<br />
• GTK+ [14] does not provide the level of conformance to the Windows<br />
user interface guidelines [27] as users would expect. Widget rendering<br />
differs from the native look & feel. Buttons in dialog boxes are ordered<br />
differently and they use non-standard icons and labels. A custom file<br />
open/save dialog, which is confusing and less capable, is used instead of<br />
the standard one provided by Windows. One of the limitations could<br />
also be the use of UTF-8 encoded strings, which have to be converted<br />
into the native UTF-16 representation used by the native Windows API<br />
functions<br />
• wxWidgets’ [39] design dates several years back, when C++ compilers<br />
were much less capable than they are today. Therefore, the library lacks<br />
support for modern C++ features, such as templates or the STL library.<br />
The code is not exception safe; the programmer has to be careful to<br />
avoid program crashes. wxWidgets do not implement their widgets from<br />
scratch, but rather wrap the native ones provided by Windows. This<br />
approach offers high performance and native look on one hand, but on<br />
the other hand, it limits the possibilities. Moreover, the library does not<br />
have a full-featured painting system with vector graphics support. This<br />
is essential in order to create appealing user interface elements<br />
17
Change language