[Bf-committers] keyboard configuration issues

Campbell Barton ideasman42 at gmail.com
Fri Aug 20 05:25:13 CEST 2010

On Fri, Aug 20, 2010 at 1:57 AM, Martin Poirier <theeth at yahoo.com> wrote:
> --- On Thu, 8/19/10, Campbell Barton <ideasman42 at gmail.com> wrote:
>> A simple solution to this is to have a package in cfg so
>> scripts/cfg/blender_keyconfig/__init__.py
>> scripts/cfg/blender_keyconfig/maya.py, etc
>> ...this way only sys.modules["blender_keyconfig"] is added
>> and the
>> submodules can be added & removed without worrying
>> about naming
>> collisions.
>> But thinking about this I wonder if its a good idea to load
>> all key
>> configurations on startup at all. Say we have 3-4
>> configurations, each
>> are fairly big python scripts and run many functions to
>> build a
>> keyboard layout with operator properties.
>> How about use a system similar to our presets, where the
>> files in a
>> directory are used to fill a menu, and the script runs only
>> when
>> selected by the user.
>> A string can be saved for the active layout and this can
>> run automatic
>> on startup when set.
> If we go for a package, we get conditional load for free (importing a package doesn't import submodules by default).
> We could just do dir(blender_keyconfig) to get a list of available configs and import blender_keyconfig.ConfigA to initialize it.
> Martin

That's be ok, though I still prefer running the scripts and not importing them.

Modules are better suited to cases where you need to keep the modules
state in memory, and in our case where register()/unregister().

>From what I can tell a key config just executes a load of key
configuration functions and quits so I don't see the need for modules.
But if you think there are times when configurations will need to
define operators/menus for eg, or make use of register/unregister
functions then we're better going with modules.

- Campbell

More information about the Bf-committers mailing list