[Bf-committers] SystemError when using simple mesh commands in scripts started from the command line...
ideasman42 at gmail.com
Mon Nov 9 08:55:43 CET 2009
Python can define its own context which may help to work in background
mode, I think this would be the script context your asking about but I
didn't test this yet.
At first I tried to generate python documentation in background mode
but it didn't missed the python operators since they are not loaded.
AFAIK we haven't even tried to have the python api work in background
mode - (speaking for myself at least)
Unless your prepared for debugging/fixing internals Id not recommend
testing background mode at the moment.
On Mon, Nov 9, 2009 at 8:11 AM, Dietrich Bollmann <diresu at web.de> wrote:
> Hi Martin :)
> Interesting reading. Sounds much more involved than I initially
> thought... :)
> Reading this document, I have the impression that some parts are still
> under heavy development. Especially the context handling looks like not
> being solved for the moment. I also seem not to be the first who
> stumbles about the problem of scripts executed from the command line...
> So probably I just should stop to ask stupid questions, let you work
> and ... wait :) The only thing I don't like about this option is, that
> everything I will create until then is already outdated...
> The other option - to try to hack things myself - probably makes
> everything only worse :)
> ...Of course I would be happy to ask, why you don't simply move the code
> for executing the command line scripts to some place after the
> initialization of the window manager, create some special script context
> and than use some "non-interactive" kind of flag to make the event
> handler skip the gui polling...
> But I am sure that you already have thought about better ways to handle
> this problem and are searching some more general and elegant solution :)
> So I'll wait...
> Thanks for the interesting Mails!
> Regards, Dietrich
> On Sun, 2009-11-08 at 13:16 -0800, Martin Poirier wrote:
>> --- On Sun, 11/8/09, Dietrich Bollmann <diresu at web.de> wrote:
>> > So invoke would be used for functionality which for
>> > instance use mouse
>> > input to rotate some object?
>> Yes. Like transform, loop cut, lasso, brush select, ...
>> > And operations used in a script which does not need user
>> > input would
>> > only use exec?
>> > Probably the bpy.ops.mesh.primitive_cube_add() command than
>> > would be of
>> > the second kind and not require the window context?
>> It's not as clear cut as that. Some operator supply both an invoke and exec function, so it has to be decided based on calling function, not operator type.
>> > Just by curiosity:
>> > Concerning interactive commands, why isn't it enough to
>> > specify the
>> > window(s) when registering an event handler?
>> It's not so much the window that is missing but the whole windowmanager. When running scripts from command line, it tries to run them before the UI is fully initialized.
>> > Aren't interactive commands (event handlers) reacting on
>> > user input
>> > invoked by events in the queue of the window they
>> > registered for? As
>> > there is exactly one event queue per window the window
>> > should be clear,
>> > no?
>> The window missing from context only applied to operator running from the command line (or in background mode), otherwise it is not a problem.
>> > Non-interactive commands on the other hand wouldn't need
>> > the context at
>> > all. (At least if they only manipulate a scene and
>> > not some window
>> > itself.)
>> Context is like a generalized dictionary. They would take the current scene from the context too.
>> > Are there documents which explain Blenders new event
>> > system?
>> Some of it is on this wiki, like on this page for example:
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam protection around
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers