Hi,
could you provide a OSX or Win build, I'd love to check that out. or maybe
a video on youtube which shows it ?
cheers,
F.
2012/3/30 pete larabell
> Hey all!
>
> I've posted a build of r45292 with the 2D Mask rasterizer in the
> compositor to graphicall.org
>
> The link is HERE: http://gra
Hi all,
Thanks for the feedback! I also had a good response from Apple about
Gakekeeper, assuring me it's basically just a way to sign binaries so users can
track it back to the makers.
I've asked them for free membership(s), but 99 USD per year is no problem to
pay for BF either :)
BTW: the
Hi, one of the proposals I have posted is relevant to the topic of this email
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/kalast/29002
Even though I find this topic interesting and exciting I am interested
to hear if there is a conflict of interests especially from Nicholas
Perhaps I should clarify "conflict of interests", which is conflict of
interest in coding the feature rather than the legal kind :)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Hey all,
Found some time to revisit this and I think I found a work-around, though I'm
not sure if it's considered clean (enough). I've opened a page on the tracker
with the diff:
http://projects.blender.org/tracker/index.php?func=detail&aid=30746
Basically what I did is I check the user pref
Hi all,
for old patches (2010 and earlier) I've requested the author to
respond whether the patch is still useful or should be closed.
We really need to get a plan for the patch tracker, folks have
submitted patches that appear quite useful but have languished for a
long time. I've had discussio
No conflicts from me :) I had intended to return to dynamic sculpting
when I've finished other sculpt stuff, but if you're available to work
on it for GSoC that's even better. I would suggest that your proposal
could use more detail though -- even if your final implementation ends
up different, it
Tom M wrote:
> for old patches (2010 and earlier) I've requested the author to
> respond whether the patch is still useful or should be closed.
[SNIP]
On a related note (bug & patch tracker):
One thing I noticed is that the creator of the tracker can not change the
status (e.g. to closed) later
Anyone who has added a comment or is assigned to the patch/bug will
see any new comments. So ie your please close comment was seen by me
and i closed the patch.
LetterRip
On Sat, Mar 31, 2012 at 10:41 AM, "Martin Bürbaum"
wrote:
> Tom M wrote:
>> for old patches (2010 and earlier) I've request
Tom M wrote:
> Anyone who has added a comment or is assigned to the patch/bug will
> see any new comments. So ie your please close comment was seen by me
> and i closed the patch.
In this case yes, but I was thinking in more general terms.
If nobody with the rights to change the tracker is notif
Patch reviewed -- looks good to me! For the most part...
Doing this in the WM has the additional benefit of affecting all
platforms, not just MacBooks. Yay!
Posting a GHOST event is an okay solution like you say, but might as
well go for the best, right? Which WM event type is generated in
respon
Hello,
I hate to mention the Patch Tracker in case I'm just missing something, but
here goes...
It seems to me that the patch tracker is currently designed to fill up with
crap. What I mean is that once a patch is accepted it just disappears from
the list, while the unaccepted ones just linger t
Harley:
> It seems to me that the patch tracker is currently designed to fill up with
> crap. What I mean is that once a patch is accepted it just disappears from
> the list, while the unaccepted ones just linger there forever.
Well said, sir! I don't have much experience with the tracker, but if
Sounds good to me! On the other hand it also does feel like a bit of code
duplication.
Should the behaviour for a GHOST_kEventTrackpad ever change, the
GHOST_kEventTrackpad must also be modified.
Updated the tracker though, as I definitely see where you're coming from as
well. =)
Also, I just c
Mike,
My comments might have seemed a bit off topic, but I do think the current
design hurts the review process as well.
Assume I submit 5 patches, four of which are unsuitable. The good one gets
accepted and disappears, while the bad ones might get a comment or two, but
they don't get *removed*
While we're on the topic, I was able to discover no straightforward way up
updating a patch when I wanted to revise mine. I couldn't figure out how to
upload a new attachment for my patch. I had to submit a new patch.
--
Jorge "Vino" Rodriguez
jo...@lunarworkshop.com
twitter: VinoBS
919.757.3066
Also, I only just found this, but the pinch/ magnifiy seems to be opposite of
what you'd expect I think? (pinch is zoom out, magnify is zoom in.)
-Patrick
> Date: Sat, 31 Mar 2012 16:58:14 -0400
> From: significant@gmail.com
> To: bf-committers@blender.org
> Subject: Re: [Bf-committers] Use
I agree it's not 100% clear, but to update a patch you have to go to your page,
add a new attachment -and- a follow-up message, and hit "Save Changes" from
there.
> Date: Sat, 31 Mar 2012 15:46:25 -0700
> From: jo...@lunarworkshop.com
> To: bf-committers@blender.org
> Subject: Re: [Bf-committer
On Sat, Mar 31, 2012 at 6:16 PM, patrick boelens wrote:
> Sounds good to me! On the other hand it also does feel like a bit of code
> duplication.
> Should the behaviour for a GHOST_kEventTrackpad ever change, the
> GHOST_kEventTrackpad must also be modified.
Eh, we usually have bigger things t
Actually the other cases do call it, though I did have it in there twice (once
in the else, once outside); sorry about that!
I kept the final one and also put the trackpad specific code within the
if-block.
I also moved the update_tablet_data() there, as a call to that for a wheelEvent
just see
Three things I've learned about getting patches into trunk:
1) you have to pester people to get them to look at your stuff
2) the bug tracker is the most direct route to trunk since people
actually care about the bug count
3) the patch tracker's main use is somewhere to put code you're pretty
sure
After speaking more closely with some Blender developers I have withdrawn
my previous proposal and formulated a draft of a new proposal. This
proposal assembles a list of user interface items to work on from the Wiki,
from bug reports, from interactions I have had with some Blender community
member
noticed this commit changes the style of multi-line if statement.
See the diff, lines under: /* duplicate flagged vertices */
I much prefer the way it was, when the '{' doesnt get its own line,
the checks in the IF statement get aligned with the code after the if
statement (within the braces),
23 matches
Mail list logo
