Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

sir_lichtkind (5541)

sir_lichtkind
  (email not shown publicly)
http://kephra.sourceforge.net/

(brave) Perl monk from Eastern Germany
Friday December 11, 2009
04:44 PM

what are configs?

[ #40010 ]
In the last post I mentioned Kephra's menu definition files. These can only work, because we have a very important file namend commandlist. There is a binding of a chunk of data to each call. the internal call, a callback that says me which state this call has or if should be disabled. also events the will be triggered if that data or status changes, an association to an icon file and the key binding is also defined there. the label and hint texts are of course part of the localisation.

how to call such files? I put it under "config/interface/*" and "config/localisation" but i'm not shure if its the right term for that. there is also a config file, where all the setiings are saved, under "config/global". Just recently i throw some parts out that are not really settings. for instance the previously used search terms and bookmark position. I put it into the search_data.yml to clean things a bit up. Also the config validate routines have now a much easier job. also the list of closed files i move from the settings into an own file. it will be a regular Kephra file session file, that holds all properties so if you restore any file from the closed files menu, you have all you settings with the marked postitions back.

There is also an extra file for the notepad content. we have a file with the templates you can insert form the templates menu. and then you have the directory "config/syntaxstyles" where are the color definitions for the syntax hightlighters are lying. there is also an dir "syntaxmodes" because we soon do a transition from these syntaxstyles to a richer format that contain more information about that language. how to comment, which interpreter /compiler to use and so on.

the we have also some files we try to hide a bit from the use in some deeper nested directories. that are subconfigs that define the help menu for a particula language or some precompiled yaml informations, that help to speed up the boot time. for instance if you translate Kephra into spanish or russian (hint, hint!) and translate the config/localisation/english.conf into an spanish.conf and put it into the localisation folder. Kephra recognises during the next start that there is a new l18n file and recompiles the language selection menu and replaces the old definition in the "config/interface/cache" folder. The label and hints for that menu item will be taken out of the meta head of the l18n file.

but all that will grow and grow and soon (before kephra 0.5) we get plugins that have to be stored somewhere with their own config files that have to be also stored somewhere. so i currently just rethinking this whole system. We had 3 extensions so far, but they all went into the core, because the're small. I don't believe that making a plugin out of every tiny thing, that is not needed to boot an app is such a smart idea like purely rational people like me to believe. I'm here very anti eclipse (the nether Khephra is a sun bearer not a sun eclipser) but Kephra is anti eclipse in all means. But thats an topic of its own, for a new article.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.