Age | Commit message (Collapse) | Author | Files | Lines |
|
I mostly do this to avoid code duplication between fluxbox and fluxbox-update_configs.
|
|
previously, init was autosaved only when a resource was modified using the menu. I have also
included modifications through lua code.
To avoid wasting resources, the file is not saved immediately, but with a 5 second delay (to
enable saving a bunch of changes in one go)
|
|
|
|
This way, global variables set by the scripts don't persist between hard reconfigures.
I also cleaned up the reconfig-handling code in fluxbox.cc. Instead of three reconfig functions
(real_reconfig, timed_reconfig, reconfig) we have just one.
|
|
This prevents the user from inadvertently overwriting e.g. the session table and then wondering
why it does not work. I'm still not sure about this approach, as it's not 100% secure (the script
can still use raw access to mess with it) and it adds some overhead to any operation referencing
a global variable.
|
|
|
|
|
|
|
|
this reduces typing and it makes more sense in lua, since there the resources are implemented as
hierarchical tables and the topmost table has to be handled a bit specially.
|
|
|
|
I added a new class, LResourceManager, which should handle loading and saving of resources like
the old ResourceManager, only it does that with the help of lua. I moved the common features of
the two managers (interface + a few functions) to a common base class ResourceManager_base. I
augmented the Resource_base class with two new functions (setFromLua and pushToLua) which are
used by the lua RM instead of getString and setFromString.
Parts of the new RM are written in lua. To avoid loading scripts from a file at runtime I decided
to link compiled lua code straight into the executable. For this purpose I created a small script
which converts a binary file into a declaration of a C array of bytes.
|