The module Kephra::API is the best starting point to understand the inner workings.
It's one design goal and purpose of this file, because it gives an overview of
+'s one design goal and purpose of this file, because it gives an overview of
all important functions and values and shows where they originate. From here
you can step to the other major interfaces that can be seen in the first lines.
-But more vitally it decouples cross module calls and allows to change things
-under the hood. As long as the first version number (see L<Versioning>)
-does not change, nothing will be removed from the API.
+But more vitally it decouples many cross module calls and allows to change things
+under the hood during smaller release cycles. As long as the first version number
+(see L<Versioning>) does not change, nothing will be removed from the API.
+Interface too most not document related internally held data.
+We have a much broader understanding of configuration.
+Even Icons and localisation belong to it.
+Its all data which puts the app in the state it is.
+handles the mapping from key kommbo to the command it triggeres for any
+App::Dialog and App::Part
If you want to leave the recommended ways as proposed by the API
to the namespace Kephra::Doc::* belongs also the module Kephra::Doc
+contains just the init process:
+setting dirs, loading libs, finding configs, start worker fork
all plugins an d internal functions should use
+interface an internal functions should use
-all the Wx-GUI-related stuff, all visible parts
+namespace of all the Wx-GUI-related stuff, all visible parts
+module that handles boot and shutdown sequence
+all dialogs are called from here
+namespace of the great visual sections of the app
+keeps track in which App::Part the Focus wanders to make save way back if needed
+wrapper around Wx::Panel + Wx::BoxSizer, helps not to deal with with sizers
+is a stepping stone to the GCL