1. Herbert Breunung
  2. Kephra


Kephra / lib / Kephra / Internals.pod

=head1 Kephra::Internals

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 name as the files.

With every directory you go deeper into the tree the modules will get more
specific. Thats why the directory Kephra has only the most common tools
and libraries.

=over 4

* API - API for plugins, most cross module calls, central data structures

* App - visuals

=over 4

* Bar - visual units made of one widget

* Editor - editor window helper

* Panel - with sizer assembled visual parts

* Part - functional units


* Config - data

=over 4

* 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


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

=head2 Modules

=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