Kephra / lib / Kephra / Internals.pod

Full commit

=head1 Kephra::Internals

Just in case you want to touch the Kephra sources - this document explains
you where to find what and how it does work together.


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.

=head3 API

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
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 renamed or removed from the API.

=head3 Explained In Detail

=head4 Kephra

contains just the init process:
setting dirs, loading libs, finding configs, start worker fork

=head4 Kephra::API

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.

=head4 Kephra::API::Command

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.

=head4 Kephra::API::DocumentStash


=head4 Kephra::API::KeyMap

handles the mapping from key kommbo to the command it triggeres for any 
App::Dialog and App::Part

* Kephra::App

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

* Kephra::App::Dialog

all dialogs are called from here

* Kephra::App::Part

namespace of the great visual sections of the app

=head2 Kephra::App::Focus

keeps track in which App::Part the Focus wanders to make save way back if needed

=over 4

* Kephra::App::Panel

wrapper around Wx::Panel + Wx::BoxSizer, helps not to deal with with sizers
is a stepping stone to the GCL

* Kephra::App::Window

main frame/window and main layout of the app
holds all the Kephra::App::Part s and Bars

* Kephra::Config

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.

* Kephra::Document

document properties, syntax modes

* Kephra::Edit

text processing

* Kephra::Plugin

plugin namespace
Kephra::API::Plugin is the base class for all plugins


=head1 Glossary

=head2 App

everything visible and GUI (Wx) related

=head2 App::Part

visual area dedicated for one purpose, editor is the most prominent,
but ther are also FileBrowser, IOUnit and more

=head2 Editor

one widget for editing text

=head2 Edit

namespace for the actual editing operations

=head2 Panel

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)

=head1 Document

=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