The module Kephra::API is the best starting point to understand the inner workings.
Thats's one design goal and purpose of this file, because it gives an overview of
the most 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 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.
If you want to leave the recommended ways as proposed by the API
and call functions or data directly ...
here is an overview to the Kephra namespace organisation.
Please not that as shorter the name is (shorter namespace chain),
the more internal and general purpose the module is owning that name.
For instance Kephra::File::Local serves as specialized subtask of Kephra::File.
contains just the init process:
setting dirs, loading libs, finding configs, start worker fork
interface to important internal functions all modules and plugins should use
The modules in the Kephra::API::* namespace are services for a more sophisticated
communication between the modules who do the real work.
Also sort of API but more complex. Contains every call the user is able to make.
Needed to protocol each call for monitoring, macros and other introspection
based functions. Also helps to make simple menu and toolbar definitions.
They just need to be a list of CommandIDs.
handles the mapping from key kommbo to the command it triggeres for any
App::Dialog and App::Part
module that handles boot and shutdown sequence
namespace of all the Wx-GUI-related stuff, all visible parts
Kephra::App::* contains the more lower level stuff and
Kephra::App::*::* the higher level components
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
main frame/window and main layout of the app
holds all the Kephra::App::Part s and Bars
Interface to 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.
document properties, syntax modes
Kephra::API::Plugin is the base class for all plugins
everything visible and GUI (Wx) related
visual area dedicated for one purpose, editor is the most prominent,
but ther are also FileBrowser, IOUnit and more
one widget for editing text
namespace for the actual editing operations
area to place widget on, can be under anything, even under each editor
a Kephra::App::Panel is a helper class that manages its sizer
(visibility and ordering of elements)
our @needed_at_first = qw/App API/;
our @starttime_loaded_modules = qw/
App App::Util API Config Config::Default Config::File
Document DocumentStash CommandList Edit EventTable
File KeyMap PluginRegistrar SanddrumInterpreter Works/;
our @runtime_loaded_namespaces =
our @command_modules =
qw/App App::Panel::Editor App::Panel::FileBrowser App::Panel::IOUnit
App::Panel::OrgPad App::Panel::ProjectManager App::Panel::SratchSheet
Edit File EventTable KeyMap PluginRegistrar SanddrumInterpreter/;
our @oop_interfaces =
qw/App::Editor App::Panel App::Splitter App::SidePanelController