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?
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
On Thu, Apr 5, 2012 at 8:53 AM, Andrew Hunter and...@aehunter.net wrote:
It was brought to my attention that Xavier Thomas has already working
such an integration. Perhaps the developers could chime in on the
possibility of getting this work merged to trunk.[2]
Further along this path, I just
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
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
+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:
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
== 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.
--
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
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
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
On Fri, Apr 6, 2012 at 7:14 PM, Przemyslaw Golab gbird...@gmail.com 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
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
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 ideasma...@gmail.com wrote:
On Fri, Apr 6, 2012 at 7:14
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
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
2012/4/6 Przemyslaw Golab gbird...@gmail.com:
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
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
On Fri, Apr 6, 2012 at 11:04 AM, Campbell Barton ideasma...@gmail.comwrote:
2012/4/6 Przemyslaw Golab gbird...@gmail.com:
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
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 ces...@cessen.com wrote:
Just committed the first version of the new keymap. Or perhaps I
should say pre-version. It's
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
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
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
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
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 gbird...@gmail.com wrote:
Campbell Barton
Then it
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 good
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
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
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
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 using
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?
Thanks in
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 almost
@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
g.mari...@liquidnet.it wrote:
On Fri, Apr 6, 2012 at 11:04 AM, Campbell Barton
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 good
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,
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 ces...@cessen.com wrote:
Excellent point. I'll create a wiki page.
Campbell: is there a particular place on the wiki that
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-select
On Fri, Apr 6, 2012 at 11:21 PM, Nathan Vegdahl ces...@cessen.com 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
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,
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
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
on
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
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
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
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 allow
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 to
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! :-)
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
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 is used
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
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
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
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
53 matches
Mail list logo
