​

xtd overview

​

Table of contents

​​

• Motivations

• What is xtd Framework ?

• xtd API

• xtd libraries

• xtd architecture

  • Dependency

  • xtd.core

  • xtd.core.native

  • xtd.core.native.unix

  • xtd.core.native.win32

  • xtd.drawing

  • xtd.drawing.native

  • xtd.drawing.native.wxwidgets

  • xtd.forms

  • xtd.forms.native

  • xtd.forms.native.wxwidgets

• xtd tools

  • Command line tools

  • GUI tools

• xtd tests

  • Unit tests

  • Manual tests

• xtd themes

  • Current Operating System / Desktop Environment

  • Generic

  • Colors only

  • Owner themes

• Build

  • CMake

  • Specific CMake commands

  • xtd build CMake options for xtd developers

• xtd guidelines

• Unit tests

• Continuous integration builds

• Test coverage

• xtd documentation

​​

Motivations

​

What are the criteria for a modern C++ framework in 2019 :

​

• C++17/20 modern

• RAII programming idiom.

• Use of namespace and no prefix

• No defines for constants and no macros for functions or event logging.

• All classes must be in namespaces.

• No global but rather static classes.

• No functions outside of classes except for extend std.

• Native controls if no theme defined. However, controls must be able to support predefined CSS themes or CSS themes created by the developer himself.

• Controls can be drawing by the user.

• Close to the std.

• Denomination of classes and functions according to std and boost standard.

• Modern events based on std::functional.

• Clear and unambiguous API. With a consistent style throughout the evolution of the framework.

 

After looking and trying (more or less in depth) many known or unknown C++ GUI libraries/frameworks. I never found one that matched these criteria.

 

Just take all the existing C++ GUI libraries and frameworks and you can see that none of them fit the above criteria. This does not mean that they are not good or that they do not work. Far from it, some of them are excellent, like Qt, wxWidgets, JUCE to name only these three. Some others are excellent too, some are less good and unfortunately many are mediocre or even abandoned.

 

Here is a paper written by Philippe M. Groarke that summarizes the advantages and disadvantages of each C++ library/framework.

 

So the decision to create a new GUI in modern C++ was made.

​

What is xtd Framework ?

 

xtd is a framework based on an OS abstraction via the xtd.core.native API and a graphical abstraction via the xtd.drawing.native API and the xtd.forms.native API.

 

At the moment there are two implementations of the xtd.core.native API:

​

• xtd.core.native.win32 : Windows platform.

• xtd.core.native.unix : linux, Android, ios and macOS.

 

But other operating systems can be added in the future or earlier if needed by implementing the xtd.core.native API like :

​

• xtd.core.native.chromeos : Chrome OS.

• xtd.core.native.haiku : Haiku.

• xtd.core.native.xxx : xxx being any OS.

 

For the moment there is an implementation of the APIs xtd.drawing.native and xtd.forms.native :

​

• xtd.drawing.native.wxwidgets and xtd.forms.native.wxwidgets : wxWidgets toolkit.

 

But in the futur, other graphical interfaces can be added by implementing the xtd.drawing.native and xtd.forms.native APIs as per rexamples :

​

• xtd.drawing.native.cocoa and xtd.forms.native.cocoa : macOS appkit. (macOS native API)

• xtd.drawing.native.gtk and xtd.forms.native.gtk : linux Gtk API. (native linux Gnome API)

• xtd.drawing.native.qt6 and xtd.forms.native.qt6 : Qt toolkit. (API "native" Kde linux)

• xtd.drawing.native.win32 and xtd.forms.native.win32 : Microsoft win32 API. (native Windows API)

• xtd.drawing.native.x11 and xtd.forms.native.x11 : X11 API. (generic linux API)

• xtd.drawing.native.x11 and xtd.forms.native.fltk : Fltk API. (generic API)

• xtd.drawing.native.sdl2 and xtd.forms.native.sdl2 : sdl2 media layer. ()

• xtd.drawing.native.sfml and xtd.forms.native.sfml : SFML media library.

• xtd.drawing.native.xxx and xtd.forms.native.xxx : xxx being any other high level or low level graphic API.

 

In summary the goal of xtd framework is to provide a high level interface with its own functionalities while being extremely portable with the simplest possible abstraction layer on the OS and on the GUI.

​

xtd API

 

When I created xtd, I had the choice of creating my own API or using an existing API. I chose to use an existing API because it is difficult to have a consistent API.

 

I also wanted to have an API close to the Win32 API and events because this API and events are known by many developers.

 

Which one to choose? It had to be the one that I knew best, that was consistent and that was complete.

 

In the company I work for, a little more than 12 years ago, we had a project that had to run on the desktop, on an embedded system and on Android (the backend could not be written in Java because the embedded system could not run a JVM). The modern C++11 didn't exist yet, it was the beginning and it wasn't present on all compilers. So I had to create a framework (threads, diagnostics, sockets, web sockets, io, unicode, ... RAII programming idiom, but no GUI) to implement the shortcomings of C++ and I based myself on the .Net framewrok.

​

• The Win32 API is too low level and is in pure C.

• The MFC API is not consistant and old.

• The .Net Framework is consistant and close to WIn32 API and events but is CSharp or managed C++ with garbage collector.

• JavaFX is not close to Win32 API and events but is Java with garbage collector.

• Qt's API is old C++ and doesn't match the modern C++ canon and I don't like that.

• wxWidgets API is convoluted and old c++.

• FLTK is closer to C than to modern C++. Even if I find it attractive for its lightness and its ease of use.

• JUCE is close to a modern c++ API as we would like but unfortunately has a paid license if we don't want to have a splash screen.

• ...

 

I naturally chose the .Net Framework API because it is close to Win32 and has a modern oriented programming approach even if it is not c++.

​

Notes

​

• All classes and methods are adapted to xtd and modern C++.

​​

xtd libraries

 

• xtd API is close to the .net API with a modern C++ approach and full integration with the std standard.

• xtd.core contains some components from mscorelib, System, System.Core libraries of the .Net Framework and of Mono.

• xtd.drawing contains some components from System.Drawing library of the .Net Framework and of Mono.

• xtd.forms contains some components from System.Windows.Forms library of the .Net Framework and of Mono.

• xtd.tunit contains some components from Microsoft.VisualStudio.TestTools.Cpp and support xUnit standard.

​​

xtd architecture

 

See architecture diagram.

 

xtd is composed of several libraries.

​

xtd.core

 

 The xtd.core library is modern C++20 libraries of classes, interfaces, and value types that provide access to system functionality. It is the foundation on which c++ applications, components, and controls are built.

​

xtd.drawing

 

The xtd.drawing library contains types that support basic GDI+ graphics functionality. Child namespaces support advanced two-dimensional and vector graphics functionality, advanced imaging functionality, and print-related and typographical services. A child namespace also contains types that extend design-time user-interface logic and drawing.

​

xtd.forms

​

The xtd.forms library contains classes for creating Windows-based applications that take full advantage of the rich user interface features available in the Microsoft Windows, Apple macOS and linux base operating system.

 

xtd.tunit

 

The xtd.tunit library is a unit-testing framework for modern C++20 inspired by Microsoft.VisualStudio.TestTools.Cpp.

​​

Dependency

​​

• xtd.core.native : no dependency

• xtd.core.native.unix : xtd.core.native

• xtd.core.native.win32 : xtd.core.native

• xtd.core : xtd.core.native, xtd.core.native.unix or xtd.core.native.win32 or other in the future.

• xtd.drawing.native : xtd.core

• xtd.drawing.native.wxwidgets : xtd.drawing.native

• xtd.drawing : xtd.drawing.native, xtd.drawing.native.wxwidgets or other in the future.

• xtd.form.native : xtd.drawing

• xtd.form.native.wxwidgets : xtd.forms.native

• xtd.forms : xtd.forms.native, xtd.forms.native.wxwidgets or other in the future.

• xtd.tunit : xtd.core (not for tests as such, but only used by xtd::tunit::console_unit_test to print the result on the console and for the very partial use of xtd::diagnostics::stack_frame to know the test line).

​​

Remarks

 

All libraries use the std.

​

xtd.core

 

This library is high level API that has access only to the std and xtd.core.native.xxx (xxx = win32, unix, ...) via xtd.core.native interface.

​

Some Rules

​​

• Under no circumstances should xtd.core, xtd.drawing, xtd.forms or xtd.tunit do any precompilation tests (#if defined ... #endif) on the compiler or the OS. Some cases like debug or release (NDEBUG) for diagnostic components. But otherwise that's all. If there is a possible difference between OS or compilers, you have to use the xtd.core.native interface.

• In the same way, if you use an external library, you have to use the xtd.core.native interface. This allows you to isolate yourself from the thridparty library and to replace it if necessary without having to rewrite all the code that calls it.

​​

Remarks

 

There are still some cases that are not yet fully compliant with these rules but this should be fixed before the 1.0.0 release.

​

xtd.core.native

 

This library is a low-level API that has access to the operating system and third-party libraries.

The role of is API is the same que l'API de le JVM of Java ou Common Language Runtime (CLR) of .Net Framework.

​

xtd.core.native.unix

 

It is a low-level library that implements the xtd.core.native interface for linux, macOS, iOs and Android.

​

xtd.core.native.win32

 

It is a low-level library that implements the xtd.core.native interface for Windows.

​

xtd.drawing

​

This library is high level API that has access only to xtd.core and xtd.drawing.native.xxx (xxx = wxwidgets or other in the future) via xtd.drawing.native interface.

​

Rule

​​

• In no case xtd.drawing should do precompilation tests (#if defined ... #endif) on the GDI+ graphics. If there is a possible difference between GDI+ graphics, you have to use the xtd.ddrawing.native interface.

​​

xtd.drawing.native

 

This library is a low-level API that has access to the GDI+ graphics.

The role of is API is the same que l'API de le JVM of Java ou Common Language Runtime (CLR) of .Net Framework.

​

xtd.drawing.native.wxwidgets

 

It is a low-level library that implements the xtd.drawing.native interface for wxWidgets.

​

xtd.forms

 

This library is high level API that has access only to xtd.ddrawing and xtd.forms.native.xxx (xxx = wxwidgets or other in the future) via xtd.forms.native interface.

​

Rule

​​

• In no case xtd.forms should do precompilation tests (#if defined ... #endif) on the GUI. If there is a possible difference between GUI, you have to use the xtd.forms.native interface.

​​

xtd.forms.native

 

This library is a low-level API that has access to the GUI.

The role of this API is the same as that of the Java JVM API or the Common Language Runtime (CLR) of the .Net Framework.

​

xtd.forms.native.wxwidgets

​

It is a low-level library that implements the xtd.forms.native interface for wxWidgets.

​

xtd tools

​

Command line tools

 

• xtdc is project management command line tool.

• guidgen is a guid generator command line tool.

• sleepfor is a sleep for duration command line tool.

​​

GUI tools

 

• guidgen-gui is a guid generator GUI application.

• xtdc-gui is project management GUI application.

​​

xtd tests

​

Unit tests

​​

• xtd.core.unit_tests contains unit tests for xtd.core library.

• xtd.drawing.unit_tests contains unit tests for xtd.drawing library.

• xtd.forms.unit_tests contains unit tests for xtd.forms library.

• xtd.tunit.unit_tests contains unit tests for xtd.tunit library.

​​

Manual tests

​​

• xtd.core.manual_tests contains manual tests for xtd.core library.

• xtd.drawing.manual_tests contains manual tests for xtd.drawing library.

• xtd.forms.manual_tests contains unit manual for xtd.forms library.

• xtd.tunit.manual_tests contains unit manual for xtd.tunit library.

​​

xtd themes

 

A control can have several style modes (xtd::forms::flat_style):

​

• xtd::forms::flat_style::system : The control is native and therefore cannot adapt to the theme defined in the application (xtd::forms::application::theme).

• xtd::forms::flat_style::standard : The control will adapt to the theme defined in the application (xtd::forms::application::theme) with the standard style.

• xtd::forms::flat_style::flat : The control will adapt to the theme defined in the application (xtd::forms::application::theme) but with the flat style.

• xtd::forms::flat_style::popup : The control will adapt to the theme defined in the application (xtd::forms::application::theme) but with the popup style.

​​

Current Operating System / Desktop Environment

​​

• gnome_dark contains GNOME dark theme.

• gnome_light contains GNOME dark theme.

• kde_dark contains KDE dark theme.

• kde_light contains KDE dark theme.

• macos_dark contains macOS dark theme.

• macos_light contains macOS light theme.

• windows_dark contains Windows dark theme.

• windows_light contains Windows light theme.

​​

Generic

​​

• symbolic_dark contains Symbolic dark theme.

• symbolic_light contains Symbolic light theme.

• xtd_dark contains xtd dark theme.

• xtd_light contains xtd light theme.

​​

Colors only

​​

• black contains black color theme.

• blue contains blue color theme.

• dark contains dark color theme.

• green contains green color theme.

• light contains light color theme.

• red contains red color theme.

• white contains white color theme.

​​

Owner themes

 

In the future, developers will be able to create their own themes.

​

Build

​

CMake

 

xtd uses CMake as build script generator.

Commands to generate xtd build project.

​

• On Windows :

​