lichtkind

As Kephra gets prepared for its great day, there are some design decisions hat make me just happy and maybe you will benefit from it too.

The previous incarnation had also a command list. A central place where most calls are stored that end up in the menu a toolbar or the user can access otherwise. But it was not only the API into userland, it also helped to create menus and bars from very simple yaml files, that only listed command IDs. Because to every command belonged a label, icon, and key informations, the rest was almost trivial. This way you could very easily change the menus within the editor (with the line move functions) and the change was visible as soon you hit save (or autosave reacted).

One major flaw of this system was: informations that belonged into code were exposed inside of config files. Very bad and fragile. But more ugly for me, changes were troublesome because I had to go to several places.

But now I did it a bit different. Now every module registers its commands on compile time with a special subroutine call to the command list. Localisation, icons, different keymaps and so on are added later by config data. This has also the advantage that you can see when opening a source file of a module, you can see on the first page what this module contributes to tha app. This way stays also together what belongs together and because of that closeness it's easier that inspiration of the correct naming of functons and labels can flow in both directions. It is helpful that reading code becomes easier just by watching the menu or toolbar, because naming is often the same or very near.

Commands do a lot more. They handle parameter and return value for more complex operations. API is not final here, but this way you get a right place to create commands with a bit of metadata without having to write so much code. It gets also practical if several commands calling the same sub, but with different parameter are the items of a radio button like menu, to select one or the other otion which is also the result and current status of that joined function. Because the CommandList has all the data it needs - much of the code can be autogenerated from the definitions. works also if you just want to use functions provided by libs as a command, without having to make wrapper code.

Another problem is that some calls are method calls from not always the same object and sometimes normal subs. this flexible system spares me from writing proxy modules that do nothing more than calling a method that gets me the right object and calling that the method on that every time.

Now you may ask: Where's the code. Soon ... very soon. Oh wait just have a look.

P.S.
The title is a pun on knuths literate programming which is very similar to the command register calls, but I like djikstra too.