Cross-platform C SDK logo

Cross-platform C SDK

New project

❮ Back
Next ❯
This page has been automatically translated using the Google Translate API services. We are working on improving texts. Thank you for your understanding and patience.

I see myself as a technical person who chose a great project and a great way of doing that project. Linus Torvalds.

In previous chapters we downloaded the software, executed the examples and learned something about the structure of the SDK. It's time to create a new application from scratch.

1. The Die Application

In this chapter and the next one we are going to work on a real application (Figure 1), included in the directory src/demo/die of the SDK. It is a simple program that allows drawing the silhouette of a die, manipulating parameters through several Slider controls. Here we will only see how to create the Visual Studio solution.

  • Go to Die for application details.
  • Go to Resources for more details on the use of texts and icons.
  • Go to Portability for details about compilation on macOS and Linux.
  • Capture of the Die application.
    Figure 1: Application Die. Inspired by DieView (Cocoa Programming for OSX, Hillegass et al.).

2. Solutions and projects

In Visual Studio (and Xcode or GNU-Make) there is the concept of solution that is, in essence, a container of projects that have some kind of relationship. On the other hand, a project is an executable program or a library. These solutions implement compilation scripts that allow to generate, link, execute and debug applications. When opened, Visual Studio will automatically load all the projects it contains. As we saw in Quick start, CMake creates the NAppGUI solution fully configured and ready to compile, with all SDK libraries and demos. This is based on the file /src/CMakeLists.txt. If we want to create a new application, we just have to add the following line to the end of the file:

Listing 1: src/CMakeLists.txt
desktopApp(Die2 die "" NRC_EMBEDDED NO)
We use Die2 because the Die application already exists as part of the demos. VisualStudio does not allow to have two projects with the same name.
  • Once ready, open CMake.
  • Where is the source code: C:\nappgui\src.
  • Where to build the binaries: C:\nappgui_build.
  • Press [Configure]: If this is the first time you generate the project, CMake will ask for the compiler (we use Visual Studio 16 2019). If you previously made the points of the section Compile the examples it will only update the current solution.
  • Press [Generate] and then [Open Project].
  • You'll see that CMake has created a new project called Die2 within the solution (Figure 2).
  • Capture the Visual Studio Solution Explorer where the new project appears.
    Figure 2: Die2 project newly added to the solution.

If you compile and execute Die2, you will realize that it is not other than the Hello, World!, since this is the default template for each new desktop application. It has also been assigned a Application icon by default, but we can change it later. If we delve into the syntax of the command desktopApp that we just added to CMakeLists.txt, we have:

desktopApp(Die2 die "" NRC_EMBEDDED NO)

desktopApp(appName path depends nrcMode installer)
  • appName: The application name.
  • path: Relative path within the solution where the project will be located (in this case C:\nappgui\die). Any path depth is supported. For example, "games/die" will create the project in C:\nappgui\games\die and "demo/games/die" in C:\nappgui\demo\games\die.
  • depends: All applications link by default with the NAppGUI SDK libraries. If the application needs additional dependencies, such as libraries created by the user, we will write them in this field separated by semicolons (eg. "physics;render"). As in this project we do not have any we passed an empty string ("").
  • nrcMode: How resources will be managed. For the moment, NRC_EMBEDDED. We will deepen them in the next chapter Resources.
  • installer: Supports two values YES or NO which indicate whether an installer must be created for the application. More information in Installers.
You can create as many new applications as you want. You just have to repeat the process, adding new ones desktopApp() to the script CMakeLists.txt.

3. Adding files

Returning to the project Die, we see that it only has one source code file (main.c). For this case it might be enough, but we are going to divide the code into several files, since it will be the usual in practically any new application that we approach. To add new source files, we simply create them through the file explorer:

  • Go to C:\nappgui\src\die using Windows Explorer.
  • Right click->New->Text document. Rename die.hxx. In this file we will include the definitions of shared types.
  • Repeat and create dgui.h and dgui.c. Here we will implement the GUI (Figure 3).
  • Windows Explorer capture, where new files are being created.
    Figure 3: Adding new files to the project, directly from the file browser.
  • Create a new folder within die. Change the name to draw.
  • Open draw and add two files: ddraw.c and ddraw.h. Here we are going to implement the drawing functions.

Press [Generate] in CMake to update the solution. Visual Studio informs us that there have been changes in the project Die (Figure 4). Simply press [Reload Solution] and the new files will be added (Figure 5).

Warning that Visual Studio shows, detecting that new files have been added.
Figure 4: Visual Studio warns about new files. Press [Reload Solution].
The new files, within the Visual Studio project tree.
Figure 5: CMake will clone the project file system within the solution.
You have the content of each of these files in /src/demo/die and /src/demo/casino. Soon, in Libraries we will see how to share code between applications.

After clicking on [Generate], CMake analyzes the files and subfolders of the project and updates the solution. Establishes the INCLUDE_PATH, group the sources in folders and review the resources. It is necessary to press [Generate] when adding or deleting files from the project. If we only edit the code it is not necessary, since the structure of the project has not changed. With recompiling it will be enough.

4. Command line applications

A few years ago, when graphic environments did not exist or were in an experimental phase, computers were handled through a text terminal. The user typed commands and the machine responded by printing messages or data on the screen. Today our dialogue with the application is carried out through mouse clicks or directly with your own finger. However, this type of "console" applications are still very much alive today, especially with regard to the tasks automation.

Automation is about getting the computer to do things without a human operator being constantly present. We have an example in (Figure 6), where we have improvised a simple application to change the size of images. The operation is simple: Open the image, select the new size and press the [Resize] button.

Capture a hypothetical desktop application to resize images.
Figure 6: Simple application to image resizing.

The problem here is that we are the ones who, constantly, have to guide the program step by step: Open, edit, save, open, edit, save, ..., etc. If we had to resize 100 images the task would become monotonous, repetitive and very very expensive. A version of the same application by command line would be something like that.

imgresize C:\imgs\nature.jpg -w320 -h160 C:\imgs2\nature.jpg

We can think that we have not won much. We have gone from a few clicks to having to write a paragraph to perform the task. Nothing is further from reality. The first advantage is the ease with which we can process batches of images:

Listing 4: Python script to process multiple images.
import os
for file in os.listdir("C:\imgs"):
    if file.endswith(".jpg"):["imgsize", file, "-w360", "-h160", "C:\imgs2\" + file])

If we had 1000 images in the directory, this program will take a few seconds (in the worst case) and we will take a whole day (at its best). We could also improve the script by uploading the new images to a remote server, for example.

As you can imagine, to create a console application, we will return to CMakeLists.txt of our solution and we will add a new line at the end of it:

Listing 5: src/CMakeLists.txt
commandApp("utils/imgresize" "" NRC_NONE)

commandApp(appPath depends nrcMode)

The parameters are very similar to those of desktop applications:

  • appPath: Application directory within the solution.
  • depends: Dependencies. A command-line application always adds a dependency with Core, since this library provides a lot of utilities that greatly enrich the C language. Libraries like INet, Draw2D and Geom2D they do not require a graphical interface and could be added as dependencies if necessary:
  • 1
    commandApp("utils/imgresize" "draw2d;inet" NRC_NONE)
  • nrcMode: NRC_NONE, NRC_EMBEDDED or NRC_PACKED. Resources distribution.

After CMake [Generate], the new project has been created in Visual Studio. It goes without saying that adding new files is done in a similar way to that seen in desktop applications, we will not repeat it. If we navigate to the source code, CMake has created a simple template:

/* NAppGUI Console Application */
#include "coreall.h"

int main(int argc, char *argv[])
    bstd_printf("Hello world!\n");
    return 0;

Which is the typical C program template, which has included the support of the core library. From here, we can modify the code and compile. CMake has already set everything up for us.

❮ Back
Next ❯