[Bf-committers] Introduction: Just a Devops and Infra guy.

[Arnd 'Justa' Marijnissen via Bf-committers]

Sorry for the obvious pun.

I just wanted to drop a note about me having joined the blender 
organization recently as an infrastructure-guy AND, more relevantly, as 
the person who'll be taking on a good number of DevOps related tasks 
that should benefit all developers working on blender-related stuffs. 
This includes you!


Some might have seen me around under my handle 'Justa', on 
blender-coders where I have lurked for a good few years now. Also of 
'Justacluster' fame; having helped build a render-cluster to be used for 
Sintel and subsequent other projects.


That aside; my main focus at blender, on the short term, will be to aid 
in the selection of what platform will be replacing the Phabricator 
software currently in use on https://developer.blender.org as Facebook 
has stopped the development of this last year.


More news about this will be shared here and in other places, so I will 
not make this mail about that *but* if you do have immediate questions 
or concerns or even tips and suggestions, please feel free to reach out 
to me on a...@blender.org !


I just wanted to let people know that I'm out there, and if you're a 
developer, I'm out there  for *you*! So if there are things that need 
fixes, changes, etc.. I'd love to hear about it.


Kind regards,

--
 Arnd 'Justa' Marijnissen
  a...@blender.org
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction

[Mohamed Chebbi via Bf-committers]

Hi

You can start here:

https://wiki.blender.org/wiki/Main_Page

Cdt

chebbi

Le 13/03/2020 à 22:32, mathurin nkenfack via Bf-committers a écrit :

Hi
I am Nkenfack Tebonfack Mathurin a student at the university of Buea in
cameroon. I just join the chat channel. i am exited on how to get started
to contribute and do my very best to learn. Where do i start...please.

Thanks in advance
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Introduction

[mathurin nkenfack via Bf-committers]

Hi
I am Nkenfack Tebonfack Mathurin a student at the university of Buea in
cameroon. I just join the chat channel. i am exited on how to get started
to contribute and do my very best to learn. Where do i start...please.

Thanks in advance
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction

[Ankit via Bf-committers]

Hi there, welcome!

Please find introduction to new developers at [1].
Also, at [2], you can see suggested ideas, for this year as well as older ones.
Find us on chat [3] too! 

Cheers
Ankit

[1]: https://wiki.blender.org/wiki/Developer_Intro 

[2]: https://wiki.blender.org/wiki/GSoC 
[3]: https://wiki.blender.org/wiki/Communication/Contact 




> On 12-Mar-2020, at 20:17, mathurin nkenfack via Bf-committers 
>  wrote:
> 
> Hi
> I am Nkenfack Mathurin a student at the university of Buea in Cameroon. I
> love blender and I have always been looking a platform to generate 3D and
> 2D simulations. I wish to participate to the Google Summer of Code through
> this organization.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Introduction

[mathurin nkenfack via Bf-committers]

Hi
I am Nkenfack Mathurin a student at the university of Buea in Cameroon. I
love blender and I have always been looking a platform to generate 3D and
2D simulations. I wish to participate to the Google Summer of Code through
this organization.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction

[Ton Roosendaal]

Hi,

Best entrypoint is "get involved" on blender.org . There 
you find all pointers and links.
For new developers the forums on devtalk.blender.org 
 are cool as well.

-Ton-


Ton Roosendaal  -  t...@blender.org   -   www.blender.org
Chairman Blender Foundation, Director Blender Institute
Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands

> On 26 Jul 2018, at 10:54, Durgesh Agrawal  
> wrote:
> 
> Hi! I am Durgesh Agrawal from IIT Kanpur, India. I wish to work with the
> Blender community. I will appreciate any help in getting me started. Thanks!
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Introduction

[Durgesh Agrawal]

Hi! I am Durgesh Agrawal from IIT Kanpur, India. I wish to work with the
Blender community. I will appreciate any help in getting me started. Thanks!
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction

[Jacob Merrill]

Make a build directory, run cmake, and then your build directory will have
the source in it, to to update use git pull.
On Feb 5, 2016 5:53 PM, "Menglee Guy"  wrote:

> Just wanted to say hi everyone!
>
> My name is Menglee Guy, I live in Salt Lake City, Utah.
> I am interested in contributing and this will be my first open source
> project.
>
> I have followed the instructions and have built blender on windows 10.
>
> Now, I have some newbie questions.
>
> c:\blender-git\blender is the master branch on my computer.
>
> 1. Do I modify the files here (c:\blender-git\blender\source) and check
> stuff in from here? What happens to it anyways?
>
> 2. How often do you update, (getting the latest copy from the version
> control)?
>
> Thank you for your time.
> MG
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction

[Aaron Carlisle]

> 1. Do I modify the files here (c:\blender-git\blender\source) and check
> stuff in from here? What happens to it anyways?

That is the main location of the source files. After making a change you
must recompile
to see your change. It would also be helpful for bigger changes to make in
a local branch.
If you read the getting started information, though out dated a little,
will help a lot. [1]
Another good resource is #blendercoders on IRC freenode.


> 2. How often do you update, (getting the latest copy from the version
> control)?

Blender is developed very rapidly so at least once a day depending on how
rapidly you are making your changes.

1. http://wiki.blender.org/index.php/Dev:Contents

On Fri, Feb 5, 2016 at 9:26 PM, Menglee Guy  wrote:

> Thanks for the quick reply.
> Sorry I still need a little clarification.
>
> My directory looks like this:
>
> c:\blender-git\blender (master)
> c:\blender-git\build_windows
>
> So, are you saying we work and modify the source code in the build_windows,
> then copy the changes to the master for check in?
>
> MG
>
> On Fri, Feb 5, 2016 at 7:09 PM, Jacob Merrill 
> wrote:
>
> > Make a build directory, run cmake, and then your build directory will
> have
> > the source in it, to to update use git pull.
> > On Feb 5, 2016 5:53 PM, "Menglee Guy"  wrote:
> >
> > > Just wanted to say hi everyone!
> > >
> > > My name is Menglee Guy, I live in Salt Lake City, Utah.
> > > I am interested in contributing and this will be my first open source
> > > project.
> > >
> > > I have followed the instructions and have built blender on windows 10.
> > >
> > > Now, I have some newbie questions.
> > >
> > > c:\blender-git\blender is the master branch on my computer.
> > >
> > > 1. Do I modify the files here (c:\blender-git\blender\source) and check
> > > stuff in from here? What happens to it anyways?
> > >
> > > 2. How often do you update, (getting the latest copy from the version
> > > control)?
> > >
> > > Thank you for your time.
> > > MG
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction

[Alex Fraser]

Hi Menglee,

On 6 February 2016 at 13:26, Menglee Guy  wrote:
> My directory looks like this:
>
> c:\blender-git\blender (master)
> c:\blender-git\build_windows
>
> So, are you saying we work and modify the source code in the build_windows,
> then copy the changes to the master for check in?

Make changes to the source in c:\blender-git\blender. When you build
again, your changes will automatically affect the application compiled
in c:\blender-git\build_windows.

The source code you checked out is your own local copy. Git is
decentralised, so you can check in whatever you like to your local
repository. As Aaron said, it's often better to work in a branch [1].
But you don't have to. The remote code (that everyone else sees) is in
a branch called `origin/master`. So when you have a change that you
want to contribute back to the Blender community, simply change to
`c:\blender-git\blender` and run `git diff origin/master`. That will
show you the changes that you have made [2]. You can run `git diff
origin/master > some_change.patch`; that will write the changes to the
.patch file, which you can upload to the tracker [3].

Cheers,
Alex

[1]: https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
[2]: http://wiki.blender.org/index.php/Dev:Doc/Tools/Patches
[3]: https://developer.blender.org/differential/diff/create/
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction

[Menglee Guy]

Thanks for the quick reply.
Sorry I still need a little clarification.

My directory looks like this:

c:\blender-git\blender (master)
c:\blender-git\build_windows

So, are you saying we work and modify the source code in the build_windows,
then copy the changes to the master for check in?

MG

On Fri, Feb 5, 2016 at 7:09 PM, Jacob Merrill 
wrote:

> Make a build directory, run cmake, and then your build directory will have
> the source in it, to to update use git pull.
> On Feb 5, 2016 5:53 PM, "Menglee Guy"  wrote:
>
> > Just wanted to say hi everyone!
> >
> > My name is Menglee Guy, I live in Salt Lake City, Utah.
> > I am interested in contributing and this will be my first open source
> > project.
> >
> > I have followed the instructions and have built blender on windows 10.
> >
> > Now, I have some newbie questions.
> >
> > c:\blender-git\blender is the master branch on my computer.
> >
> > 1. Do I modify the files here (c:\blender-git\blender\source) and check
> > stuff in from here? What happens to it anyways?
> >
> > 2. How often do you update, (getting the latest copy from the version
> > control)?
> >
> > Thank you for your time.
> > MG
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Introduction

[Menglee Guy]

Just wanted to say hi everyone!

My name is Menglee Guy, I live in Salt Lake City, Utah.
I am interested in contributing and this will be my first open source
project.

I have followed the instructions and have built blender on windows 10.

Now, I have some newbie questions.

c:\blender-git\blender is the master branch on my computer.

1. Do I modify the files here (c:\blender-git\blender\source) and check
stuff in from here? What happens to it anyways?

2. How often do you update, (getting the latest copy from the version
control)?

Thank you for your time.
MG
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction and CMake refactoring

[Stephen Kelly]

On 11/09/2015 09:58 AM, Martijn Berger wrote:
> Hi  Steve,
>
> Welcome,
>
> You may or may not be aware that we want to work towards making CMake
> feature complete versus our Scons buildsystem in order to facilitate
> dropping Scons.

I'm vaguely aware of it, but not very.

> You talk about modernizing but what versions of CMake would this raise our
> requirement to?

The task described above would require 3.0, but I would increase the
requirement to 3.3, because if you're going to increase it, you might as
well increase it to the latest release :).

Thanks,

Steve.


>
> Martijn
>
>
>
> On Sun, Nov 8, 2015 at 11:54 PM, Stephen Kelly  wrote:
>
>> Hello,
>>
>> Today I was on IRC just before the weekly meeting and discussed some issues
>> regarding the CMake buildsystem. We worked together on creating the issue
>>
>>  https://developer.blender.org/T46725
>>
>> Campbell Barton helped me out with a contributor account to allow me to
>> push
>> to blender-staging to implement it. I'll work together with Campbell on the
>> specifics of the task, and longer-term perhaps work on modernising the
>> CMake
>> buildsystem in a larger way. If you have any questions about T46725, feel
>> free to ask. I am subscribed to the mailing list.
>>
>> For the last 4 years I've been working in mostly personal time on upstream
>> CMake, shifting it towards interfaces which are target scoped (eg commands
>> like target_include_directories) instead of directory scoped (eg, commands
>> like include_directories, which affect all targets in a directory), and
>> implementing usage-requirements to make it easier to define and maintain
>> buildsystems with many dependent targets.
>>
>> For the last 6 years, I've been the maintainer of the Qt model-view
>> framework and the Qt CMake integration. I've touched many parts of Qt
>> through my previous job where I worked as a Qt consultant. For some years
>> prior to and during that time I was also active in KDE, in particular
>> KDEPIM
>> and kdelibs (now KDE Frameworks).
>>
>> I'm very familiar with git, mailing lists, reviews, cmake and C++ (and
>> python, like everyone :) ), but I have quite some learning to do regarding
>> phabricator, opengl, and 3d modelling generally, so those are the topics
>> I'm
>> likely to be asking about on IRC.
>>
>> I've been interested in blender for some time because I would like to learn
>> more about 3d. I expect the buildsystem work will give me the excuse to
>> explore the codebase, and then I hope to dig into the interesting features
>> of blender.
>>
>>  https://developer.blender.org/p/steveire/
>>
>> Hello!
>>
>> Steve.
>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction and CMake refactoring

[Sergey Sharybin]

Hi,

Maybe i'm missing something, but main concern about current state oc CMake
is a tedios process of manually maintaining order of libraries. This is a
walid point, but how's the proposed change will solve the issue? It seems
to be just more a conditional add of libraries to the linking list?

On Mon, Nov 9, 2015 at 1:58 PM, Martijn Berger 
wrote:

> Hi  Steve,
>
> Welcome,
>
> You may or may not be aware that we want to work towards making CMake
> feature complete versus our Scons buildsystem in order to facilitate
> dropping Scons.
>
> You talk about modernizing but what versions of CMake would this raise our
> requirement to?
>
> Martijn
>
>
>
> On Sun, Nov 8, 2015 at 11:54 PM, Stephen Kelly  wrote:
>
> > Hello,
> >
> > Today I was on IRC just before the weekly meeting and discussed some
> issues
> > regarding the CMake buildsystem. We worked together on creating the issue
> >
> >  https://developer.blender.org/T46725
> >
> > Campbell Barton helped me out with a contributor account to allow me to
> > push
> > to blender-staging to implement it. I'll work together with Campbell on
> the
> > specifics of the task, and longer-term perhaps work on modernising the
> > CMake
> > buildsystem in a larger way. If you have any questions about T46725, feel
> > free to ask. I am subscribed to the mailing list.
> >
> > For the last 4 years I've been working in mostly personal time on
> upstream
> > CMake, shifting it towards interfaces which are target scoped (eg
> commands
> > like target_include_directories) instead of directory scoped (eg,
> commands
> > like include_directories, which affect all targets in a directory), and
> > implementing usage-requirements to make it easier to define and maintain
> > buildsystems with many dependent targets.
> >
> > For the last 6 years, I've been the maintainer of the Qt model-view
> > framework and the Qt CMake integration. I've touched many parts of Qt
> > through my previous job where I worked as a Qt consultant. For some years
> > prior to and during that time I was also active in KDE, in particular
> > KDEPIM
> > and kdelibs (now KDE Frameworks).
> >
> > I'm very familiar with git, mailing lists, reviews, cmake and C++ (and
> > python, like everyone :) ), but I have quite some learning to do
> regarding
> > phabricator, opengl, and 3d modelling generally, so those are the topics
> > I'm
> > likely to be asking about on IRC.
> >
> > I've been interested in blender for some time because I would like to
> learn
> > more about 3d. I expect the buildsystem work will give me the excuse to
> > explore the codebase, and then I hope to dig into the interesting
> features
> > of blender.
> >
> >  https://developer.blender.org/p/steveire/
> >
> > Hello!
> >
> > Steve.
> >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction and CMake refactoring

[Martijn Berger]

Hi  Steve,

Welcome,

You may or may not be aware that we want to work towards making CMake
feature complete versus our Scons buildsystem in order to facilitate
dropping Scons.

You talk about modernizing but what versions of CMake would this raise our
requirement to?

Martijn



On Sun, Nov 8, 2015 at 11:54 PM, Stephen Kelly  wrote:

> Hello,
>
> Today I was on IRC just before the weekly meeting and discussed some issues
> regarding the CMake buildsystem. We worked together on creating the issue
>
>  https://developer.blender.org/T46725
>
> Campbell Barton helped me out with a contributor account to allow me to
> push
> to blender-staging to implement it. I'll work together with Campbell on the
> specifics of the task, and longer-term perhaps work on modernising the
> CMake
> buildsystem in a larger way. If you have any questions about T46725, feel
> free to ask. I am subscribed to the mailing list.
>
> For the last 4 years I've been working in mostly personal time on upstream
> CMake, shifting it towards interfaces which are target scoped (eg commands
> like target_include_directories) instead of directory scoped (eg, commands
> like include_directories, which affect all targets in a directory), and
> implementing usage-requirements to make it easier to define and maintain
> buildsystems with many dependent targets.
>
> For the last 6 years, I've been the maintainer of the Qt model-view
> framework and the Qt CMake integration. I've touched many parts of Qt
> through my previous job where I worked as a Qt consultant. For some years
> prior to and during that time I was also active in KDE, in particular
> KDEPIM
> and kdelibs (now KDE Frameworks).
>
> I'm very familiar with git, mailing lists, reviews, cmake and C++ (and
> python, like everyone :) ), but I have quite some learning to do regarding
> phabricator, opengl, and 3d modelling generally, so those are the topics
> I'm
> likely to be asking about on IRC.
>
> I've been interested in blender for some time because I would like to learn
> more about 3d. I expect the buildsystem work will give me the excuse to
> explore the codebase, and then I hope to dig into the interesting features
> of blender.
>
>  https://developer.blender.org/p/steveire/
>
> Hello!
>
> Steve.
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction and CMake refactoring

[Campbell Barton]

On Mon, Nov 9, 2015 at 10:16 PM, Sergey Sharybin  wrote:
> Hi,
>
> Maybe i'm missing something, but main concern about current state oc CMake
> is a tedios process of manually maintaining order of libraries. This is a
> walid point, but how's the proposed change will solve the issue? It seems
> to be just more a conditional add of libraries to the linking list?

Typically CMake projects define library dependencies, however we
couldn't use this because some libraries linked to the stub for the
blenderplayer (the same library had different dependencies for
blender/blenderplayer).

If we use conditional linking theres no need to have BLENDER_SORTED_LIBS,
the handful of  libraries using stubs can check the target when
specifying their deps.

> On Mon, Nov 9, 2015 at 1:58 PM, Martijn Berger 
> wrote:
>
>> Hi  Steve,
>>
>> Welcome,
>>
>> You may or may not be aware that we want to work towards making CMake
>> feature complete versus our Scons buildsystem in order to facilitate
>> dropping Scons.
>>
>> You talk about modernizing but what versions of CMake would this raise our
>> requirement to?
>>
>> Martijn
>>
>>
>>
>> On Sun, Nov 8, 2015 at 11:54 PM, Stephen Kelly  wrote:
>>
>> > Hello,
>> >
>> > Today I was on IRC just before the weekly meeting and discussed some
>> issues
>> > regarding the CMake buildsystem. We worked together on creating the issue
>> >
>> >  https://developer.blender.org/T46725
>> >
>> > Campbell Barton helped me out with a contributor account to allow me to
>> > push
>> > to blender-staging to implement it. I'll work together with Campbell on
>> the
>> > specifics of the task, and longer-term perhaps work on modernising the
>> > CMake
>> > buildsystem in a larger way. If you have any questions about T46725, feel
>> > free to ask. I am subscribed to the mailing list.
>> >
>> > For the last 4 years I've been working in mostly personal time on
>> upstream
>> > CMake, shifting it towards interfaces which are target scoped (eg
>> commands
>> > like target_include_directories) instead of directory scoped (eg,
>> commands
>> > like include_directories, which affect all targets in a directory), and
>> > implementing usage-requirements to make it easier to define and maintain
>> > buildsystems with many dependent targets.
>> >
>> > For the last 6 years, I've been the maintainer of the Qt model-view
>> > framework and the Qt CMake integration. I've touched many parts of Qt
>> > through my previous job where I worked as a Qt consultant. For some years
>> > prior to and during that time I was also active in KDE, in particular
>> > KDEPIM
>> > and kdelibs (now KDE Frameworks).
>> >
>> > I'm very familiar with git, mailing lists, reviews, cmake and C++ (and
>> > python, like everyone :) ), but I have quite some learning to do
>> regarding
>> > phabricator, opengl, and 3d modelling generally, so those are the topics
>> > I'm
>> > likely to be asking about on IRC.
>> >
>> > I've been interested in blender for some time because I would like to
>> learn
>> > more about 3d. I expect the buildsystem work will give me the excuse to
>> > explore the codebase, and then I hope to dig into the interesting
>> features
>> > of blender.
>> >
>> >  https://developer.blender.org/p/steveire/
>> >
>> > Hello!
>> >
>> > Steve.
>> >
>> > ___
>> > Bf-committers mailing list
>> > Bf-committers@blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>> >
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>
>
> --
> With best regards, Sergey Sharybin
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Introduction and CMake refactoring

[Stephen Kelly]

Hello,

Today I was on IRC just before the weekly meeting and discussed some issues
regarding the CMake buildsystem. We worked together on creating the issue

 https://developer.blender.org/T46725

Campbell Barton helped me out with a contributor account to allow me to
push
to blender-staging to implement it. I'll work together with Campbell on the
specifics of the task, and longer-term perhaps work on modernising the
CMake
buildsystem in a larger way. If you have any questions about T46725, feel
free to ask. I am subscribed to the mailing list.

For the last 4 years I've been working in mostly personal time on upstream
CMake, shifting it towards interfaces which are target scoped (eg commands
like target_include_directories) instead of directory scoped (eg, commands
like include_directories, which affect all targets in a directory), and
implementing usage-requirements to make it easier to define and maintain
buildsystems with many dependent targets.

For the last 6 years, I've been the maintainer of the Qt model-view
framework and the Qt CMake integration. I've touched many parts of Qt
through my previous job where I worked as a Qt consultant. For some years
prior to and during that time I was also active in KDE, in particular
KDEPIM
and kdelibs (now KDE Frameworks).

I'm very familiar with git, mailing lists, reviews, cmake and C++ (and
python, like everyone :) ), but I have quite some learning to do regarding
phabricator, opengl, and 3d modelling generally, so those are the topics
I'm
likely to be asking about on IRC.

I've been interested in blender for some time because I would like to learn
more about 3d. I expect the buildsystem work will give me the excuse to
explore the codebase, and then I hope to dig into the interesting features
of blender.

 https://developer.blender.org/p/steveire/

Hello!

Steve.

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction + Help

[Tom M]

Hi,

looks like your email got overlooked, you can have a look at our quick
hacks page

http://wiki.blender.org/index.php/Dev:Doc/Quick_Hacks

We also have a todo tracker that has things that developers plan to
get to, but items don't always get closed, so you might want to double
check before starting on one that it hasn't arleady been done.

https://projects.blender.org/tracker/?atid=264group_id=9func=browse

You can also pop into irc.freenode.net and ask to be given a bug,
which will reduce the odds that someone else will be working on it at
the same time.

LetterRip


On Tue, Oct 29, 2013 at 1:35 AM, Gurjot Singh bhattigur...@gmail.com wrote:
 Hi,
 I am Gurjot Singh Bhatti from India. I'm currently doing my Computer
 Science Engineering (B.Tech 3rd Year).
 Recently I came across this amazing piece of software Blender. Well
 its the 'Love at First Sight'. :D
 I never thought any open source software could even compete with all
 those expensive proprietary softwares that claim to be the best. I
 think I under-estimated the power of open source community. Since I've
 always been interested in 3D Animations and Games this software is a
 blessing. And I'm seriously amazed at its level of production.
 And I'd love to be the part of this community as a developer.

 I've built the Blender and I was going through the bug lists. It seems
 those bugs are solved pretty fast by all the experts here like Brecht
 Van Lommel, and Campbell Barton.
 I don't know from where should I start first?
 Is there any particular task I should follow or what?
 Any kind of help or tip would be appreciated. :)

 --
 Gurjot Singh
 Blog: http://bhattigurjot.wordpress.com
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction + Help

[Gurjot Singh]

On 5 November 2013 07:12, Tom M letter...@gmail.com wrote:
 Hi,

 looks like your email got overlooked, you can have a look at our quick
 hacks page

 http://wiki.blender.org/index.php/Dev:Doc/Quick_Hacks

Hi, thanks for replying.
Actually Mr.Campbell Barton did replied but it was a PM.

 We also have a todo tracker that has things that developers plan to
 get to, but items don't always get closed, so you might want to double
 check before starting on one that it hasn't arleady been done.

 https://projects.blender.org/tracker/?atid=264group_id=9func=browse

 You can also pop into irc.freenode.net and ask to be given a bug,
 which will reduce the odds that someone else will be working on it at
 the same time.

Sure, I'll look forward to it. :)

-- 
Gurjot Singh
Blog: http://bhattigurjot.wordpress.com
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction + Help

[Campbell Barton]

Was trying to avoid too much noise on the list so I linked to a
similar recent question on the list,
of course then it looks like nobody replied.

On Tue, Nov 5, 2013 at 4:02 PM, Gurjot Singh bhattigur...@gmail.com wrote:
 On 5 November 2013 07:12, Tom M letter...@gmail.com wrote:
 Hi,

 looks like your email got overlooked, you can have a look at our quick
 hacks page

 http://wiki.blender.org/index.php/Dev:Doc/Quick_Hacks

 Hi, thanks for replying.
 Actually Mr.Campbell Barton did replied but it was a PM.

 We also have a todo tracker that has things that developers plan to
 get to, but items don't always get closed, so you might want to double
 check before starting on one that it hasn't arleady been done.

 https://projects.blender.org/tracker/?atid=264group_id=9func=browse

 You can also pop into irc.freenode.net and ask to be given a bug,
 which will reduce the odds that someone else will be working on it at
 the same time.

 Sure, I'll look forward to it. :)

 --
 Gurjot Singh
 Blog: http://bhattigurjot.wordpress.com
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Introduction

[Benjy Cook]

Hello,
My name is Benjy Cook, I'm a long time Blender user and avid programmer. I am 
currently a student at Tel Aviv University, majoring in Computer Science and 
Film.I recently subscribed to this list to get a closer look at the 
behind-the-scenes of Blender programming and how that effort operates.I hope to 
take an active role and help develop this awesome piece of software.I am fluent 
in Python, and coded many different scripts in Blender, mostly via the 
Game-engine. I am also familiar with C.Just wanted to take this opportunity to 
say hello and introduce myself to the list.
Cheers, Benjy.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction

[raulf]

Hello Benjy

You're wellcome, being a Blender developer is a joy and a pleasure that
will fill you, you will see ;)

Cheers
Farsthary


 Hello,
 My name is Benjy Cook, I'm a long time Blender user and avid programmer. I
 am currently a student at Tel Aviv University, majoring in Computer
 Science and Film.I recently subscribed to this list to get a closer look
 at the behind-the-scenes of Blender programming and how that effort
 operates.I hope to take an active role and help develop this awesome piece
 of software.I am fluent in Python, and coded many different scripts in
 Blender, mostly via the Game-engine. I am also familiar with C.Just wanted
 to take this opportunity to say hello and introduce myself to the list.
 Cheers, Benjy.
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers



___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction

[Mitchell Stokes]

Hi Benjy!

If you're interested in doing some BGE development, come find me in the
#blendercoders IRC channel on freenode. I can help you start to figure out
the source code. :)

Cheers,
Mitchell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction

[Nathan Letwory]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9.3.2011 9:30, Daniel Tavares wrote:
 Hi everyone,
 
 My name is Daniel Tavares and I'm a software engineer with six plus years of
 professional software development experience, including three years working
 on a triple-A MMO. I have experience with C++, Python, cmake, and git. I'm
 interested in multi-platform projects and I am comfortable working in
 Windows, OS X and Linux.

Sounds like a nice list :)

 
 I have been following bf-committers ml for a while and would like to
 contribute to the community. I understand that there's a goal of getting a
 new release by the end of the month, so I would like to know which areas
 need an extra hand. I'm also interested in helping improve the COLLADA
 support, so anyone out there currently working on this, feel free to drop me
 a line and give me some pointers on the latest events.

I'd be happy to have you on our COLLADA efforts. I've started creating a
roadmap-like page in our wiki here
http://wiki.blender.org/index.php/Dev:2.5/Source/Architecture/COLLADA .
There are also still issues that are marked as TODO in our tracker (
http://projects.blender.org/tracker/?atid=498group_id=9func=browse and
http://projects.blender.org/tracker/?atid=264group_id=9func=browse )
and some of them are on our todo list on the wiki
http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Simple_Todos#COLLADA

If you're IRC-compliant, do join #blendercollada on the freenode.net
network. You'll find me there as jesterKing (or amino, when not present).

Welcome!

/Nathan

- -- 
Nathan Letwory
Letwory Interactive | Studio Lumikuu
http://www.letworyinteractive.com | http://www.lumikuu.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNd5StAAoJEKtfN7KsE0TtEcAH/itMGSYeMhCb+ORcJMY81Hn8
VAhznfKxcpky8ZX6v1VNZId0XjTHt+lyMr58MrHmBhBZ5WvIFHEoPxn6qmEfPjji
rqztDE4V9NeGtDFIRdcz+ZUeXBPV8DpRdox8yviJuqpKmShfe9cEYf/4+CxoxcCN
eGhzAS0Pnzti4Ez6TpYZU43h7nOWoYhv4y98jE1vGkExkavB976QVihsjCbBnKb6
sh3l2WStPZzeaCTSpNDR866D0vLqpqj5ITwdh5364NZMoE+GVyUeSRvtm/r6MXkY
6zbvMBKa0hlaMsN7umqoL3qFWewOzKv+DsawVLWRq+1shbFq207sFqLjMSDiIDg=
=BgWz
-END PGP SIGNATURE-
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction

[Tom M]

On Tue, Mar 8, 2011 at 10:30 PM, Daniel Tavares
danielmtava...@gmail.com wrote:
 Hi everyone,

 My name is Daniel Tavares

Welcome Daniel.


 I understand that there's a goal of getting a
 new release by the end of the month, so I would like to know which areas
 need an extra hand. I'm also interested in helping improve the COLLADA
 support, so anyone out there currently working on this, feel free to drop me
 a line and give me some pointers on the latest events.


Excellent,

Nathan has already responded on this.  I suspect diving into Collada
would be your best bet.

Tom M.
LetterRip

 Cheers,

 Daniel Tavares
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Introduction and Request

[Juan Linietsky]

Hi! My name is Juan Linietsky and I work as consultant for many game
development studios. Usually, I provide tools, technology and support to
them as part of my job.
I noticed that more and more artists in studios are pushing for Blender as
an alternative to commercial tools such as 3DS max, both because it's free
and they really love the tool.
However, Blender still has a huge drawback in game development, which is the
very poor Collada support. I have no doubts that the support in 2.5 series
improved, but even though the artists i work with are very enthusiastic,
support is still not at the same level they find in autodesk software using
OpenCollada or ColladaMaya.

I may have to start working on a Playstation 3 project with a company soon
that will requiere them to use almost all the functionality present in
Collada (like skinning, morphing, animation, etc), and the artists would
really like to use Blender 2.5 and contribute to test it and use it in a
real world scenario. I'm sure that they can provide very valuable testing
and feedback to Blender 2.5 development and help make Collada support very
solid. However, I'd really like to know if I can count on the Blender
development community to receive feedback and help fix the issues that will
arise in this real-world-usage scenario of Blender 2.5.

Cheers!

Juan Linietsky
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] introduction

[Campbell Barton]

On Thu, Jun 3, 2010 at 8:07 PM, Campbell Barton ideasma...@gmail.com wrote:
 On Thu, Jun 3, 2010 at 7:16 PM, Ian Watkins watkin...@gmail.com wrote:
 On Thu, Jun 3, 2010 at 11:12 AM, Campbell Barton ideasma...@gmail.com 
 wrote:
 Hi Ian,

 * re: compiler warnings, I compile with CMake on linux which uses:
  -Wall -Wno-char-subscripts -Wpointer-arith -Wcast-align
 -Wdeclaration-after-statement -Wno-unknown-pragmas
 -Wno-char-subscripts

 This removes warnings which in my experience can be ignored, a few
 times I tried to get blender to build with less warnings (when
 omitting some of the flags above), but found it mostly useless.
 There are libraries like bullet which is really an external project so
 we try not to modify its source, and other cases in the game engine
 where there is no easy way to fix the warning.
 So even if you get 1000's of warnings (with only -Wall for instance),
 I have found its not that easy to simply go in and 'fix' many of them.

 I've run blenders code through cppcheck, splint, clangs error checker.
 We also had coverity run scans on blenders source though that was on
 2.4x a while ago.

 nevertheless, fix warnings you find when building blender is a fine
 place  to start.

 My experience is that if you ignore warnings, they just grow --
 masking problems one should probably look at.  Additionally, that path
 can lead to people caring less about warnings than they should.
 Granted, some warnings are innocuous -- but those are typically easy
 to fix.

 When working with a large group of people, it seems like an absolute
 policy serves everyone the best.

 As an example, when I write code, I tend to throw -Wall -Wextra
 -Werror and make sure it keeps building.  When someone adding feature
 to such a codebase has an issue, it is because their code is
 (arguably) broken.

 In other words, zero warnings in (when I checked out the code) leads
 to zero warnings out (when I commit my code back to the central
 repository).  Otherwise, how do I know if I added warnings or not?

 Just my experience.  I acknowledge that this is possibly a waste of
 time, but I'm getting several things out of it, while the rest of you
 are getting (hopefully) fewer warnings.  Seems like a good trade all
 around.

 Agree that fixing warnings is important, periodically we go over and
 cleanup warnings, I'd not say that the warnings in blender are growing
 and growing.

 Heres a log of warnings from compiling on 64bit linux, gcc 4.4.3
 svn r29188: http://www.pasteall.org/13554
 ignoring bullet, there are around ~90.

 At one point I spent some time to try and have -Werror default but
 wasn't able to remove implicit declaration gzopen64, Brecht also
 tried to get this working and wasn't able to.

 If we can resolve this I'd be OK with using -Werror, at least for a
 while and see if its acceptable with our mixed developer base.

Correction, Brecht fixed the gzopen64 problem r21082, so with GCC at
least we could try -Werror, though with people building on different
OS's and compiler versions I'd want to avoid frequent small breakages.

 * re: memory management.
 We have guarded alloc, which can help track leaks based on a string ID
 for each alloc, however it could be interesting to replace the
 allocator.
 AFAIK the only thing which makes this tricky MEM_allocN_len() which
 returns the length of allocated memory. this is only used in a few
 places so I think its use could be removed and we could swap out
 guarded alloc altogether, for testing/benchmarking.

 pretty much every allocator I've looked at can trivially add a similar
 interface, with only jemalloc not being able to do it in O(1).
 Generally, I've considered such an interface a debug extension.  What
 is this used for in the code?  Offhand, I can only think of trying to
 avoid growing a buffer with realloc, or, alternately, avoiding buffer
 overruns.  I'll grep through the code and see what's going on, I
 guess.


 * re: plugin system. really important to get this right for 2.5, have
 discussed with Brecht and Ton a little, research in this area is
 useful but not sure its a good first project since we need to consider
 how the rna api might fit in with texture, sequencer plugins and
 possible compositor and shader plugins too.

 Of your suggestions I think parallel code is a good place to start if
 you have experience with this in previous projects.
 You could take some area of blender which is self contained and
 optimize it without having to understand lots of different parts of
 blender at once.

 I haven't used GIT yet though I'd like to try [...]

 One of us... One of us

 --
 --Ian
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers




 --
 - Campbell




-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] introduction

[Nicholas Bishop]

I'd rather not build with -Werror by default; while coding I often
make quick changes that throw a few harmless warnings, then fix those
things up before I commit. For example, I might temporarily declare
some new variables in the middle of code, which is technically a
no-no, but gcc doesn't actually care other than to print a warning.

If we somehow set up a commit script that rejected commits that add
warnings to the build, that might be OK, but for normal development I
think it'd be irritating.

-Nicholas

On Fri, Jun 4, 2010 at 3:02 AM, Campbell Barton ideasma...@gmail.com wrote:
 On Thu, Jun 3, 2010 at 8:07 PM, Campbell Barton ideasma...@gmail.com wrote:
 On Thu, Jun 3, 2010 at 7:16 PM, Ian Watkins watkin...@gmail.com wrote:
 On Thu, Jun 3, 2010 at 11:12 AM, Campbell Barton ideasma...@gmail.com 
 wrote:
 Hi Ian,

 * re: compiler warnings, I compile with CMake on linux which uses:
  -Wall -Wno-char-subscripts -Wpointer-arith -Wcast-align
 -Wdeclaration-after-statement -Wno-unknown-pragmas
 -Wno-char-subscripts

 This removes warnings which in my experience can be ignored, a few
 times I tried to get blender to build with less warnings (when
 omitting some of the flags above), but found it mostly useless.
 There are libraries like bullet which is really an external project so
 we try not to modify its source, and other cases in the game engine
 where there is no easy way to fix the warning.
 So even if you get 1000's of warnings (with only -Wall for instance),
 I have found its not that easy to simply go in and 'fix' many of them.

 I've run blenders code through cppcheck, splint, clangs error checker.
 We also had coverity run scans on blenders source though that was on
 2.4x a while ago.

 nevertheless, fix warnings you find when building blender is a fine
 place  to start.

 My experience is that if you ignore warnings, they just grow --
 masking problems one should probably look at.  Additionally, that path
 can lead to people caring less about warnings than they should.
 Granted, some warnings are innocuous -- but those are typically easy
 to fix.

 When working with a large group of people, it seems like an absolute
 policy serves everyone the best.

 As an example, when I write code, I tend to throw -Wall -Wextra
 -Werror and make sure it keeps building.  When someone adding feature
 to such a codebase has an issue, it is because their code is
 (arguably) broken.

 In other words, zero warnings in (when I checked out the code) leads
 to zero warnings out (when I commit my code back to the central
 repository).  Otherwise, how do I know if I added warnings or not?

 Just my experience.  I acknowledge that this is possibly a waste of
 time, but I'm getting several things out of it, while the rest of you
 are getting (hopefully) fewer warnings.  Seems like a good trade all
 around.

 Agree that fixing warnings is important, periodically we go over and
 cleanup warnings, I'd not say that the warnings in blender are growing
 and growing.

 Heres a log of warnings from compiling on 64bit linux, gcc 4.4.3
 svn r29188: http://www.pasteall.org/13554
 ignoring bullet, there are around ~90.

 At one point I spent some time to try and have -Werror default but
 wasn't able to remove implicit declaration gzopen64, Brecht also
 tried to get this working and wasn't able to.

 If we can resolve this I'd be OK with using -Werror, at least for a
 while and see if its acceptable with our mixed developer base.

 Correction, Brecht fixed the gzopen64 problem r21082, so with GCC at
 least we could try -Werror, though with people building on different
 OS's and compiler versions I'd want to avoid frequent small breakages.

 * re: memory management.
 We have guarded alloc, which can help track leaks based on a string ID
 for each alloc, however it could be interesting to replace the
 allocator.
 AFAIK the only thing which makes this tricky MEM_allocN_len() which
 returns the length of allocated memory. this is only used in a few
 places so I think its use could be removed and we could swap out
 guarded alloc altogether, for testing/benchmarking.

 pretty much every allocator I've looked at can trivially add a similar
 interface, with only jemalloc not being able to do it in O(1).
 Generally, I've considered such an interface a debug extension.  What
 is this used for in the code?  Offhand, I can only think of trying to
 avoid growing a buffer with realloc, or, alternately, avoiding buffer
 overruns.  I'll grep through the code and see what's going on, I
 guess.


 * re: plugin system. really important to get this right for 2.5, have
 discussed with Brecht and Ton a little, research in this area is
 useful but not sure its a good first project since we need to consider
 how the rna api might fit in with texture, sequencer plugins and
 possible compositor and shader plugins too.

 Of your suggestions I think parallel code is a good place to start if
 you have experience with this in previous projects.
 You could take some 

[Bf-committers] introduction

[Ian Watkins]

Hello all,

I imagine everyone is quite busy, so I'll attempt to be brief.

I recently decided to contribute time to an open source project.  I've
had a passion for movies and an interest in animation for most of my
life -- so blender seems like the logical place to spend time.  I'm an
openGL novice -- I know enough to be dangerous, basically, but I've
been working as a software engineer for the past 8 years.

I've worked in embedded systems for 5 years, where I've written a
memory allocator, improved the distributed build system, and worked on
a number of other projects...  I know c, c++, perl, python, java,
bash/sh shell scripting, autotools, make, and more.

I've been looking for details on what areas need help in blender
development, but haven't found many details.

Short term, I plan on reducing/eliminating compiler warnings (if they
exist) -- mainly to start to get an idea of how things work.

Is there a coding style for blender?

As for features/fixes I'd like to explore the following (assuming 2.5
hasn't addressed these issues -- this is based off of 30 mins of
playing with 2.45).

* When collapsing tools, have the entire name of the section rendered
on the vertical bar.
* More configurable UI -- essentially, allow an area to be dragged out
of its doc, and placed in a new window (I have a huge 2 monitor setup,
and it would be nice to be able to have a full screen view of what is
being worked on, or have 2 views near full screen).
* plugin system.  pretty sure there isn't much work here, but I'd like
to be able to load a new plugin while blender is running (alternately,
update a plugin).  The plugin should provide menu items, tool tips,
etc. on load and the UI should be updated accordingly.
* Memory management tools.  Ability to query the allocator about in
flight data, who allocated it, etc.
* parallel code.  I have experience with chromium, MPI, threads, and IPC.

Mainly, though, I'm hoping to learn, and hoping that I'll be able to
teach a little as well.

Lastly, have you guys used git at all?  With the many branches you've
made for SOC, and the commit policy, I'd think you guys would love
distributed source code management -- along with the ability to merge
less painfully.

And I've failed miserably at being brief.  Apologies.
-- 
--Ian
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] introduction

[Nathan Letwory]

On 3.6.2010 17:13, Ian Watkins wrote:
 Hello all,


Hi Ian and welcome to the list and to Blender development in general.


 I recently decided to contribute time to an open source project.  I've
 had a passion for movies and an interest in animation for most of my
 life -- so blender seems like the logical place to spend time.  I'm an
 openGL novice -- I know enough to be dangerous, basically, but I've
 been working as a software engineer for the past 8 years.


Nice, always fun to get more interested souls in the gang.

 I've worked in embedded systems for 5 years, where I've written a
 memory allocator, improved the distributed build system, and worked on
 a number of other projects...  I know c, c++, perl, python, java,
 bash/sh shell scripting, autotools, make, and more.


C, C++ and Python are what you'll need mostly :) I use our scons 
implementation most when building Blender (having written it maybe not 
surprising ;)

 I've been looking for details on what areas need help in blender
 development, but haven't found many details.


Some todo list can be found here: 
http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo

 Short term, I plan on reducing/eliminating compiler warnings (if they
 exist) -- mainly to start to get an idea of how things work.

You'll find compiler warnings by the thousands probably :)

 Is there a coding style for blender?


Not really, but do checkout the code in core - that's what we mostly 
use. In general: don't mess with the style in an existing file. Do what 
is in that file.

 * When collapsing tools, have the entire name of the section rendered
 on the vertical bar.


 * More configurable UI -- essentially, allow an area to be dragged out
 of its doc, and placed in a new window (I have a huge 2 monitor setup,
 and it would be nice to be able to have a full screen view of what is
 being worked on, or have 2 views near full screen).

You can create new windows from areas in Blender 2.5 (current trunk). 
Hold shift and with RMB pressed drag one of the corner triangles into 
the area you want to duplicate into a new window. Area management has 
been improved since 2.4x.

Entire window duplication is possible too.

 * plugin system.  pretty sure there isn't much work here, but I'd like
 to be able to load a new plugin while blender is running (alternately,
 update a plugin).  The plugin should provide menu items, tool tips,
 etc. on load and the UI should be updated accordingly.

Currently Blender 2.5 has a much more advanced Python integration that 
will help you do most of your extension needs. That said, I think it 
might be nice to have a better plugin system for some parts like 
textures (there's already plugins for that, dunno if that also still 
works in 2.5), but I can imagine that for instance for nodes it would be 
nice.
 * Memory management tools.  Ability to query the allocator about in
 flight data, who allocated it, etc.

I think guardedalloc already can give you that kind of info.
 Lastly, have you guys used git at all?  With the many branches you've
 made for SOC, and the commit policy, I'd think you guys would love
 distributed source code management -- along with the ability to merge
 less painfully.


No. I try to sync trunk to gitorious.org/blenderprojects though. And I 
don't think that a change of SCM will be done anytime soon. SVN has 
served us well enough and after a big CVS-SVN transition I don't think 
most of the users are longing for yet another one. Personally I'd like 
Git though.

 And I've failed miserably at being brief.  Apologies.


Don't worry about that :)

Anyway, feel free to ask more, check out the docs on wiki and join 
#blendercoders to ask for live help. You'll find me with the nick jesterKing

/Nathan

-- 
Nathan Letwory
Letwory Interactive
http://www.letworyinteractive.com

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] introduction

[Campbell Barton]

Hi Ian,

* re: compiler warnings, I compile with CMake on linux which uses:
 -Wall -Wno-char-subscripts -Wpointer-arith -Wcast-align
-Wdeclaration-after-statement -Wno-unknown-pragmas
-Wno-char-subscripts

This removes warnings which in my experience can be ignored, a few
times I tried to get blender to build with less warnings (when
omitting some of the flags above), but found it mostly useless.
There are libraries like bullet which is really an external project so
we try not to modify its source, and other cases in the game engine
where there is no easy way to fix the warning.
So even if you get 1000's of warnings (with only -Wall for instance),
I have found its not that easy to simply go in and 'fix' many of them.

I've run blenders code through cppcheck, splint, clangs error checker.
We also had coverity run scans on blenders source though that was on
2.4x a while ago.

nevertheless, fix warnings you find when building blender is a fine
place  to start.

* re: memory management.
We have guarded alloc, which can help track leaks based on a string ID
for each alloc, however it could be interesting to replace the
allocator.
AFAIK the only thing which makes this tricky MEM_allocN_len() which
returns the length of allocated memory. this is only used in a few
places so I think its use could be removed and we could swap out
guarded alloc altogether, for testing/benchmarking.

* re: plugin system. really important to get this right for 2.5, have
discussed with Brecht and Ton a little, research in this area is
useful but not sure its a good first project since we need to consider
how the rna api might fit in with texture, sequencer plugins and
possible compositor and shader plugins too.

Of your suggestions I think parallel code is a good place to start if
you have experience with this in previous projects.
You could take some area of blender which is self contained and
optimize it without having to understand lots of different parts of
blender at once.

I haven't used GIT yet though I'd like to try, however I'm not sure
we're developing at a scale where subversion limits us in the way it
would the linux kernel for eg.

- Campbell

On Thu, Jun 3, 2010 at 4:13 PM, Ian Watkins watkin...@gmail.com wrote:
 Hello all,

 I imagine everyone is quite busy, so I'll attempt to be brief.

 I recently decided to contribute time to an open source project.  I've
 had a passion for movies and an interest in animation for most of my
 life -- so blender seems like the logical place to spend time.  I'm an
 openGL novice -- I know enough to be dangerous, basically, but I've
 been working as a software engineer for the past 8 years.

 I've worked in embedded systems for 5 years, where I've written a
 memory allocator, improved the distributed build system, and worked on
 a number of other projects...  I know c, c++, perl, python, java,
 bash/sh shell scripting, autotools, make, and more.

 I've been looking for details on what areas need help in blender
 development, but haven't found many details.

 Short term, I plan on reducing/eliminating compiler warnings (if they
 exist) -- mainly to start to get an idea of how things work.

 Is there a coding style for blender?

 As for features/fixes I'd like to explore the following (assuming 2.5
 hasn't addressed these issues -- this is based off of 30 mins of
 playing with 2.45).

 * When collapsing tools, have the entire name of the section rendered
 on the vertical bar.
 * More configurable UI -- essentially, allow an area to be dragged out
 of its doc, and placed in a new window (I have a huge 2 monitor setup,
 and it would be nice to be able to have a full screen view of what is
 being worked on, or have 2 views near full screen).
 * plugin system.  pretty sure there isn't much work here, but I'd like
 to be able to load a new plugin while blender is running (alternately,
 update a plugin).  The plugin should provide menu items, tool tips,
 etc. on load and the UI should be updated accordingly.
 * Memory management tools.  Ability to query the allocator about in
 flight data, who allocated it, etc.
 * parallel code.  I have experience with chromium, MPI, threads, and IPC.

 Mainly, though, I'm hoping to learn, and hoping that I'll be able to
 teach a little as well.

 Lastly, have you guys used git at all?  With the many branches you've
 made for SOC, and the commit policy, I'd think you guys would love
 distributed source code management -- along with the ability to merge
 less painfully.

 And I've failed miserably at being brief.  Apologies.
 --
 --Ian
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers




-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] introduction

[Michael McLay]

On Thu, Jun 3, 2010 at 10:29 AM, Nathan Letwory 
nat...@letworyinteractive.com wrote:

 On 3.6.2010 17:13, Ian Watkins wrote: Lastly, have you guys used git at
 all?  With the many branches you've
  made for SOC, and the commit policy, I'd think you guys would love
  distributed source code management -- along with the ability to merge
  less painfully.
 

 No. I try to sync trunk to gitorious.org/blenderprojects though. And I
 don't think that a change of SCM will be done anytime soon. SVN has
 served us well enough and after a big CVS-SVN transition I don't think
 most of the users are longing for yet another one. Personally I'd like
 Git though.


I hope the Blender team is open to suggestions about how to improve the
project management activities. I agree with Ian that moving to a distribute
source code management tools has advantages. Merging is one of them. Another
is the ability to checkin to a branch when you are offline and then later
push the commits to the local copy of the branch back into the branch in a
central repository. The choice between Git, Bazaar, or Mercurial is a matter
of taste more than a matter of features.

A higher level discussion might also reconsider the choice of gforge. I
believe there is some disastifaction with gforge and alternatives have been
suggested. I don't recall the name. It wasn't Trac. I believe it was written
in Ruby. I wasn't reading the Blender mailing list when the decision was
made to move to gforge, but I would assume it may have been due to problems
with Sourceforge. That is a common reason for ditching Sourceforge. From a
project management perspective I would suggest considering a move to
Launchpad.net would. There are many advantages in migrating Blender to
Launchpad.

   - Launchpad offer the free hosting convenience of Sourceforge, but with a
   much better UI and API and no advertising.
   - No Blender project resources would be wasted managing a gforge
   repository.
   - The GUI to Launchpad is more advanced and feature-full than gforge and
   Sourceforge.
   - Launchpad has an integral bug tracking tool that supports multiproject
   bugs and bug tracking in external
trackershttps://help.launchpad.net/Bugs/MultiProjectBugs/.

   - Launchpad scales much better than gforge. There is a huge user base
   (over 18,000 projects)
   - Launchpad has evolved gracefully and new powerful features are added on
   a regular basis.
   - There is solid financial support for Launchpad development from the
   Ubuntu project.
   - The huge user base and commitment of the Ubuntu project makes it a safe
   choice.
   - Launchpad uses Bazaar, distributed SCM, has an command structure that
   is mostly a superset of Subversion. It just does a much better job of
   managing memory usage, and it has very good merge support.
   - It is possible to directly import a Subversion repository into Bazaar
   with no information loss. The converse is not true.
   - If you don't like Bazaar you can use VCS to remotely manage alternative
   repositories using GIT, SVN,...
   - The entire Launchpad data repository is accessible through a Python
   API.
   - They have an XML schema for importing bugs.

The biggest problem standing in the way of an easy and rapid migration to
Launchpad is the lack of a gforge-to-launchpad migration script for bugs.
There is a trac-to-launchpad
scripthttps://launchpad.net/trac-launchpad-migrator,
but a gforge reader needs to be written to move the old bugs to the Lauchpad
bug tracker. The Trac migration script is less than 1000 lines of code. Most
of the work would involve modifying the SQL queries used to extract data
from the Trac database to queries that extract data from the gforge tracker.

An unofficial Blender project is already installed on Launchpad. It was
abandoned by the originator of the project, so I asked to be made the
maintainer. I've done some work on updating it to reflect the releases that
were missing. There's a mirror of the Blender
svnhttps://launchpad.net/blenderrepository on Sourceforge that uses
the Bazaar distributed source code
management tool. Only the trunk is mirrored at the moment, but it would be
simple enough to add aditional VCS imports for all of the legacy branches.
If you have commit privileges to the Blender gforge repository I can add you
to the Launchpad bf-committers team. I'd be very happy to turn over the
maintainer role to one of the core Blender maintainers should you choose to
migrate to Launchpad.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] introduction

[Kent Mein]

In reply to Martin Poirier (the...@yahoo.com):

 X-Mailer: YahooMailClassic/11.0.8 YahooMailWebService/0.8.103.269680
 Date: Thu, 3 Jun 2010 08:58:40 -0700 (PDT)
 From: Martin Poirier the...@yahoo.com
 To: bf-blender developers bf-committers@blender.org
 Subject: Re: [Bf-committers] introduction
 Reply-To: bf-blender developers bf-committers@blender.org
 
 
 
 --- On Thu, 6/3/10, Campbell Barton ideasma...@gmail.com wrote:
 
  We also had coverity run scans on blenders source though
  that was on
  2.4x a while ago.
 
 AFAIK, they still run scans on trunk (2.5 now) from time to time.
 
 People that want access can request a login/password(I think LetterRip can do 
 that).
 
 Martin
 

We can try anyway.  I've tried multiple times to add additional people
and get the scan running again fully with 2.5 and talking to them has
been not so fruitful.

I'll push again and see if anything has changed.

Kent
-- 
m...@cs.umn.edu
http://www.cs.umn.edu/~mein
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] introduction

[Ian Watkins]

On Thu, Jun 3, 2010 at 10:29 AM, Nathan Letwory
nat...@letworyinteractive.com wrote:
//snip

 Anyway, feel free to ask more, check out the docs on wiki and join
 #blendercoders to ask for live help. You'll find me with the nick jesterKing

what irc network?  I'll be working on stuff starting around 2100 ET or
so.  Would be nice to talk to some people about things on the wiki if
they aren't clear.

-- 
--Ian
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] introduction

[Xavier Thomas]

Freenode

For devoloping purpose #blendercoders is the place to go.

There is no automatical build system, but indivudual can upload svn or
custom on www.graphicall.org
No review tool neither, only the patch tracker on projects.blender.org

Xavier

2010/6/3 Ian Watkins watkin...@gmail.com:
 On Thu, Jun 3, 2010 at 10:29 AM, Nathan Letwory
 nat...@letworyinteractive.com wrote:
 //snip

 Anyway, feel free to ask more, check out the docs on wiki and join
 #blendercoders to ask for live help. You'll find me with the nick jesterKing

 what irc network?  I'll be working on stuff starting around 2100 ET or
 so.  Would be nice to talk to some people about things on the wiki if
 they aren't clear.

 --
 --Ian
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] introduction

[Ian Watkins]

On Thu, Jun 3, 2010 at 11:12 AM, Campbell Barton ideasma...@gmail.com wrote:
 Hi Ian,

 * re: compiler warnings, I compile with CMake on linux which uses:
  -Wall -Wno-char-subscripts -Wpointer-arith -Wcast-align
 -Wdeclaration-after-statement -Wno-unknown-pragmas
 -Wno-char-subscripts

 This removes warnings which in my experience can be ignored, a few
 times I tried to get blender to build with less warnings (when
 omitting some of the flags above), but found it mostly useless.
 There are libraries like bullet which is really an external project so
 we try not to modify its source, and other cases in the game engine
 where there is no easy way to fix the warning.
 So even if you get 1000's of warnings (with only -Wall for instance),
 I have found its not that easy to simply go in and 'fix' many of them.

 I've run blenders code through cppcheck, splint, clangs error checker.
 We also had coverity run scans on blenders source though that was on
 2.4x a while ago.

 nevertheless, fix warnings you find when building blender is a fine
 place  to start.

My experience is that if you ignore warnings, they just grow --
masking problems one should probably look at.  Additionally, that path
can lead to people caring less about warnings than they should.
Granted, some warnings are innocuous -- but those are typically easy
to fix.

When working with a large group of people, it seems like an absolute
policy serves everyone the best.

As an example, when I write code, I tend to throw -Wall -Wextra
-Werror and make sure it keeps building.  When someone adding feature
to such a codebase has an issue, it is because their code is
(arguably) broken.

In other words, zero warnings in (when I checked out the code) leads
to zero warnings out (when I commit my code back to the central
repository).  Otherwise, how do I know if I added warnings or not?

Just my experience.  I acknowledge that this is possibly a waste of
time, but I'm getting several things out of it, while the rest of you
are getting (hopefully) fewer warnings.  Seems like a good trade all
around.


 * re: memory management.
 We have guarded alloc, which can help track leaks based on a string ID
 for each alloc, however it could be interesting to replace the
 allocator.
 AFAIK the only thing which makes this tricky MEM_allocN_len() which
 returns the length of allocated memory. this is only used in a few
 places so I think its use could be removed and we could swap out
 guarded alloc altogether, for testing/benchmarking.

pretty much every allocator I've looked at can trivially add a similar
interface, with only jemalloc not being able to do it in O(1).
Generally, I've considered such an interface a debug extension.  What
is this used for in the code?  Offhand, I can only think of trying to
avoid growing a buffer with realloc, or, alternately, avoiding buffer
overruns.  I'll grep through the code and see what's going on, I
guess.


 * re: plugin system. really important to get this right for 2.5, have
 discussed with Brecht and Ton a little, research in this area is
 useful but not sure its a good first project since we need to consider
 how the rna api might fit in with texture, sequencer plugins and
 possible compositor and shader plugins too.

 Of your suggestions I think parallel code is a good place to start if
 you have experience with this in previous projects.
 You could take some area of blender which is self contained and
 optimize it without having to understand lots of different parts of
 blender at once.

 I haven't used GIT yet though I'd like to try [...]

One of us... One of us

-- 
--Ian
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] introduction

[Nathan Letwory]

On 3.6.2010 19:57, Ian Watkins wrote:
 On Thu, Jun 3, 2010 at 10:29 AM, Nathan Letwory
 nat...@letworyinteractive.com  wrote:
 //snip

 Anyway, feel free to ask more, check out the docs on wiki and join
 #blendercoders to ask for live help. You'll find me with the nick jesterKing

 what irc network?  I'll be working on stuff starting around 2100 ET or
 so.  Would be nice to talk to some people about things on the wiki if
 they aren't clear.


#blendercoders @ freenode

/Nathan


-- 
Nathan Letwory
Letwory Interactive
http://www.letworyinteractive.com
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] introduction

[Campbell Barton]

On Thu, Jun 3, 2010 at 7:16 PM, Ian Watkins watkin...@gmail.com wrote:
 On Thu, Jun 3, 2010 at 11:12 AM, Campbell Barton ideasma...@gmail.com wrote:
 Hi Ian,

 * re: compiler warnings, I compile with CMake on linux which uses:
  -Wall -Wno-char-subscripts -Wpointer-arith -Wcast-align
 -Wdeclaration-after-statement -Wno-unknown-pragmas
 -Wno-char-subscripts

 This removes warnings which in my experience can be ignored, a few
 times I tried to get blender to build with less warnings (when
 omitting some of the flags above), but found it mostly useless.
 There are libraries like bullet which is really an external project so
 we try not to modify its source, and other cases in the game engine
 where there is no easy way to fix the warning.
 So even if you get 1000's of warnings (with only -Wall for instance),
 I have found its not that easy to simply go in and 'fix' many of them.

 I've run blenders code through cppcheck, splint, clangs error checker.
 We also had coverity run scans on blenders source though that was on
 2.4x a while ago.

 nevertheless, fix warnings you find when building blender is a fine
 place  to start.

 My experience is that if you ignore warnings, they just grow --
 masking problems one should probably look at.  Additionally, that path
 can lead to people caring less about warnings than they should.
 Granted, some warnings are innocuous -- but those are typically easy
 to fix.

 When working with a large group of people, it seems like an absolute
 policy serves everyone the best.

 As an example, when I write code, I tend to throw -Wall -Wextra
 -Werror and make sure it keeps building.  When someone adding feature
 to such a codebase has an issue, it is because their code is
 (arguably) broken.

 In other words, zero warnings in (when I checked out the code) leads
 to zero warnings out (when I commit my code back to the central
 repository).  Otherwise, how do I know if I added warnings or not?

 Just my experience.  I acknowledge that this is possibly a waste of
 time, but I'm getting several things out of it, while the rest of you
 are getting (hopefully) fewer warnings.  Seems like a good trade all
 around.

Agree that fixing warnings is important, periodically we go over and
cleanup warnings, I'd not say that the warnings in blender are growing
and growing.

Heres a log of warnings from compiling on 64bit linux, gcc 4.4.3
svn r29188: http://www.pasteall.org/13554
ignoring bullet, there are around ~90.

At one point I spent some time to try and have -Werror default but
wasn't able to remove implicit declaration gzopen64, Brecht also
tried to get this working and wasn't able to.

If we can resolve this I'd be OK with using -Werror, at least for a
while and see if its acceptable with our mixed developer base.

 * re: memory management.
 We have guarded alloc, which can help track leaks based on a string ID
 for each alloc, however it could be interesting to replace the
 allocator.
 AFAIK the only thing which makes this tricky MEM_allocN_len() which
 returns the length of allocated memory. this is only used in a few
 places so I think its use could be removed and we could swap out
 guarded alloc altogether, for testing/benchmarking.

 pretty much every allocator I've looked at can trivially add a similar
 interface, with only jemalloc not being able to do it in O(1).
 Generally, I've considered such an interface a debug extension.  What
 is this used for in the code?  Offhand, I can only think of trying to
 avoid growing a buffer with realloc, or, alternately, avoiding buffer
 overruns.  I'll grep through the code and see what's going on, I
 guess.


 * re: plugin system. really important to get this right for 2.5, have
 discussed with Brecht and Ton a little, research in this area is
 useful but not sure its a good first project since we need to consider
 how the rna api might fit in with texture, sequencer plugins and
 possible compositor and shader plugins too.

 Of your suggestions I think parallel code is a good place to start if
 you have experience with this in previous projects.
 You could take some area of blender which is self contained and
 optimize it without having to understand lots of different parts of
 blender at once.

 I haven't used GIT yet though I'd like to try [...]

 One of us... One of us

 --
 --Ian
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers




-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] introduction

[Nathan Letwory]

On 3.6.2010 20:09, Michael McLay wrote:
 On Thu, Jun 3, 2010 at 11:59 AM, Nathan Letwory
 nat...@letworyinteractive.com  wrote:

 The last thing I want to do is start a long discussion on the mailing list.
 Ideally a couple core team members would sign up for the blender repository
 on Launchpad and take it for a test drive. If they like it then we could
 continue the discussion about migrating. If they say no then the subject is
 dropped.

Please sign me up as a core team member interested in test driving again.

 About launchpad - I think I tried gaining maintainership of the Blender
 project there, but I have had no responses to my queries, so I lost

 Interesting. Maybe you asked before they had established a process for
 determining when a maintainer needed to be replaced. It took less than a
 week for me to take over as the maintainer.

That's likely :)

 Should the need arise for making tweaks to the content of the project on
 launchpad there are many plugin tools available. If finer grain control is
 needed the Python API for LaunchPad and Bazaar provide a mechanism for
 controlling the content of the repository without the need to manage the
 software and hardware infrastructure.

Again, count me in as one of the core team members to test drive. My 
username on launchpad.net is also jesterKing :)

Thanks for your input.

/Nathan

-- 
Nathan Letwory
Letwory Interactive
http://www.letworyinteractive.com
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] introduction

[Nathan Letwory]

On 3.6.2010 19:49, Ian Watkins wrote:


 Further queries:

 1) Is there an automated nightly build?  (e.g., BuildBot, hudson, etc)
 If not, what would it take to get one set up?  Actually, I think I
 could do this myself -- but it would lack the ability to post good
 output to a webserver.  I could easily have eail sent to this list if
 that's acceptable.

No, we don't have any official nigthly build, but graphicall.org is 
where builders can upload their own builds, and it has worked very 
nicely for our means. For linux there are already automated builds 
(triggered on commits).

For windows I started yesterday writing a small script that'd upload 
builds that are comparable to our official releases (considering they're 
then done with the very same machine as the releases will be done ;). A 
few more days and those should be there too. At least regular builds on 
a daily basis

 2) Is there a code review tool instance?  (i.e., review board,
 crucible, reitvald, etc)  If not, can one be set up?

We use the patch tracker for external code, otherwise there's no review 
process per se. I have had experience only with review board. I'm not 
sure if up-front code review would work for our process as we know it 
currently, and I don't yet see the value in a tool like this in our case.

Code review is done mostly by module/code owners and in case of larger 
rewrites/patches, on ML or in IRC some team members are recruited to 
review the patch and give comments. This is also handled often through 
our patch tracker (see https://projects.blender.org).

I'm interested in investigating more these kind of tools for Blender 
though. Maybe the launchpad.net might prove useful - we'll see :)

/Nathan

-- 
Nathan Letwory
Letwory Interactive
http://www.letworyinteractive.com
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Introduction to Notifiers

[Matt Ebb]

Hi all,

I've noticed in IRC over the past months, a little confusion about
what notifiers are and how they work in Blender 2.5. I've
compiled/written up a little tutorial that hopefully explains their
purpose a bit better for new coders.

Check it here: 
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/NotifiersIntroduction

(Or any corrections, please edit the page :)

As I was doing a bit of work in the wiki I also noticed a
not-very-widely publicised doc on adding new properties with DNA and
RNA. I'd encourage people unfamiliar with it to take a look:

http://wiki.blender.org/index.php/BlenderDev/Blender2.5/DefineProperty


cheers,

Matt
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction to Notifiers

[Aurel W.]

Very nice doc work, thanks a lot.

Aurel

On 5 February 2010 12:48, Matt Ebb m...@mke3.net wrote:
 Hi all,

 I've noticed in IRC over the past months, a little confusion about
 what notifiers are and how they work in Blender 2.5. I've
 compiled/written up a little tutorial that hopefully explains their
 purpose a bit better for new coders.

 Check it here: 
 http://wiki.blender.org/index.php/BlenderDev/Blender2.5/NotifiersIntroduction

 (Or any corrections, please edit the page :)

 As I was doing a bit of work in the wiki I also noticed a
 not-very-widely publicised doc on adding new properties with DNA and
 RNA. I'd encourage people unfamiliar with it to take a look:

 http://wiki.blender.org/index.php/BlenderDev/Blender2.5/DefineProperty


 cheers,

 Matt
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers