Re: [Bf-committers] build documentation incorrect, non-existing link
Thanks for pointing this out, I've updated the file now and pointed to the wiki where most of the useful information is. Brecht. On Sun, Feb 24, 2013 at 7:33 PM, Torsten Mohr wrote: > Hello, > > according to the "Bug report guidelines" it seems i should post this here, in > the freshly downloaded blender-2.66 sources in doc/build_systems/cmake.txt it > says that the Dependencies are listed at: > > http://www.blender.org/cms/Getting_Dependencies.135.0.html > > But it seems that page does not exist. > > Surely just a very minor issue,but to my understanding worth changing. > > > Best regards > Torsten > > ___ > 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] Hypothetical take on client/server based addon/package repositories
Here are some ideas/notes/comments/[delusions?] on what a
client/server for blender addon's could look like. Basically it is how
I would go about a basic implementation of such a system (give of take
some refinements along the way). Unfortunately, not being python
person, if I tried to write a prototype client, it would probably be
considered cruel and unusual punishment to the project. ;) I could
create a small demo repository using some of the existing addons, if
anyone thinks that would help. Otherwise, maybe some will read this
and point out any design flaws (that hopefully can be accounted for).
And, since I haven't seen the other repository addon manager demo, I
have no idea how this differs (or is redundant of) that one.
Anyway.. here it is (warning! it is a _little_ long)..
-Chad
Package Side Format
===
Zip structure
-
myaddon.bap:
manifest.txt The package meta-data (required)
license.txtThe full license text (optional)
icon.png An icon of the addon (optional).
python/The base directory for python
(equivalent to each addon directories as-is now)
(required if python based)
lib32/freebsd/ Various platform specific directories for holding
lib32/linux/ binaries (i.e. DLL's/.so's) The os-mnemonic would
lib32/osx/ be a fixed defined value in blender for each OS.
lib32/windows/
lib64/freebsd/
lib64/linux/
lib64/osx/
lib64/windows/
Manifest Format (MIME style)
For general package manifest information, a simple MIME header style
should be adequate. This could be a modified form (no line
continuation, max line length ~200 characters maybe, UTF-8 allowed for
some field values).
Package-Version: 1
ID: {----}
Legacy-ID: myaddon
Name: My Add-on
Version: 1.0
Icon: icon.png
Type: addon/python
Creator: John Doe
Copyright: Copyright, 2013, John Doe Industries
License: GPL/3.0
Description: Do the things an add-on should do.
Description: A really long description is continued with multiple
Description: lines.
URL:http://myaddon.example.com/
Platform: linux/32
Platform: windows/32
Platform: linux/64
Platform: windows/64
Target-Application: blender:2.69-2.78
The breakout would be (some based on the firefox addon meta names):
Package-Version (required)
The spec version of all meta-fields in this group.
Ideally this should rarely need to change.
Suggested as first field, but not required as such.
ID (required)
The unique ID. This should be considered case insensitive.
For UUIDs, it would be enclosed in braces (i.e. {}).
Also could potentially use domain based identifier rules
(e.g. org.blender.addon.rigify), but this alone doesn't
account for domain ownership changes over time (without a
datestamp encoded with it, in a consistent format). Maybe
more like org.blender.addon.rigify@201302, with the date
being a MM[DD] with-in the domain ownership period
(doesn't have to be the domain registration date like some
schemes use), as long as the same date is always used for
the same addon.
Legacy-ID (optional)
Used to match again the legacy name.
Maybe this wouldn't be needed, but was a thought.
Also could be called Friendly-ID (see below - far below)
Name (required/utf8)
The simple addon name.
Version (required)
The addon version (in "unbound" dot notation).
1.0
3.0.2
1.5.2.1
2.3.2013.02.18.1 (no, that's not a stardate!)
The versions parts would be compared as text (no assumption of
value ranges as integers). So 1.0.92800018178901018117191011.2
is a valid version. Missing [right side] parts are same as 0.
Possible a single letter suffix could be supported (which
would be treated as an addition .## notation of: X - 'a' + 1).
2.63 --> 2.63
2.63a --> 2.63.1
Icon (optional/multi?)
The package relative path of an icon file (always png?).
If multiple are allowed to be specified, then the "best fit"
would be used (each assumed to be a different resolution,
or maybe even format [like SVG over a bitmap]).
Type (required)
The [hierarchical] type mnemonic of what the package contains.
addon/python -- Standard addon (python)
[Bf-committers] Blender developer meeting notes, 24 February 2013
Hi All, >Alternative is to do brute-force raycast tests. Might even work surprisingly fast. just for reference for anyone interested - how raycast picking was done in dx ( so this is algorithm for ref, links also have some gotchas (second link) ) . http://www.mvps.org/directx/articles/rayproj.htm http://www.mvps.org/directx/articles/improved_ray_picking.htm Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Rigify addon causes error, error, error,....
On Tue, Feb 26, 2013 at 8:29 AM, Nathan Vegdahl wrote: >> Would prefer addon devs don't do this, some do already but it means we >> can't be sure the addon in SVN is really the latest one, have to >> contact devs before release to make sure we pull the latest version >> in, and it won't be tested as much (or not and have older addons in >> which miss features/fixes), > > While I understand the inconvenience this can pose, there is already > too much inconvenience for me the other way around. Whats inconvenient about maintaining an addon in svn? > So for the time > being, at least, I'm going to do primary development of Rigify on > github (http://github.com/cessen/rigify), and merge stable changes > during the appropriate BCon stages. If the development model for > addons included with Blender changes at some point, I'll reconsider. > But I don't think that model necessarily needs to change. Don't blame you, I've been using git for development too (then moving into svn when ready). So if you can keep whats in trunk stable, maintained and update fixes for release, this works, I just want to avoid fragmentation. > I treat (and want to treat) Rigify as an independent project, and > would really prefer a less centralized development model for it, and > inclusion as an officially supported addon hinders both those things > by design. So this seems like a decent compromise: it lets me develop > it independently as needed/wanted, but it can still be included as an > official addon for those who want it to be so. We can think of the > github repo as something like a development branch. Ok, as a dev branch I see where your coming from, I still worry a bit that changes wont be tested as well in our development builds. > I would also be perfectly happy for Rigify to not be included as an > official addon, but I think there may be others that would object to > that. For example, there was a certain someone that argued in favor > of its inclusion after Sintel. ;-) It's a shame if we can't provide users good tools by default (even though they need to be enabled). If rigify is fairly small and kept working with current blender releases, I don't see why not include it. >> users who want to test latest version need >> to manually grab it. - just becomes a hassle IMHO, ...makes conflicts >> more likely too. > > This is a use-case that should be better supported anyway, IMHO. Not sure how we would better support this - you can install an addon from a zipfile, that parts fairly straightforward. The hassle is mostly that users need to know what to search for in the first place, trust the script isn't malicious, check the version matches their blender and manually update it from the authors web site. > Obviously if two conflicting versions of an addon are enabled > simultaneously, we can't expect that to work. But simply having two > different versions of an addon present... not sure why that needs be > an issue. Not sure what your getting at here, it shouldn't be an issue, I'm quite sure it can be added. > Consider, for example, someone having two different > versions of an external renderer installed, and they want to be able > to use either/or in different projects (maybe one is more stable, but > the other has more features). I think there are meaningful use-cases > outside of Rigify and the current situation. Agree, did you check on adding support for this? if you wanted some help investigating ways to implement we could continue discussion on bf-python. > --Nathan -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Rigify addon causes error, error, error,....
> Would prefer addon devs don't do this, some do already but it means we > can't be sure the addon in SVN is really the latest one, have to > contact devs before release to make sure we pull the latest version > in, and it won't be tested as much (or not and have older addons in > which miss features/fixes), While I understand the inconvenience this can pose, there is already too much inconvenience for me the other way around. So for the time being, at least, I'm going to do primary development of Rigify on github (http://github.com/cessen/rigify), and merge stable changes during the appropriate BCon stages. If the development model for addons included with Blender changes at some point, I'll reconsider. But I don't think that model necessarily needs to change. I treat (and want to treat) Rigify as an independent project, and would really prefer a less centralized development model for it, and inclusion as an officially supported addon hinders both those things by design. So this seems like a decent compromise: it lets me develop it independently as needed/wanted, but it can still be included as an official addon for those who want it to be so. We can think of the github repo as something like a development branch. I would also be perfectly happy for Rigify to not be included as an official addon, but I think there may be others that would object to that. For example, there was a certain someone that argued in favor of its inclusion after Sintel. ;-) > users who want to test latest version need > to manually grab it. - just becomes a hassle IMHO, ...makes conflicts > more likely too. This is a use-case that should be better supported anyway, IMHO. Obviously if two conflicting versions of an addon are enabled simultaneously, we can't expect that to work. But simply having two different versions of an addon present... not sure why that needs be an issue. Consider, for example, someone having two different versions of an external renderer installed, and they want to be able to use either/or in different projects (maybe one is more stable, but the other has more features). I think there are meaningful use-cases outside of Rigify and the current situation. --Nathan On Sun, Feb 17, 2013 at 7:24 PM, Campbell Barton wrote: > On Mon, Feb 18, 2013 at 4:58 AM, Nathan Vegdahl wrote: >> Thanks for the fix Irie! >> >>> Anyway, I don't understand why you did such big changes in Bcon4... >> >> Fair enough. It seemed like the best option of bad options. I'm >> currently working with a studio to improve Rigify for their pipeline, >> but I have a limited amount of time to be on-site working with them. >> Given that Rigify is an addon, and not part of Blender proper, I felt >> it was worth it for the sake of properly documenting the changes and >> milestones instead of having a mega-commit at the end. >> >> There's also a complicating factor, which is that they're working with >> SVN blender, so every time they update, it wipes out any local Rigify >> changes. >> >> All-in-all, perhaps not the best choice on my part, but it wasn't on a whim. >> >> In any case, I'll avoid this in the future. Perhaps I ought to >> maintain a parallel git repo somewhere for publishing out-of-sync >> changes. > > Would prefer addon devs don't do this, some do already but it means we > can't be sure the addon in SVN is really the latest one, have to > contact devs before release to make sure we pull the latest version > in, and it won't be tested as much (or not and have older addons in > which miss features/fixes), users who want to test latest version need > to manually grab it. - just becomes a hassle IMHO, ...makes conflicts > more likely too. > > Best just try avoid this situation again, if an addon is well > maintained we shouldn't be finding its broken right before release. > > Of course if you wanted to make a git repo to work on some > improvements during the week of the release, then pull the changes > back into svn right after and continue development in SVN, thats > different. > >> --Nathan >> >> >> On Sat, Feb 16, 2013 at 7:51 PM, IRIE Shinsuke >> wrote: >>> Hi Nathan, >>> >>> Your recent commit (r4286) introduced a bug in poll() of the new >>> "Rigify Dev Tools". It causes an error every time UI is updated: >>> >>> Traceback (most recent call last): >>> File >>> "/home/irie/build/blender2.6/cmake/bin/2.65/scripts/addons/rigify/ui.py", >>> line 206, in poll >>> return obj.mode == 'EDIT_ARMATURE' >>> NameError: global name 'obj' is not defined >>> >>> >>> The following patch fixes it: >>> >>> Index: release/scripts/addons/rigify/ui.py >>> === >>> --- release/scripts/addons/rigify/ui.py (revision 4288) >>> +++ release/scripts/addons/rigify/ui.py (working copy) >>> @@ -203,7 +203,7 @@ >>> >>> @classmethod >>> def poll(cls, context): >>> -return obj.mode == 'EDIT_ARMATURE' >>> +return context.mode == 'EDIT_ARMATURE' >>
