I agree with Patrick here. Specialized scripts for generating ivy or
houses or cities or spaceships are great when you need them, but they
don't really belong into the core code. They just increase code size,
add maintenance burden on core devs and are not of much use in most
projects other than th
The id and from pointers are set in the snode_set_context function in
node_edit.c. They describe the context origin (from, what kind of data
block from context defines the node tree, usually the active object),
and the actual owning data block of the node tree (id). They id
pointer is a way to let
Ahh, everything makes sense now! What you say is exactly right. This
Linux behavior can probably be mimicked on Windows too with the proper
driver settings.
But when you click the side switch mapped to MMB while hovering, it's
still MMB if you choose to make contact with the surface, correct?
It's
I feel like we are still miscommunicating.
It sounds like your setup is:
Stylus tip = LMB
Hold down side-button-1 + stylus tip = MMB
Hold down side-button-2 + stylus tip = RMB
In other words, you use the side buttons as _modifiers_ for the tip of
the stylus. Holding them down changes the meaning
> The side buttons are pressure sensitive...?
In a boolean sense, yes! But I meant once the pen makes contact with
the tablet surface while one of the side-buttons is held down.
Pressure = 0 while hovering.
Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
_
The side buttons are pressure sensitive...?
--Nathan
On Fri, Apr 6, 2012 at 4:50 PM, Mike Erwin wrote:
> That's the way I have mine set up too. The Wacom defaults on
> Mac/Windows are RMB and double-click, so you have to make a custom
> profile for blender. I was just pointing out that they're
That's the way I have mine set up too. The Wacom defaults on
Mac/Windows are RMB and double-click, so you have to make a custom
profile for blender. I was just pointing out that they're all pressure
sensitive, not just LMB, and can be used for drawing.
Mike Erwin
musician, naturalist, pixel pusher
> All "buttons" of the pen should already be pressure sensitive, whether
> or not the sideswitch is used to make them MMB, RMB, or whatever. The
> eraser end comes through as button 1 as well (LMB by default). Unless
> you're talking about some strange hardware I haven't tested.
For me:
Tap = LMB
> For people using mice, switching painting functionality to RMB will
> work fine. But for tablet users it's important for LMB to be paint,
> since that's the one with pressure sensitivity.
>
> --Nathan
All "buttons" of the pen should already be pressure sensitive, whether
or not the sideswitch i
Easy fix. Just tried it out. All we need to do is switch selection
to be done with "click" (mouse down + mouse up) instead of just
"press" (mouse down).
In general, though, I feel like manipulators are a neglected part of
blender. Will address at some point over on the funboard list.
--Nathan
Everyone:
In order to avoid cluttering the development mailing list, I'm moving
to the functionality board mailing list for further discussion. There
we can break this up into other topics, with different threads for
each. Please follow me there if you would like to continue
participating! :-)
Y
One of the problem is with the use of manipulators, which seem to have
precedence with LMB action over viewport movement
On Fri, Apr 6, 2012 at 10:51 PM, Fabio Massaioli <
fabio.massai...@virgilio.it> wrote:
>
> When I began to use Blender I chose to use LMB selection because I was
> accustomed t
> Since selecting bones in weight paint mode is a bit like a
> secondary action (with painting being the primary action),
> would it be obscene to change selection in this case to
> be CTRL + LMB?
I think we need to take a broader look at selection first. But using
one of the modifier keys to all
Since selecting bones in weight paint mode is a bit like a secondary action
(with painting being the primary action), would it be obscene to change
selection in this case to be CTRL + LMB? I realize that strays away from
absolute consistency for selection, but I think it would be more strange an
> The only mess-up I'm aware of is weight-painting mode.
> Trying to select a new bone just paints.
Hmm. Yeah, this may be trickier than I thought. Also consider
selecting faces/vertices for masking.
For people using mice, switching painting functionality to RMB will
work fine. But for tablet
When I began to use Blender I chose to use LMB selection because I was
accustomed to other applications. I had soon to switch back to RMB
selection because left button functions overlapped with selection.
Now I think that RMB selection is the best choice and I'd like to use it
also in other ap
The only mess-up I'm aware of is weight-painting mode. Trying to select a new
bone just paints. But if you just hit Shift+LMB, you get a list of (hopefully)
nicely labelled bones. So it isn't that much of a mess-up.
>
> I agree with this but I was about to try doing just this when someone
> o
Pitching in on the sub-modes discussion; I feel submodes should be exactly
that. They should not be listed in the normal Modes menu with
Object/Edit/Weight/etc or else that menu will become too large. I think using
1/2/3 within Edit Mode, and other modes makes the most sense. It's very easy to
> I agree with this but I was about to try doing just this when someone
> on IRC warned me off of it saying it messes up to much in Blender. Was
> this just BS, or is there some truth to it?
That's based on the option in the user preferences. It may be true,
I'm not sure. In our case, though, we
On Fri, Apr 6, 2012 at 11:21 PM, Nathan Vegdahl wrote:
>> Those things said - I've been "trying" LMB-select for a couple of years. I
>> have to say, I much prefer it, as LMB for select is ubiquitous in virtually
>> all other pieces of software I use.
>>
>> Dare I suggest you try this out as well
> Those things said - I've been "trying" LMB-select for a couple of years. I
> have to say, I much prefer it, as LMB for select is ubiquitous in virtually
> all other pieces of software I use.
>
> Dare I suggest you try this out as well Nathan?
Yup! I'm kind of assuming that we'll switch to LMB-
Started a wikipage under my user page for now:
http://wiki.blender.org/index.php/User:Cessen/New_Keymap
--Nathan
On Fri, Apr 6, 2012 at 12:51 PM, Nathan Vegdahl wrote:
> Excellent point. I'll create a wiki page.
>
> Campbell: is there a particular place on the wiki that something like
> this s
On Friday 06 April 2012, Nathan Vegdahl wrote:
> The other thing I'd like to try out is just assigning the
> vert/edge/face modes to 1/2/3.
Just some feedback on this: I'm using exactly this setting for some time now,
and it's far better for me than the default, especially because, as you said,
Inspiring. In particular, this is what caught my eye:
On 2012-04-05, at 11:30 PM, Nathan Vegdahl wrote:
> (When I say "keymap" in this email, I mean to include the mouse as
> well. Basically, key/mouse-map.)
>
> == Principle 5 ==
> Consistency with other software. Tautology: unless there are
"Mike Erwin;
Instead of a one-size-fits-all keymap, why can't we have it grow or
shrink based on what devices a person is actually using? Might be
better as a keymap-gen script outside blender, to keep things simple.
Input: "I have a US keyboard layout without numpad, an Inutos4M, and a
SpaceMouseP
Excellent point. I'll create a wiki page.
Campbell: is there a particular place on the wiki that something like
this should go? I'm looking at the guidelines, and it's not entirely
obvious to me where this would fit. Maybe just under my user page...?
It also may be a good idea to simply move t
> I would like to see four high-level modes, ie object
> mode, face mode, vertex mode, and edge mode.
This is definitely worth trying out. I'll give it a go and we can see
how it feels.
The other thing I'd like to try out is just assigning the
vert/edge/face modes to 1/2/3. I suspect vert/edge/
> @Nathan: totally agree. My comment was referred to having a key for every
> tool Oo.
Oh, I see! Ha ha, I totally misunderstood. I agree.
--Nathan
On Fri, Apr 6, 2012 at 3:26 AM, Gianmichele Mariani
wrote:
> On Fri, Apr 6, 2012 at 11:04 AM, Campbell Barton wrote:
>
>> 2012/4/6 Przemyslaw Go
> Finding the most used commands might be done by writing a recorder
> that is mode aware and then letting a large group of pros/advanced
> users use it. Once you get the data then you have a great starting
> place when it comes to deciding what is important and often used VS
> commands that are al
Hi,
I'm trying to understand the node editor code and I haven't been able so
far to figure out where the "id" and "from" properties of the "SpaceNode"
structure are set. I suppose there should be some code that changes those
members on selection change.
Can you tell me something about that?
Than
> Related to this is differences in keyboard layouts. Many laptops do
> not have numeric keypads, and yet people are more and more frequently
> using laptops for serious graphics work. There are also differences
> in keyboard layouts between countries.
>
> Also: number of mouse buttons? People u
I don't think that has any effect on what I suggested. That all remains the
same, but you remove an abstraction layer which groups the three edit modes
inside a parent mode.
It's not an issue of changing how it's implemented, but rather of changing
how it's presented to the user. Currently the pre
> I would like to see four high-level modes, ie object mode, face mode,
> vertex mode, and edge mode.
Is this a correct way of looking at it?
You can be in Object mode *OR* Edit mode. But you can have vertex
select, edge select, and face select enabled simultaneously if you wish
so they aren't
On the topic of mode switching:
I did some work on this in my own keymap and my approach was to reduce the
number of keystrokes and mouse clicks to switch modes. Currently to switch
among edit modes (vertex, edge, face) you must press the hotkey and then
choose with the mouse. That involves a bit
Inspiring. In particular, this is what caught my eye:
On 2012-04-05, at 11:30 PM, Nathan Vegdahl wrote:
> (When I say "keymap" in this email, I mean to include the mouse as
> well. Basically, key/mouse-map.)
>
> == Principle 5 ==
> Consistency with other software. Tautology: unless there are
I would like to get involved in this too - is there a wiki page or IRC
channel we can use to kick around ideas? I can see this topic becoming
really long winded for the mailing list.
-Sean
On Fri, Apr 6, 2012 at 7:14 AM, Przemyslaw Golab wrote:
> Campbell Barton
>
> Then it should be made east
Students, don't put your submission off to the very last minute. A
few students in irc have mentioned some sort of problem uploading (so
far easily resolved issues) so please don't wait too long and end up
being unable to submit.
There is about 3.5 hours left before the deadline.
Looking forward
Campbell Barton
Then it should be made east & fast.
>
Hehe, good point. :)
--
n-pigeon
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Hi!
By the way. I have one most used command I use in edit mode.
I wanted to propose to create a hot key by default for "Limit selection to
visible" button, that
lay right aside the (vert/edge/face) buttons.
Usually I bind it to "Q" key and I use that function very often
when I edit meshes, and I
A basic idea is to find what is used most often and then make those
keys the most easy to type, remembering the rule of one hand on the
mouse at all times.
Finding the most used commands might be done by writing a recorder
that is mode aware and then letting a large group of pros/advanced
users us
Incidentally - the underline keys in the menu can also be used as
shortcuts, so..
Space, E (Edit mode)
Space, O (Object mode)
On Fri, Apr 6, 2012 at 8:17 PM, Nathan Vegdahl wrote:
> Just committed the first version of the new keymap. Or perhaps I
> should say pre-version. It's not much yet.
>
>
On Fri, Apr 6, 2012 at 11:04 AM, Campbell Barton wrote:
> 2012/4/6 Przemyslaw Golab :
> > Yes but the problem is the creations of keyslot, creating new keyslot for
> > operator that doesn't have one is not easy and fast.
> >
> > You have to > find it (learn that it doesn't exists) > create one (le
Just committed the first version of the new keymap. Or perhaps I
should say pre-version. It's not much yet.
The main change of interest that I've made is how mode-switching
works. A toggle mentality really doesn't work anymore, since e.g.
mesh objects have numerous modes. I'm experimenting wit
2012/4/6 Przemyslaw Golab :
> Yes but the problem is the creations of keyslot, creating new keyslot for
> operator that doesn't have one is not easy and fast.
>
> You have to > find it (learn that it doesn't exists) > create one (learn
> how) > and edit it. Not just, find it > edit it how you like.
Hmm, maybe something different about my #8 rule.
Everything haves a slot, event if it not assigned to key. Then if someone
wants a hot key for this function, he only add what key he want.
How about this approach?
--
n-pigeon
___
Bf-committers mailing
Yes but the problem is the creations of keyslot, creating new keyslot for
operator that doesn't have one is not easy and fast.
You have to > find it (learn that it doesn't exists) > create one (learn
how) > and edit it. Not just, find it > edit it how you like.
W dniu 6 kwietnia 2012 11:35 użytko
Agreed, Campbell. Principle 8 really ought to be:
"There is no such thing as a perfect keymap. We _will_ be making
compromises, and not everyone is going to be perfectly happy."
--Nathan
On Fri, Apr 6, 2012 at 2:48 AM, Campbell Barton wrote:
> On Fri, Apr 6, 2012 at 7:14 PM, Przemyslaw Golab
> There's just not enough room to still keep consistency
> and all of those wonderful principles.
No doubt! I have no illusions that a "perfect" keymap is possible,
hitting all of these principles 100%. With any problem this complex,
that's not going to happen. You can't design roads to get eve
On Fri, Apr 6, 2012 at 7:14 PM, Przemyslaw Golab wrote:
> == Principle 8 ==
>
> Key-map everything. There are many operators that don't have any key-map.
> Users have to manually create key-slot for it and configure it and it is
> not so easy and takes some time.
> Users should have some key-map f
As much as I would love to have a keymap for everything, I think this is
really difficuly. There's just not enough room to still keep consistency
and all of those wonderful principles.
Also keep in mind that not all artists need to use the whole 100% of
Blender but only a subset of it for which I'
Thanks Campbell!
I attempted to commit what I have so far, but SVN gave me this error:
svn: Commit failed (details follow):
svn: Server sent unexpected return value (405 Method Not Allowed) in
response to MKCOL request for
'/svnroot/bf-extensions/!svn/wrk/1c506060-ffef-45df-99b1-68315534/contr
I'd greatly appreciate and help in finishing my proposal for a Multitouch
Framework in Blender for GSoC. :)
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/nickrishel/1
The Project Details section is not well fleshed out, unfortunately my brain
gave up for the night before I did
== Principle 8 ==
Key-map everything. There are many operators that don't have any key-map.
Users have to manually create key-slot for it and configure it and it is
not so easy and takes some time.
Users should have some key-map for everything so they could just easily
edit it if needed.
--
n-pi
> Here are some (proposed) principles for designing the keymap (the
> order has nothing to do with importance):
> --Nathan
> ___
+1 for all of these principles.
___
Bf-committers mailing list
Bf-committers@blen
+1,
Nathan, you can start working on this immediately in contrib if you like.
From trunk this DIR us used for keymap files but as with any other
contrib script - it wont be included in release, which is a good think
seeing as we're in feature freeze ATM.
The keymap can be committed to:
./release/
> Also as a Dvorak keyboard users, I always feel left out. I switch to
> QWERTY just for blender use.
Ah, indeed! This should be filed under principle 7, along with all
those other things I haven't a clue how to address yet. Hopefully
we'll come up with solutions as we try out various keymap ide
> Might also be an idea to keep the current keymap, if the changes are
> integrated etc., in a "Blender Classic" preset, so that people who like
> the current set up can still get to use them.
Sorry, I should have mentioned this. I took it for granted that this
is what we will do! So yes, absolu
On Fri, Apr 6, 2012 at 9:05 AM, metalliandy
wrote:
> Sounds like a good idea :)
> Might also be an idea to keep the current keymap, if the changes are
> integrated etc., in a "Blender Classic" preset, so that people who like
> the current set up can still get to use them.
Yes, I was about to post
Sounds like a good idea :)
Might also be an idea to keep the current keymap, if the changes are
integrated etc., in a "Blender Classic" preset, so that people who like
the current set up can still get to use them.
On 06/04/2012 05:53, CG Cookie wrote:
> A major +1 from me as well. If you'd like
59 matches
Mail list logo
