Global settings

The global settings are the information that can be found in startup.conf and all other settings used by the application. It is and instance of the DEBSettings class. You get hold of it by calling getsettings. It works in the same way as getpath by creating the object the first time and from then on deliver the global object. There is one difference from getpaths, and that is the creation of directories and startup.,conf with defaults if it do not exist. It uses getpaths with do parameters to get the paths, so it is important that you have called getpaths before using getsettings if you want to use any modifiers when generating the global paths object.

The creation of startup.conf

When no startup.conf file exists in the paths.myapps directory, the getpaths will create a new one from a default found in the paths.builddef directory with the name defaults/langcode/startup.conf where langcode is yours or the default "en" if no one is set. For now you can assume it will be en as this is the only supported language at the moment.

Loading of settings

If you have a value in paths.myapp, this will be used to load myapp based on this path. Do not use this unless you want to use the default versions of apppaths and myappsettings. If not use the factory version of creating the objects given in the manual methods.

The defaults folder and startup.conf template

To accommodate your application with files, the DG3 framework used default files and templates when generating it's files. This might feel as an extra burden when creating the project, but will help adding flexibility and extensibility later on. The files are added inside the Definitions folder and if you added a prefix to you settings, this is added to the Definitions folder as well (ex. Definitons\DEReporter). Then you will find several new folders named defaults, forms and templates. There might be more than these tree, but all of these should be present. Each of these folders then have sub folders with language codes. The default and fallback folder is "en". This is the one we are looking up when the files are not found in other languages. When you now have navigated into the language folder, this will be the root of the names you send to the form, default and template loaders. Ex the name startup.conf will be looked up in the paths.defpath + defaults\en\startup.conf for a default file and the like for forms and templates. The order the application looks up files are myapp.paths first and then app.paths. The order is locale language first then english and that is done myapp folder first then the application folders. This means that you are able to override templates in your local application and use fallback found in the master application for you local application as well.

What you need for a minimal applicaton in your Definitions folder

"""
The startup settings for DEReporter
"""
settings = {
    'version' : 0.11,
    'language' : 'en',
    'recentlyopened' : [],
}

The default startup.conf

"""
The definition of the default main window
"""
title = 'Main application window'
form = {
    'type' : 'mainwindow',
    'title' : '@getreporterversion()',
    'onclose' : '@me._runonappexit()',
    'panels' : {
        'elements' : [
            'main/StartNavigator',
        ],          
    },
    'main' : 'main/StartStackedWindow',
    'statusbar' : 'main/StartStatusBar',
}

The main app window form. You can have less than this example. The main is the only that needs to be populated. This example loads other forms in startup for all parts of the screen. This make it easier to reuse fragments of forms in many other forms. The "@function()" calls back to the class loading the form in some fashion.

"""
Configuration for DEReporter
Updated at {% now "D d. M Y h:m" %}
"""
{% load settingstools %}
{% writesettings dg3 %}

The template for saving startup.conf. The witesettings takes the settings dict and formats it into this file.