If you want to touch the Kephra sources -
this document explains where to find what and how does it all work together.
In case you learn better by code - start at Kephra::API.
In each file is only one package with exactly the same name as the file.
With every directory you go deeper into the tree the modules will get more
specific. Thats why the directory "lib/Kephra" has only the most common
tools and libraries. Other dir:
* API - API for plugins, most cross module calls, central data structures
* App - visuals
* Bar - container widgets (menu bar, toolbar, tab bar, status bar, etc.)
* Editor - editor widget helper
* Panel - with sizer assembled visual units (snippet lib, io unit, etc.)
* Part - functional units (main part, side panel, etc,)
* Config - data
* Default - built in fall back configs when certain files are in trouble
* Document - document properties
* Edit - text manipulation functions
* Files - all sorts of IO
* Plugins - namespace of users extentions
contains just the init process:
setting dirs, loading libs, finding configs, making worker fork, starting app
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.
If you want to leave the recommended ways as proposed by the API and call
functions or data directly (or even better you want to help to develope Kephra) ...
here is an overview to the Kephra namespace organisation.
Please note that the 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.
The module Kephra::API is the best starting point to understand the inner workings.
That's actually one design goal and purpose of this file, because it gives an
overview to the most important functions and values and there origin. From there
you can step to the other major interfaces that are included with C<use> in the
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 renamed or removed from the API.
=head3 Explained In Detail
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)
=head2 Interdependency Of Core Modules
=head2 Modules vs Objects
=head2 Boot Stages
Just using the fact that when modules are loded (after the fork)
there main code (outside the sub) is run. At this time we create the
basic command list and the definition which module gets which part of
the global config (actual loading happens later).
=head2 Worker Fork