[Bf-committers] Blender Command Port

Dietrich Bollmann d.bollmann at tu-berlin.de
Tue Apr 15 04:50:56 CEST 2008


Hi GSR,

On Mon, 2008-04-14 at 19:03 +0200, GSR wrote:
> Hi,
> diresu at web.de (2008-04-13 at 1447.00 +0900):
> > > >   - remove the --geometry NNNxNNN+NNN+NNN option I added?
> 
> Please split features for easier tracking. The change, per se, has
> merits: standard syntax and flexibility if using the X11 style (size
> or position, size and position, ++ for referencing top left corner, --
> for bottom right, etc).

In order to be independent from implementation differences between
different platforms (Unix, Linux, MAC, MS, ...) I wrote my own
--geometry option parsing code.  You can find it in the attachment of
the current mail.

If you are interested in integrating the code, I will write a patch. 

I originally named the files containing the code as follows:

  - blender/source/blender/include/UTL_parse_options_geometry.h
  - blender/source/blender/blenkernel/intern/parse_options_geometry.c

Would these names and locations be ok for a patch also?
Or should I rather use some other names and locations?

The "UTL_" prefix is my invention (UTL for utilities).
Should I rather chose something else?

> > > > As currently everybody is busy with the new release, I probably 
> > > > better commit a new version of my command port patch when Blender 
> > > > 2.26 is out, right?
> > > 
> > > After numerous tracker comments and a long mail list thread, I am 
> > > happy to see we finally have an understanding.
> > 
> > So am I :)
> > 
> > > After the 2.46 release, we intend for Blender to have a new event
> > > handling system.
> > 
> > That sounds like good news :)
> 
> Nice thing to see you keep on with the port idea, it will allow all
> new kind of uses that are not even imagined now. There are other apps
> which provide such system, under diverse names (shell, client, remote
> pipe...), and all become more flexible and useful with such option. I
> see someone mentions render farms, it could allow to control frame per
> frame without having to restart Blender and reload data. Or create a
> headless exporter and conversion tool (at worst, one would need Xvfb).

Sounds great :)

As I have a local version of the command port which works for the
current blender as found on the repository and have to clean it up from
other features anyway, I plan to write a patch as fast as I find time.

If the new event system comes out I will try to find the time for
integration.

Who knows, may be there are some features in the command port code which
might be helpful for the new event system: 

  - The protection of the main queue with mutexes to make the queue
    thread save or 

  - the implementation of the master/servant behaviour via 
    condition variables 

for example.

Greeting from a warm and sunny Tokyo :)

Dietrich

> GSR
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UTL_parse_options_geometry.h
Type: text/x-chdr
Size: 2058 bytes
Desc: not available
Url : http://lists.blender.org/pipermail/bf-committers/attachments/20080415/f9368549/attachment.h 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parse_options_geometry.c
Type: text/x-csrc
Size: 6386 bytes
Desc: not available
Url : http://lists.blender.org/pipermail/bf-committers/attachments/20080415/f9368549/attachment.c 


More information about the Bf-committers mailing list