[Bf-committers] Trunk compile scons/msvc broken on windows due to changes in blf_glyph.c
Hey gsrb3d, i get the errors: source\blender\blenfont\intern\blf_glyph.c(39) : error C2006: '#include': Datein amen erwartet, aber 'Bezeichner' gefunden source\blender\blenfont\intern\blf_glyph.c(39) : fatal error C1083: Datei (Inclu de) kann nicht geöffnet werden: : No such file or directory scons: *** [D:\blender_dev\code\build\trunk\source\blender\blenfont\intern\blf_g lyph.obj] Error 2 scons: building terminated because of errors. Best regards, Thomas ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Trunk compile scons/msvc broken on windows due to changes in blf_glyph.c
Hi, din...@gmx.de (2010-11-01 at 1100.23 +0100): Hey gsrb3d, i get the errors: source\blender\blenfont\intern\blf_glyph.c(39) : error C2006: '#include': Datein amen erwartet, aber 'Bezeichner' gefunden source\blender\blenfont\intern\blf_glyph.c(39) : fatal error C1083: Datei (Inclu de) kann nicht geöffnet werden: : No such file or directory scons: *** [D:\blender_dev\code\build\trunk\source\blender\blenfont\intern\blf_g lyph.obj] Error 2 scons: building terminated because of errors. Yeah, thanks, got a similar report via private mail. The problem is that Blender's freetype (the one under lib/windows/) is an ancient version, 2.1.7 from 2004-02-12. So two options: someone with MSWindows updates the lib to a version with the functions, which means at least 2.1.10, or if not possible in near future, I will recommit with #ifdef. To get some perspective of the versions: newest is 2.4.3 from 2010-10-03, Debian Stable has 2.3.7 from 2008-06-29, Blender's lib/darwin-9.x.universal/ has 2.3.9 from 2009-03-12, lib/darwin-8.x.i386/ has 2.1.10 from 2005-06-12 and lib/windows64/ has 2.3.5 from 2007-07-02. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Farsthary's branch update help
Hi all :) Since my branch has became pretty obsolete and was based on my first unlimited clay draft in order to commit my latest Unlimited Clay patch I need to flush the old code and start from a fresh sync source what steps should I follow to do that? (flush the old branch and start with fresh updated code) and in case I don't have the bandwith to do that could someone help me on that? Committing my patch would not be a problem since it is only few kb but re-syncing my branch I don't know... Thanks in advance and all the best Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.55 beta AHOY!
This line is failing: char *modpath= BLI_get_folder(BLENDER_SCRIPTS, modules); Can you start blender with strace to see where its looking? strace blender 21 | grep modules On Mon, Nov 1, 2010 at 3:43 PM, Ken Hughes khug...@pacific.edu wrote: Tested my 64-bit build this morning; untarred into my home directory and ran, got this message: bpy: couldn't find 'scripts/modules', blender probably wont start. Ken ___ 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] [32823] trunk/lib/windows: New Freetype libs for MSVC 2008.
Hi, din...@gmx.de (2010-11-02 at 0013.49 +0100): Revision: 32823 http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=revroot=bf-blenderrevision=32823 Author: dingto Date: 2010-11-02 00:13:49 +0100 (Tue, 02 Nov 2010) Log Message: --- New Freetype libs for MSVC 2008. Committing version 2.4.3 here. Compiled LIB Release with MXVC 2008 Express Edition Thanks, that was fast. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Auto-registration in Python
On Fri, Oct 29, 2010 at 10:06 PM, Nathan Vegdahl ces...@cessen.com wrote: On the contrary. Having half-defined subclasses of RNATypes breaks the Liskov substitution principle. How? The RNATypes themselves are not fully defined (e.g. you can't use bpy.types.Panel directly). Making a derived class of bpy.types.Panel that also can't be directly used hardly violates the Liskov substitution principle, as long as it can also be further derived from. I'm not even sure how Liskov is relevant. It _is_ however a violation of the 'contract', as you stated later on. So I see where you're coming from. But still, these are rules of thumb, not things that should be strictly enforced. Because sometimes it is useful to bend or break such principles, even if in the general case it is best to stick to them. My main complaint about the current system, however, is that it's so implicit. It does things without the code telling it to. And this is bad, both in terms of my personal preferences and in terms of code readability (i.e. being able to follow what's going on). I would hate to use a GUI toolkit, for example, that automatically displayed defined GUI elements without them being explicitly linked somewhere in the main loop. That's exactly what this feels like. The current system: 1. Coder defines a class. 2. That class magically shows up somewhere else without the coder telling it to. 3. wtf? A better system: 1. Coder defines a class. 2. Coder puts that class somewhere else. 3. No wtf. Having said that, I'm coming to agree with you insofar as property types are concerned (e.g. something derived from IDPropertyGroup), since as a coder you expect to just be able to use the class directly in your code. Having to 'register' it is strange. But things like operators, and especially panels(!) because they meaningfully change Blender's behavior, really feel like things that should be registered explicitly. --Nathan On Thu, Oct 28, 2010 at 9:26 PM, Martin Poirier the...@yahoo.com wrote: NOTE: TL/DR at bottom --- On Thu, 10/28/10, Nathan Vegdahl ces...@cessen.com wrote: It should be even more trivial with automatic registration. And yet in reality... Yet in really it's exactly as I was saying. Those problems concern properties, which aren't taken care off by the autoregistration system (yet), which really sucks. I agree. Part of the problem is that IDPropertyGroup derived classes, as a RNAType, is autoregistered while property definitions aren't, that's why property definition needs to be done in the Register function (especially in cases where they reference subclasses of IDPropertyGroup, which I would guess is more than a few times). [Well, that and otherwise addons wouldn't be good citizen and you'd end up with properties from all installed stuff, which is a huge NO). This isn't even a problem with autoregistration, the same issue would crop up with manual registration. You just can't define properties in the main namespace of a module if they reference IDPropertyGroup classes that will be registered later (whether automatically or manually in the Register function, as before). Also, the addons system won't work correctly in those cases, as mentioned before. One major problem is that there is (as far as I'm aware), no real written guidelines as to how addons should be coded in that regard. (In the future, as a solution, adding a delayed call system for properties would be the way to solve it, and that should pretty much be doable in the same way autoregistration currently works and pretty much remove the need for Register and Unregister functions, although we could still keep them around if people want to initialize custom resources). Here's the thing: I'm speaking as someone who was not involved in designing the system. For someone who doesn't have knowledge of the internals of how auto-registration works, it becomes a magical system with semi-unpredictable and unclear rules. Like, what gets registered? What doesn't? How do I control that so that I can structure my code how I want to? When do things get registered? Etc. I agree, there's a serious lack of documentation. The rules are rather simple though: Anything that derives from an RNAType is automatically registered (and will work correctly with the addon system). Don't derive from an RNAType if your class isn't a fully formed RNAType (with all the defined methods and whatnots that this imply). Any properties that you want to add need to be added in a Register function. The ordering doesn't really matter. RNATypes will always be registered (in the order they are defined) before the Register function is called, so if you add properties to a IDPropertyGroup in your Register function, it will always work the first time. Where it fucks up is when turning stuff on and off in the addons system and registering a module (or a
Re: [Bf-committers] Farsthary's branch update help
If all else fails I suppose someone could try mailing you a dvd with the latest repository on it :) I would offer to do so now but alas i'm doing exams and don't have much time. On 11/2/10, ra...@info.upr.edu.cu ra...@info.upr.edu.cu wrote: Hi all :) Since my branch has became pretty obsolete and was based on my first unlimited clay draft in order to commit my latest Unlimited Clay patch I need to flush the old code and start from a fresh sync source what steps should I follow to do that? (flush the old branch and start with fresh updated code) and in case I don't have the bandwith to do that could someone help me on that? Committing my patch would not be a problem since it is only few kb but re-syncing my branch I don't know... Thanks in advance and all the best Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Sent from my mobile device From Luke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender-2.55 has no menu bar
Didn't realize I'd exceeded the size limit, sending without attachment, will
upload blenderstrace.txt to bug 3015824. Also having trouble
losing the attachment with thunderbird, hope I don't have to resend a copy
paste version.
On 11/01/2010 01:52 AM, Campbell Barton wrote:
You shouldn't need to copy files from /usr/share/blender into
~/.blender, if so then its a bug.
I understand from this that I can delete ~/.blender and blender should
create it on first use, is this correct?
I just tested and it work as expected.
With CMake, set the CMAKE_INSTALL_PREFIX variable, its /usr/local by
default, I set it to /opt/blender25
make install copies the files into the install prefix.
Please excuse the layout of my replies, I'm writing this over a period of time
as I find out (what are IMHO) relevant information.
I'm using svn 32811 for this exercise hope it doesn't change anything.
The make install part of using cmake over scons is a big step forward
from scons placing everything in install/linux2. I cannot use
%{buildroot}, which is where the files to populate the rpm go, in the
%build section of the spec file and scons didn't place the files in an
FHS type directory hierarchy. Now with make install I can use the
rpmbuild macro %makeinstall and the files go into FHS compliant
directories, I only have to move the locale directory to /usr/share/locale.
My %{prefix} is /usr, %{_bindir}=/usr/bin and %{_datadir}=/usr/share.
When I am finished I will attach the final 11.3 x86_64 build log.
For an example on using CMake to create a package see:
./build_files/package_spec/pacman/PKGBUILD
You could look into why it cant find the script directory using strace.
If you grep for the dir you filter out a lot of junk, notice the last
line the path is found, eg:
~ # strace /opt/blender25/bin/blender 21 | grep /opt/blender25
execve(/opt/blender25/bin/blender, [/opt/blender25/bin/blender],
[/* 36 vars */]) = 0
readlink(/proc/self/exe, /opt/blender25/bin/blender, 4094) = 26
stat(/opt/blender25/bin/blender, {st_mode=S_IFREG|0755,
st_size=125951465, ...}) = 0
stat(/opt/blender25/bin/2.55/config, 0x7fff8291a6e0) = -1 ENOENT (No
such file or directory)
stat(/opt/blender25/bin/2.55/config, 0x7fff8291a6a0) = -1 ENOENT (No
such file or directory)
stat(/opt/blender25/bin/2.55/python, 0x7fff8291a770) = -1 ENOENT (No
such file or directory)
stat(/opt/blender25/bin/release/python, 0x7fff8291a580) = -1 ENOENT
(No such file or directory)
stat(/opt/blender25/share/blender/2.55/python, 0x7fff8291a580) = -1
ENOENT (No such file or directory)
readlink(/opt/blender25/bin/blender, 0x7fff82905940, 4096) = -1
EINVAL (Invalid argument)
stat(/opt/blender25/bin/Modules/Setup, 0x7fff82906880) = -1 ENOENT
(No such file or directory)
stat(/opt/blender25/share/blender/2.55/scripts/modules,
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
Using strace /usr/bin/blender.bin 21 | grep /usr I noticed the line :
stat(/usr/share/blender/2.55/config, 0x7fff780c0180) = -1 ENOENT (No such
file or directory)
Looking at the blender.org x86_64 linux 2.54 tarball I noticed a directory
/usr/share/blender/2.54/cfg and /usr/share/blender/2.54/config
were present but empty and have even tried creating them, what are their
purpose?
So far I've changed from moving blender/%version/datafiles/locale to
/usr/share/locale which is where the language files should reside to
using lndir to populate locale/ with symbolic links to the language files.
At this stage after using strace a few times I've rebuilt blender with
/usr/share/locale containing symlinks to the contents of
/usr/share/blender/2.55/datafiles/locale
Here is the output of strace when it locates /usr/share/blender/2.55/datafiles
note. I've renamed my ~/.blender directory deliberately :
stat(/home/davepl/.thumbnails/normal/, {st_mode=S_IFDIR|0755, st_size=32768,
...}) = 0
stat(/home/davepl/.thumbnails/fail/blender/, {st_mode=S_IFDIR|0755,
st_size=6, ...}) = 0
stat(/usr/bin/2.55/datafiles/locale, 0x7fff729a53e0) = -1 ENOENT (No such
file or directory)
stat(/home/davepl/.blender/2.55/datafiles/locale, 0x7fff729a54c0) = -1 ENOENT
(No such file or directory)
stat(/data/src/osc/home:plater:blender/blender/release/datafiles/locale,
0x7fff729a51e0) = -1 ENOENT (No such file or directory)
stat(/usr/bin/release/datafiles/locale, 0x7fff729a51e0) = -1 ENOENT (No such
file or directory)
stat(/usr/share/blender/2.55/datafiles/locale, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
stat(/usr/bin/2.55/config, 0x7fff729a52b0) = -1 ENOENT (No such file or
directory)
stat(/home/davepl/.blender/2.55/config, 0x7fff729a5390) = -1 ENOENT (No such
file or directory)
brk(0x1c93000) = 0x1c93000
brk(0x1cb6000) = 0x1cb6000
brk(0x1cdc000) = 0x1cdc000
brk(0x1d04000) = 0x1d04000
brk(0x1d25000) = 0x1d25000
brk(0x1d46000) = 0x1d46000
Re: [Bf-committers] Blender-2.55 has no menu bar
On Tue, Nov 2, 2010 at 12:58 AM, Dave Plater dpla...@webafrica.org.za wrote:
Didn't realize I'd exceeded the size limit, sending without attachment, will
upload blenderstrace.txt to bug 3015824. Also having trouble
losing the attachment with thunderbird, hope I don't have to resend a copy
paste version.
On 11/01/2010 01:52 AM, Campbell Barton wrote:
You shouldn't need to copy files from /usr/share/blender into
~/.blender, if so then its a bug.
I understand from this that I can delete ~/.blender and blender should
create it on first use, is this correct?
I just tested and it work as expected.
With CMake, set the CMAKE_INSTALL_PREFIX variable, its /usr/local by
default, I set it to /opt/blender25
make install copies the files into the install prefix.
Please excuse the layout of my replies, I'm writing this over a period of
time as I find out (what are IMHO) relevant information.
I'm using svn 32811 for this exercise hope it doesn't change anything.
The make install part of using cmake over scons is a big step forward
from scons placing everything in install/linux2. I cannot use
%{buildroot}, which is where the files to populate the rpm go, in the
%build section of the spec file and scons didn't place the files in an
FHS type directory hierarchy. Now with make install I can use the
rpmbuild macro %makeinstall and the files go into FHS compliant
directories, I only have to move the locale directory to /usr/share/locale.
My %{prefix} is /usr, %{_bindir}=/usr/bin and %{_datadir}=/usr/share.
When I am finished I will attach the final 11.3 x86_64 build log.
For an example on using CMake to create a package see:
./build_files/package_spec/pacman/PKGBUILD
You could look into why it cant find the script directory using strace.
If you grep for the dir you filter out a lot of junk, notice the last
line the path is found, eg:
~ # strace /opt/blender25/bin/blender 21 | grep /opt/blender25
execve(/opt/blender25/bin/blender, [/opt/blender25/bin/blender],
[/* 36 vars */]) = 0
readlink(/proc/self/exe, /opt/blender25/bin/blender, 4094) = 26
stat(/opt/blender25/bin/blender, {st_mode=S_IFREG|0755,
st_size=125951465, ...}) = 0
stat(/opt/blender25/bin/2.55/config, 0x7fff8291a6e0) = -1 ENOENT (No
such file or directory)
stat(/opt/blender25/bin/2.55/config, 0x7fff8291a6a0) = -1 ENOENT (No
such file or directory)
stat(/opt/blender25/bin/2.55/python, 0x7fff8291a770) = -1 ENOENT (No
such file or directory)
stat(/opt/blender25/bin/release/python, 0x7fff8291a580) = -1 ENOENT
(No such file or directory)
stat(/opt/blender25/share/blender/2.55/python, 0x7fff8291a580) = -1
ENOENT (No such file or directory)
readlink(/opt/blender25/bin/blender, 0x7fff82905940, 4096) = -1
EINVAL (Invalid argument)
stat(/opt/blender25/bin/Modules/Setup, 0x7fff82906880) = -1 ENOENT
(No such file or directory)
stat(/opt/blender25/share/blender/2.55/scripts/modules,
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
Using strace /usr/bin/blender.bin 21 | grep /usr I noticed the line :
stat(/usr/share/blender/2.55/config, 0x7fff780c0180) = -1 ENOENT (No such
file or directory)
Looking at the blender.org x86_64 linux 2.54 tarball I noticed a directory
/usr/share/blender/2.54/cfg and /usr/share/blender/2.54/config
were present but empty and have even tried creating them, what are their
purpose?
So far I've changed from moving blender/%version/datafiles/locale to
/usr/share/locale which is where the language files should reside to
using lndir to populate locale/ with symbolic links to the language files.
At this stage after using strace a few times I've rebuilt blender with
/usr/share/locale containing symlinks to the contents of
/usr/share/blender/2.55/datafiles/locale
Here is the output of strace when it locates
/usr/share/blender/2.55/datafiles note. I've renamed my ~/.blender directory
deliberately :
stat(/home/davepl/.thumbnails/normal/, {st_mode=S_IFDIR|0755,
st_size=32768, ...}) = 0
stat(/home/davepl/.thumbnails/fail/blender/, {st_mode=S_IFDIR|0755,
st_size=6, ...}) = 0
stat(/usr/bin/2.55/datafiles/locale, 0x7fff729a53e0) = -1 ENOENT (No such
file or directory)
stat(/home/davepl/.blender/2.55/datafiles/locale, 0x7fff729a54c0) = -1
ENOENT (No such file or directory)
stat(/data/src/osc/home:plater:blender/blender/release/datafiles/locale,
0x7fff729a51e0) = -1 ENOENT (No such file or directory)
stat(/usr/bin/release/datafiles/locale, 0x7fff729a51e0) = -1 ENOENT (No
such file or directory)
stat(/usr/share/blender/2.55/datafiles/locale, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
stat(/usr/bin/2.55/config, 0x7fff729a52b0) = -1 ENOENT (No such file or
directory)
stat(/home/davepl/.blender/2.55/config, 0x7fff729a5390) = -1 ENOENT (No
such file or directory)
brk(0x1c93000) = 0x1c93000
brk(0x1cb6000) = 0x1cb6000
brk(0x1cdc000) = 0x1cdc000
brk(0x1d04000)
[Bf-committers] Couple of patches for MinGW compilation
Hi MinGW compilation broken at the time, firstly by outdated python library files and later by outdated Freetype library. I submitted couple of very simple patches https://projects.blender.org/tracker/index.php?func=detailaid=24461group_id=9atid=127 and https://projects.blender.org/tracker/index.php?func=detailaid=24495group_id=9atid=127 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Couple of patches for MinGW compilation
Personally i think it's not good idea to use tdm-gcc to build libraries -- better to use official mingw-gcc with sjlj exceptions model atm. Especially if library contains c++ code, but there could be other problems, maybe with glibc, not sure. Original Message Subject: [Bf-committers] Couple of patches for MinGW compilation From: alex liquidi...@ya.ru To: bf-committers@blender.org Date: 11/02/2010 07:01 AM Hi MinGW compilation broken at the time, firstly by outdated python library files and later by outdated Freetype library. I submitted couple of very simple patches https://projects.blender.org/tracker/index.php?func=detailaid=24461group_id=9atid=127 and https://projects.blender.org/tracker/index.php?func=detailaid=24495group_id=9atid=127 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Couple of patches for MinGW compilation
On Tue, 02 Nov 2010 04:21:05 +0200, Sergey I. Sharybin g.ula...@gmail.com wrote: Personally i think it's not good idea to use tdm-gcc to build libraries -- better to use official mingw-gcc with sjlj exceptions model atm. Especially if library contains c++ code, but there could be other problems, maybe with glibc, not sure. tdm-gcc use sjlj exceptions model, and at the time when I checked it, official MinGW with gcc-4.x.x used DW2 exceptions causing troubles with linking. I'll try to recompile Freetype with official MinGW and if everything ok reupload it to the tracker Original Message Subject: [Bf-committers] Couple of patches for MinGW compilation From: alex liquidi...@ya.ru To: bf-committers@blender.org Date: 11/02/2010 07:01 AM Hi MinGW compilation broken at the time, firstly by outdated python library files and later by outdated Freetype library. I submitted couple of very simple patches https://projects.blender.org/tracker/index.php?func=detailaid=24461group_id=9atid=127 and https://projects.blender.org/tracker/index.php?func=detailaid=24495group_id=9atid=127 ___ 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] Couple of patches for MinGW compilation
On Tue, Nov 2, 2010 at 2:35 AM, alex liquidi...@ya.ru wrote: On Tue, 02 Nov 2010 04:21:05 +0200, Sergey I. Sharybin g.ula...@gmail.com wrote: Personally i think it's not good idea to use tdm-gcc to build libraries -- better to use official mingw-gcc with sjlj exceptions model atm. Especially if library contains c++ code, but there could be other problems, maybe with glibc, not sure. tdm-gcc use sjlj exceptions model, and at the time when I checked it, official MinGW with gcc-4.x.x used DW2 exceptions causing troubles with linking. I'll try to recompile Freetype with official MinGW and if everything ok reupload it to the tracker Original Message Subject: [Bf-committers] Couple of patches for MinGW compilation From: alex liquidi...@ya.ru To: bf-committers@blender.org Date: 11/02/2010 07:01 AM Hi MinGW compilation broken at the time, firstly by outdated python library files and later by outdated Freetype library. I submitted couple of very simple patches https://projects.blender.org/tracker/index.php?func=detailaid=24461group_id=9atid=127 and https://projects.blender.org/tracker/index.php?func=detailaid=24495group_id=9atid=127 Committed the patch, Sergey told me about this incompatibility but thought this would be ok since freetype is written in C. -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Auto-registration in Python
Hi, --- On Mon, 11/1/10, Campbell Barton ideasma...@gmail.com wrote: But now its become a problem that we have more complicated situations which I dont think can be handled well automatically... 1) registering classes which have properties which are themselves are rna classes... and so on. This is an issue also with manual registration. 2) registration order in these complex cases is not clear. Not made better with manual registration. Worse, this means is has to be sorted out by all authors and not by a dependency walker (which would be possible but probably not even needed). 3) unregistering these needs to be done in the right order or there are problems. Not different when doing it manually. 4) dynamically defined classes/operators are also a case where auto-registration becomes more tricky then its worth. If you're talking about the cases where people were using type() to initialize a class, that's very much overcomplicating things for nothing (even without automatic registration). Reloading addons/scripts and all of the above problems IMHO mean that automatic registration is just not able to deal with this well. No. What it does mean is that the RNA registration and properties system as a whole have problems that we didn't foresee before. Going back to manual registration doesn't solve the issues, it shoves them back in the court of the users. The thing to do now is to identify what those problems are (regardless of the registration method used: the required order of registration and properties definition stays the same in all cases for example) and, if possible, solve them at the C API level, if not, define as clearly as possible the steps needed to do things properly. Only then can we decide if it's at all possible to keep doing things automatically and if not, what kind of documentations needs to be written to show people how to do it manually. As an added note, unloading plugins is not something that we are the only ones struggling with. Other software sometimes require you to restart the program to correctly unload a running extension, for example. I'm not saying being about to load/unload stuff consecutively in a single session isn't something that we should try to do, but if it makes everyone's life harder, it's possible to compromise. For the most part is works OK but there are still problems. simple example is bug. https://projects.blender.org/tracker/index.php?func=detailaid=24132group_id=9atid=498 I tried for an hour or so to fix it but its just not easy to do with the current system. This is exactly the kind of problem I was talking about before in a reply to Nathan. Manual registration is not going to solve this magically. The real problem here is that properties registration is decoupled from RNA type definition. That is an issue regardless of whether or not registration is done manually. One thing that can be tried is having optional initialize() and dispose() class methods in RNATypes. initialize is called after the type is registered (so that it is now a real RNA type) while dispose is called before it is unregistered (so that it is still a valid RNA type). Going back to that bug tracker entry, this is what it would look like: - class XPlaneObjectSettings(bpy.types.IDPropertyGroup): @classmethod def initialize(cls): bpy.types.Object.xplane = bpy.props.PointerProperty(attr=xplane, type=cls, name=XPlane, description=XPlane Export Settings) cls.exportChildren = bpy.props.BoolProperty(attr=exportChildren, name=Export Children, description=Export children of this to X-Plane., default = False) @classmethod def dispose(cls): del bpy.types.Object.xplane - Doing things this way also makes the class more self contained (it doesn't depend on outside definitions to work properly). Moreover, it should be possible to make the dispose() code in this case unneeded if defining properties used a wrapper function that associated the defined properties with the module/rnatype where they are defined (which would also make removing non IDPropertyGroup properties on unregister automatic). In simple cases its convenient but for complex cases the script author has no idea whats going on and ends up needing to read blenders internal registration code to figure out how to make their script work. How would that be any different with manual registration? IMHO this is a case where our API tries to hide inner working where it shouldn't. IMHO, this is a case where we didn't abstract the inner workings of our API enough. Remember, this is an API we want to have around for a long time. The more we can hide the inner warts of the internal C API, the easier it will be in the long term to fix stuff there without having to pull the rug under people's feet. So I'm
Re: [Bf-committers] Auto-registration in Python
On Tue, Nov 2, 2010 at 1:44 PM, Martin Poirier the...@yahoo.com wrote: 4) dynamically defined classes/operators are also a case where auto-registration becomes more tricky then its worth. If you're talking about the cases where people were using type() to initialize a class, that's very much overcomplicating things for nothing (even without automatic registration). I've been using exec() to dynamically generate idpropertygroups with lists of parameters that are determined at runtime. How could this be done without dynamically defining classes? cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
