Re: [Bf-committers] Steam Greenligth
On Fri, Nov 2, 2012 at 5:00 AM, Sean Olson seanol...@gmail.com wrote: you would have to make a steam-blender that integrates with steam API and installs into their folder structure. I don't think you would have to do anything of the sort. There's no Steam folder structure it's really just a package delivery system. Some Blender developer would create a Steam package (it's called a 'depot' in Steam terminology) and upload it to Valve's servers, and then Steam downloads the depot and unpacks it on the user's computer. You can integrate with Steam's API if you want but it's not necessary. In all it's not a whole lot of effort. As far as F/OSS on Steam goes, I think you'll find Valve is very reasonable. They want people using and enjoying their service and there's a large cross section of Steam users who would use Blender. Their legal people are very amicable as well. You have nothing to lose by asking, anyway. -- Jorge Vino Rodriguez jo...@lunarworkshop.com [ Tweet http://twitter.com/vinobs | Like http://www.facebook.com/bsvino| Plus http://www.google.com/profiles/bs.vino ] 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Temporary global storage
I need a place where I can put a UI-related temporary variable for storing things such as what was the last button pressed and when did the last tooltip close. It must be in some scope that's visible to and accessible by all controls. I can't put it in RNA because those things are stored to the hard drive, and these things are runtime-related and shouldn't be stored. I don't want to make a global variable because that's obviously sloppy. There doesn't seem to be any UI-related area to place stuff that should be visible to all controls but not stored on the hard drive. If I can solve this problem then I should be able to immediately remove two things from my list. -- Jorge Vino Rodriguez jo...@lunarworkshop.com [ Tweet http://twitter.com/vinobs | Like http://www.facebook.com/bsvino| Plus http://www.google.com/profiles/bs.vino ] 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Temporary global storage
This would be perfect but I can't find a place to use it that's not part of
an operator. There's no single operator responsible for handling these
functions. I'm not able to find any way to attach a SKIP_SAVE property to,
for example, wmWindowManager or wmWindow. I'd rather avoid resorting to a
static variable in a function. Maybe there's some way to do it with rna
that I'm not seeing?
On Thu, Jun 21, 2012 at 4:01 AM, CoDEmanX codem...@gmx.de wrote:
How about using RNA with SKIP_SAVE flag?
bpy.types.World.temp_var = StringProperty(description=Label of the
control, options={'SKIP_SAVE'})
Or in C:
prop = RNA_def_int(ot-srna, prop_name, 1, 1, INT_MAX, Prop
Name,
, 1, 10);
RNA_def_property_flag(prop, PROP_SKIP_SAVE);
Am 21.06.2012 09:52, schrieb Jorge Rodriguez:
I need a place where I can put a UI-related temporary variable for
storing
things such as what was the last button pressed and when did the last
tooltip close. It must be in some scope that's visible to and accessible
by
all controls. I can't put it in RNA because those things are stored to
the
hard drive, and these things are runtime-related and shouldn't be
stored. I
don't want to make a global variable because that's obviously sloppy.
There
doesn't seem to be any UI-related area to place stuff that should be
visible to all controls but not stored on the hard drive. If I can solve
this problem then I should be able to immediately remove two things from
my
list.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
--
Jorge Vino Rodriguez
jo...@lunarworkshop.com
[ Tweet http://twitter.com/vinobs | Like http://www.facebook.com/bsvino|
Plus http://www.google.com/profiles/bs.vino ]
919.757.3066
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Temporary global storage
You' On Thu, Jun 21, 2012 at 3:57 PM, Dan Eicher d...@trollwerks.org wrote: On Thu, Jun 21, 2012 at 3:00 PM, Jorge Rodriguez jo...@lunarworkshop.com wrote: This would be perfect but I can't find a place to use it that's not part of an operator. There's no single operator responsible for handling these functions. I'm not able to find any way to attach a SKIP_SAVE property to, for example, wmWindowManager or wmWindow. I'd rather avoid resorting to a static variable in a function. Maybe there's some way to do it with rna that I'm not seeing? If these variables aren't of interest to people in general it's overkill to wrap them in rna and (automagically) expose them in the py-api. Why would anyone care when the last time a tooltip was closed or what the last highlighted button was when writing a script? Dan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Jorge Vino Rodriguez jo...@lunarworkshop.com [ Tweet http://twitter.com/vinobs | Like http://www.facebook.com/bsvino| Plus http://www.google.com/profiles/bs.vino ] 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Temporary global storage
Oops! Accidentally hit enter. You're right, they wouldn't care. I'm not trying to expose anything to python, I'm just trying to find a good place to store this thing without resorting to a global variable. On Thu, Jun 21, 2012 at 4:07 PM, Jorge Rodriguez jo...@lunarworkshop.comwrote: You' On Thu, Jun 21, 2012 at 3:57 PM, Dan Eicher d...@trollwerks.org wrote: On Thu, Jun 21, 2012 at 3:00 PM, Jorge Rodriguez jo...@lunarworkshop.com wrote: This would be perfect but I can't find a place to use it that's not part of an operator. There's no single operator responsible for handling these functions. I'm not able to find any way to attach a SKIP_SAVE property to, for example, wmWindowManager or wmWindow. I'd rather avoid resorting to a static variable in a function. Maybe there's some way to do it with rna that I'm not seeing? If these variables aren't of interest to people in general it's overkill to wrap them in rna and (automagically) expose them in the py-api. Why would anyone care when the last time a tooltip was closed or what the last highlighted button was when writing a script? Dan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Jorge Vino Rodriguez jo...@lunarworkshop.com [ Tweet http://twitter.com/vinobs | Likehttp://www.facebook.com/bsvino| Plus http://www.google.com/profiles/bs.vino ] 919.757.3066 -- Jorge Vino Rodriguez jo...@lunarworkshop.com [ Tweet http://twitter.com/vinobs | Like http://www.facebook.com/bsvino| Plus http://www.google.com/profiles/bs.vino ] 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Temporary global storage
Uncle_Entity suggested in IRC that I should try G or G.main. G has a lot of assorted, almost random stuff in it. It's not the best place for it since it's still a glorified global, but it's not serialized to disk and it wouldn't have other averse consequences like exposing to Python scripts. I think I'm going to try with this if others don't object. -- Jorge Vino Rodriguez jo...@lunarworkshop.com [ Tweet http://twitter.com/vinobs | Like http://www.facebook.com/bsvino| Plus http://www.google.com/profiles/bs.vino ] 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Floating buttons proposal
Micheal, It's clear that you have some beef with me and I understand that. I don't agree with a lot of the things you have said about me, but I won't argue about them with you since it's clear that we won't agree. I think I may have not made myself clear, which is a common problem that I have, so I will try to clear up some miscommunications that we may have had. 1) I don't want to fundamentally change Blender. I dislike a lot of the design decisions of Blender, this is true. But I also like a lot of the design decisions of Blender. For example, I agree with just about everything on the UI Paradigms wiki pagehttp://wiki.blender.org/index.php/Dev:2.5/Source/UI/UIParadigms. Perhaps I'm so busy criticizing the things that I disagree with that I forget to mention the things I do well. This is my mistake. 2) I often have strong opinions and I love to debate. When I told Brecht that I disagreed with him, my intention was to start a healthy debate, that he may inform me why I was wrong and probably change my mind about one thing or another. To this end I would improve the proposal and learn something. I didn't mean that he was wrong or that I wouldn't listen to what he said, only that I disagreed, as I'm entitled to do. Often my strong opinions are interpreted as defiance on my part and this is another mistake which I make often. 3) Many of the Blender team and myself have a fundamental disagreement on the part of how to handle new users. Ton once said to me in IRC (paraphrased) New users are an unknown quantity. Ignore then and focus on experienced users. This is an attitude that runs contrary to most of the designers I've learned from and worked with. I respect that Blender should be a tool for advanced users and I don't want to change that (please refer to #1). I only want to remove common frustrations and create methods for new users to become acclimated to Blender, ideally without getting in the way of expert users. I don't think that this is a zero-sum game, I think that features that are better for new users are also better for experts. I try to keep all of my work compatible with the expert user workflow. It's important to me as well as you that Blender remain a powerful tool for power users. I think that the two things are not mutually exclusive. Last) This thread is for giving feedback on my proposal. What's your feedback? Do you think that having this option for users is a bad one? Do you think that the existing toolbars serve this function better? Do you think my design choices are poor? I created this thread for feedback, and I would appreciate yours. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Floating buttons proposal
The purpose of floating controls is to allow designs from the proposals of persons like: - Bill Reynishhttp://3.bp.blogspot.com/-J4mFuYz0ZBU/TqRngF0eagI/AJw/2LASnxw262k/s1600/Blender_ui_cleanup.jpg(On the left of the 3D view) - Myself http://i.imgur.com/ErmDd.png (On the bottom of the 3D view) - Leeroy/LCG http://i.imgur.com/Lxqn1.jpg (Along the top) My proposal doesn't include any specific designs, only the ability to create them through scripting. The 'T' toolbar would likely be replaced entirely by some sort of floating control arrangement. The end result would be more space available for the user. The previous operator panel is in my opinion a good workflow idea with a failed design implementation, and we should experiment with other wayshttp://dl.dropbox.com/u/4205810/blender-opstack.pngof doing it, which would be supported by the floating controls structure. I think that not having pixel locations, while it makes sense with the properties panels, may not make so much sense here. Some designs, such as the third, may not boil down to just a row or column of buttons. These designs won't change all that often, so I don't think adding one button between others is a use case that we need to be more concerned about. To zoom, the layout engine can simply scale the pixel locations and sizes. We can include the ability to arrange buttons in rows and columns as well, but I think pixel locations is a good idea. Note: Undocking a panel is another thing to do on my list, but it's not part of this proposal. On Fri, Jun 15, 2012 at 7:01 AM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: Hi, I'm missing details on how you interact with these floating things, a mockup, an example for how they would be used, etc. For me it seems that this would be another way to present what we already have in panels and menus. So how do these coexist, what goes where? Right now we basically have a toolbar, a redo panel, and properties of the space. Could they be some sort of region inside a space like we have now, but overlayed with a transparent background? Also explicit values for pixel sizes should be avoided in scripts, that doesn't work well with a zoomable interface, and makes it more complicated to drop in a button between others. It's nice to allow flexibility but in the end I think you mostly want e.g. a row of icons for a toolbar, or undocking some panel, .. ? So it may not need that many layout code changes, that seems lower priority to me. Brecht. On Wed, Jun 13, 2012 at 8:06 PM, Jorge Rodriguez jo...@lunarworkshop.com wrote: As part of my GSoC I'm going to be implementing some floating buttons in the 3D view. It should help with usability, with reducing clutter in the properties/tool panels, and with tablet users. I'd like some Blender devs to please review it and make comments so that I can revise it before it's updated. http://wiki.blender.org/index.php/User:Vino/Floating_Buttons_Proposal Thank you. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ 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 -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Floating buttons proposal
As part of my GSoC I'm going to be implementing some floating buttons in the 3D view. It should help with usability, with reducing clutter in the properties/tool panels, and with tablet users. I'd like some Blender devs to please review it and make comments so that I can revise it before it's updated. http://wiki.blender.org/index.php/User:Vino/Floating_Buttons_Proposal Thank you. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Developer support for new keymap
You're doing a great job in your new key map and I'd love to support you any way I can. My GSoC project is UI-based but if you can persuade my mentor to let me work on this too then I'd gladly be your code monkey. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] GSoC Thread
Thanks for accepting me into GSoC! I'm so excited! My email from Google says, Now that you've been accepted, please take the opportunity to speak with your mentors about plans for the Community Bonding Period: what documentation should you be reading, what version control system will you need to set up, etc., before start of coding begins on May 21st. In the interest of avoiding mentors repeating themselves for every student I thought I would create this thread so that the GSoC people can all be oriented at once. I plan to copy my proposal to the Blender wiki and use it to keep track of my progress. I'm also thinking about using the Git mirror of Blender on Gitorious to do my work: https://gitorious.org/blenderprojects/blender Is that a good idea? I think a number of Blender devs do this already? One last thing: May 21st is in the middle of exams. How flexible are you guys on that? Looking forward to GSoC! -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GSoC Thread
Last exam is on the 24th, I can start on Blender on the 25th. Since I already have a good bit of Blender coding experience, hopefully I'll be able to hit the ground running :) I'll save the technical details for the gsoc list. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Improving Blender's keymap: a proposal
I've been thinking about number keys and edit modes. It's been suggested that the modes be bound to the number keys. I'm all for this. I also would like to propose that shift plus a number key adds an edit mode. Ctrl + number key can remove a mode. Example suppose a user inputs this series of keys: 1 - Switch to Face mode 2 - Switch to Edge mode Shift 3 - Add Vertex mode, now Blender is in Edge + Vertex mode Shift 1 - Add Face mode, now Blender is in all 3 Ctrl 2 - Remove Edge mode, now Blender is Face + Vertex -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Improving Blender's keymap: a proposal
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 of mouse aiming and an extra click that I think in unnecessary and distracting. My solution was to have three hotkeys, one for each edit mode. That's more keys on the keyboard, but I think it's worth it given how much context switching goes on. Another thing I would like to see is more seamless switching between object mode and the edit modes. If I'm in object mode and I want to go to a specific edit mode then the process is 1. Hit tab to go to edit mode 2. Ctrl-tab to open edit mode menu 3. Select an option, vertex face or edge The mental model that this gives to a user is that there are two high-level modes, object and edit modes, with edit further broken down into three sub-modes. That basically represents how they're implemented in the code. It's a complex mental model that requires a lot of keystrokes and I think it can be simplified. I would like to see four high-level modes, ie object mode, face mode, vertex mode, and edge mode. I think presenting the modes to the user this way is a better choice, since it's a simpler mental model and can result in faster switching between modes and thus more efficient work. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Improving Blender's keymap: a proposal
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 presentation represents the implementation, I am suggesting a presentation that simplifies the conceptual model and makes therefore context switching simpler. On Fri, Apr 6, 2012 at 11:22 AM, Harley Acheson harley.ache...@gmail.comwrote: 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 really modes at all. Harley ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] User Interface Tasklist Proposal
On Sun, Apr 1, 2012 at 8:25 PM, Campbell Barton ideasma...@gmail.comwrote: Even if you dont have big-ticket tasks, would like to see clear direction - Improve usability - is fine but give ~3-6 key areas you will work on to do so. So the takeaway here for me is to find a few specific areas of Blender such as Increased configuration and Efficient use of whitespace and so on, and try to categorize my tasks in those areas. I'm busy today but I'll revise it tonight. Though its a real shame to have someone motivated to work on our UI but unable to because we cant get our act together and appoint a UI team. Haha yes I am crying on the inside. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] User Interface Tasklist Proposal
On Sun, Apr 1, 2012 at 3:12 AM, Campbell Barton ideasma...@gmail.comwrote: * would not be accepted into blender (probably you we'rent to know but pre-select highlighting wouldnt be accepted, Ton doesn't like it) Really? How strange. What's the objection? He doesn't want it even as an option? * are very very easy, or simply tweaking a default (right click menu for text is an example of this, of course users dont care if features are hard to code or not, BUT it does make it harder to review your proposal since we cant really count these additions as significant contributions - projects for you to sink your teeth into) I spoke with some other developers who expressed to me that a lot of small items is better than one large items, better possibility of it being finished. So I just threw everything related to usability (not necessarily UI) onto the list. From what I've seen there's been a few similar polish-related GSoC projects accepted in recent years, so I was hoping it wouldn't be a problem. Would you prefer if there was one or two big ticket items on there? Such as... * reduce vertical scrolling for toolbar, operator view. * cleanup view3D header menus eg: http://www.blendernation.com/2011/10/29/cleaning-up-the-blender-ui/ * improve the layout engine for more efficient use of whitespace (or at least make configurable). * improve toolbar (add/remove user tools would be nice to have) These look really interesting, I would love to add them. Can I ask you to expand on these? How exactly more efficient whitespace, you mean reducing it? How would you want to reduce vertical scrolling? Some of them could be controversial, I tried to stick to uncontroversial things. The Reynish presentation for example I would love to work on. Should I do a Gimp mockup of a new toolbar? If these things require debate, how should I go about handling them in my proposal? I'll move all of the not directly related to UI stuff into a nice-to-have section. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] patch tracker
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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] User Interface Tasklist Proposal
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 members, and from my own personal pet peeves, mostly usability-related improvements and bug fixes. http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/vino/23002 Essentially the proposal is for me to be a janitor for a few months. My goal is at the end of the project Blender will be much more fluid and easier to use and understand for both new and existing users. I would love to see feedback and thoughts, but please remember that items in this list are not final and are at the discretion of the Blender team, including my would-be mentor. If you have something you would like to see on the list, I would like to hear it. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] New-User Interface Proposal
Hello! I've submitted my GSoC proposal about making an interface for Blender that is targeted to new users: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/vino/21001 I would love to hear some feedback and thoughts on how I can improve the proposal and thus my chances of it being accepted. Thanks! -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New-User Interface Proposal
Perhaps I named my proposal wrong. My intention is not to make a crippled UI only for first-time users. My intention is to make a full UI that is easier to understand and would fully support everything Blender has to offer, just as the default Blender UI has right now. It will not be a second UI, it will be a primary UI. Also, like I say in my proposal, I'm not interested in making a Maya-compliant key config. That's much smaller than the scope of this proposal. Many of the things I want to do can not be done right now in Blender, I know this because I have investigated the Blender code and created patches to Blender that support the new interaction models that I want. I've already done a bit of work on this task. It took me two weeks, so I think that completing the list is not out of the scope of work of a GSoC project. The problem as I see it is that Blender's adoption has been weak, in large part because Blender is not friendly to new users. The solution is not more documentation. The people who avoid Blender because it's difficult to use are not going to change their mind because you offer them text to read, or because it is more customizable. They may change their mind if Blender becomes easier to use. That's what I want to accomplish - make Blender easier to use. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Rotate/Pan during Circle Select
I did some work on this that you may find useful as part of my UI changes to Blender. This is a patch against 2.61 that automatically confirms circle select when the mouse is released. If you use this patch and b https://github.com/BSVino/Blender/commit/1c4ddd21eb3eb9b4959587984343640da6b7fa72 I made a lot of other updates to circle select as well, basically turning it into a tool that can be used to drag-select stuff with the left mouse button, without having to enter a different mode. They're scattered around here: https://github.com/BSVino/Blender/commits/traditional I know this doesn't address your question directly but I thought it may help. Seems like what your user may be expecting. On Sat, Mar 3, 2012 at 5:56 PM, Ryan King rk...@panoptic.com wrote: I was talking with a user coming from another 3D package who was bummed about our Circle Select mode requiring you to cancel / rotate / re-enter the mode. My first thought was that it would require an unpopular remapping of MMB (since MMB is used to deselect verts, it cannot be used to Rotate/Pan). So as a workaround I was prepared to tell him to simply use the Keypad navigation - only to find it doesn't work in this mode. Is the implementation of Circle Select Mode somehow tangled that it would be a major challenge to add the ability to use the Numpad while in that mode? Thank you very much, - rking ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 3D Cursor and Border Select
I know that this will be an unpopular suggestion but I will raise it anyway. I would like the team to consider turning the 3D cursor off by default. Not shown and not settable until turned on. Reasons: 1) It's a specific feature used for specific things, new users don't need to see or understand it to begin learning Blender. 2) It's a cumbersome way of doing things, we should develop more intuitive and faster ways of doing what the 3D cursor does. I'll just go ahead and address what I'm sure will be the main counter argument: If you dumb Blender down then you'll get dumb users. Response 1) Everybody is dumb when they're learning. If we want to increase adoption we need to make it easier to learn. Response 2) The user can always turn it back on when they find utility for it. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 3D Cursor and Border Select
On Fri, Mar 2, 2012 at 4:33 PM, Harley Acheson harley.ache...@gmail.comwrote: I would like the team to consider turning the 3D cursor off by default. I would be happy just to *lock* it in place. I use it and love it, but it is never where I want it when I need it because I'm always accidentally moving it around. So just a lock cursor would be great. I was thinking about binding a button to turning it on and off so that it's easy to get out of your way and bring it back when desired. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 3D Cursor and Border Select
The thread is named 3D Cursor and Border Select and I am discussing a solution to your problem of the 3D cursor which you described in your first post: On Sat, Feb 25, 2012 at 4:29 PM, Daniel Salazar - 3Developer.com zan...@gmail.com wrote: In my personal use experience and more importantly when teaching to students setting the 3D cursor with LMB click is one of the main sources of headaches. Seems relevant to me :) -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 3D Cursor and Border Select
On the topic of bound select: I made some changes that allow for, instead of bound select, a sort of drag-select wherein the user drags the mouse over the specific things he wants selected. I modified the circle select to make it. It's a bit more precise than a bound select. If you want to try it out, you can find it here: https://github.com/BSVino/Blender I haven't built a distributable yet because I haven't had time to get the scons build to work and/or get cpack to package Blender properly. On Sun, Feb 26, 2012 at 7:10 AM, Ton Roosendaal t...@blender.org wrote: Which leads to the main issue: three out of four members of our current UI owner team is very inactive now. We need to refresh this team with people who get as much respect recognition as we had during the 2.5 period, and then trust them to build and maintain a sane default. I volunteer. I've already done a bunch of work on this. I have a lot of ideas on how to improve Blender's UI and I have some time to devote. I submitted a patchhttp://projects.blender.org/tracker/index.php?func=detailaid=29945group_id=9atid=127before which allows for left-click select and also drag and drop with the transform tools, but nothing happened with it. If I were on the Blender team I could commit this and all of the other work I've done on Blender (see the commit historyhttps://github.com/BSVino/Blender/commits/traditionalin my GitHub account) directly to the project. Here's all of the stuff I've done with Blender that I would love to see in trunk: - Added some more manipulator handles that move an object locked to 2 dimensions instead of 1. Sort of like pressing shift. - Hovering over a manipulator with the mouse highlights it. - The above mentioned drag-select and drag-drop features. - The ability to bind a key to go directly to vert edge or face mode from object mode. - An option for hiding the 3D cursor completely. (I know this would be unpopular - it would be off by default. Some people hate the 3D cursor.) I'd love to join the team. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] blender UI state
Thanks to those who have provided feedback so far. Please sign your posts on the discussion page or it will quickly become illegible. I hope to see more discussion about the new user experience. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] blender UI state
That page looks like it deals with a lot of specifics. Having not seen enough big-picture discussion, especially concerning the experience of a new user, I've gone ahead and drafted up some ideas on that subject here: http://wiki.blender.org/index.php/User:Vino/New_User_Experience Some of it was copied from this discussion, but much of it is new. I would love to hear people's thoughts or feedback. I would really like to see more people make mockups of what they think the initial screen should look like once users load Blender for the first time. If there is any consensus I would like to use that material to draft a proposal page to make a revamp of Blender's UI specifically geared toward simplifying the default settings for new user adoption. To answer the question: Yes, I am willing to do the work of implementing any such proposal were it to get approved by the devs. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Transform tool tweaks
Unless I'm misunderstanding, that behavior is intentional. The patch adds two features, one being tap to confirm, the other being drag and drop. Now that I think about it, I should make drag and drop an option also. On Sat, Jan 21, 2012 at 8:29 AM, Yousef Hurfoush ba...@msn.com wrote: I'm sorry. Can you explain this better? Break it down into steps for me to reproduce it and I'll see if I can fix it. the optimal case for it to work is: -freeze the mouse movement -press g (now it will lock to mouse) -move your mouse as desired -press g to confirm the error can happen if do the above steps, but: -instead of the 1st step, you'll be moving your mouse. it will lock and confirm directly! i think it's easy to fix, but as i said before : the whole patch doesn't add any simplicity to using blender. Regards Yousef Harfoush ba...@msn.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Transform tool tweaks - Patch available
Martin, The new patch is in. http://projects.blender.org/tracker/index.php?func=detailaid=29945group_id=9atid=127 I had problems updating the old so I created a new one. Sorry if that causes any problems. Both the tap to confirm and the drag and drop functionality are now optional. They default to off. To turn them on you can go into the user preferences, 3D view, and expand the Grab command, and they should be there. Let me know if you have any trouble or feedback. I love feedback. On Tue, Jan 17, 2012 at 7:43 PM, Jorge Rodriguez jo...@lunarworkshop.comwrote: Thanks Martin I'd appreciate that a lot. I see you're the Transform module owner so it's good to know it's being looked at :) I tried to keep the workflow compatible with the current workflow. It should be entirely compatible with the exception of RR. If you have ideas of how to support both at once I would love to hear. On Tue, Jan 17, 2012 at 7:37 PM, Martin Poirier the...@yahoo.com wrote: Hi Jorge, I'll be looking at this as soon as I have time (probably on Thursday). Some of the changes (confirming with release among others) are stuff that I tried early on while porting transform to the 2.5 operator system and should be doable with the current keymap setup. If you want a workflow that isn't currently possible with the customization that exists, I generally think it's better to make the system flexible enough to support both (which might be what you did, haven't looked at the patch yet) and then discuss what the default keymaps/options should be. I'll get back to you once I've had a good look at your patch. Thanks, Martin From: Jorge Rodriguez jo...@lunarworkshop.com To: bf-blender developers bf-committers@blender.org Sent: Tuesday, January 17, 2012 9:25:07 PM Subject: Re: [Bf-committers] Transform tool tweaks - Patch available The patch is now available here: http://projects.blender.org/tracker/index.php?func=detailaid=29919group_id=9atid=127 I would love it if people could try it out and inform me of any problems or suggestions. I would be happy to update the patch given feedback. Following is a reprint of the patch description: This patch is against svn r43478 Changes: * Pressing the grab/rotate/resize button while the tool is already active will cause the tool to confirm the current transformation. In the case of switching rotation modes, this functionality has been moved to Shift-R instead. * When using a transform tool bound to right click, right clicking will confirm instead of cancel; otherwise it will cancel like before. * Holding a transform button/key will drag the object. If the user holds for longer than 250ms or farther than 10 pixels then the action is treated like a drag and when the key is released the transformation is automatically confirmed. Notes: * This patch removes some duplicate code in the modal handler for transform events. * In order to support this patch some slight changes have been made in the way handler operators are called. Duplicate button/key presses are now filtered by the handler and not sent to the operator, and information about the handler/keymapitem which invoked the operator (if any) have been added to the wmOperator structure. * The previous event state also now includes the prevkeytime - the time that the previous keyboard key was pressed. Justification: This patch attempts to improve the usability of the transformation tools by implementing behavior which most users will expect. If a button is pressed once to activate a tool, than users can expect to be able to press that same button again to deactivate the tool. If the user presses and holds the button then the functionality should remain active for as long an the button is held down and then deactivate when it is released. In order to implement this behavior, the behavior when pressing the rotation button twice had to be changed. Before, the second press toggled the rotation type. This functionality has been moved to Shift-R. I recommend that the default bindings also be changed so that Shift-R activates rotation directly in trackball mode, to reduce the number of key presses required to access that mode. I feel that while the different behavior may cause some friction for some current Blender users, the new features should help users, new users especially, feel more comfortable with Blender. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ 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 -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 -- Jorge
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [43589] trunk/blender/source/blender/ editors/object/object_add.c: fix for last commit - declarations must be in the begin of the
I'm using MSVC, CMake, VS10 generator, and I'm pretty sure I've seen errors
related to this. It may not be all versions or configurations of MSVC.
On Sat, Jan 21, 2012 at 5:29 PM, Dalai Felinto dfeli...@gmail.com wrote:
I actually built on OSX with cmake+make (using framework gcc I think).
So we need to expand the disallowance to osx as well I guess.
2012/1/21 Campbell Barton ideasma...@gmail.com
We should have MSVC compiler warnings set up to disallow this as with
GCC.
On Sun, Jan 22, 2012 at 11:49 AM, Dalai Felinto dfeli...@gmail.com
wrote:
Revision: 43589
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=43589
Author: dfelinto
Date: 2012-01-22 00:49:12 + (Sun, 22 Jan 2012)
Log Message:
---
fix for last commit - declarations must be in the begin of the block
(C,
tsc tsc)
Modified Paths:
--
trunk/blender/source/blender/editors/object/object_add.c
Modified: trunk/blender/source/blender/editors/object/object_add.c
===
--- trunk/blender/source/blender/editors/object/object_add.c
2012-01-21
23:57:28 UTC (rev 43588)
+++ trunk/blender/source/blender/editors/object/object_add.c
2012-01-22
00:49:12 UTC (rev 43589)
@@ -1790,13 +1790,13 @@
/* check if obdata is copied */
if(didit) {
Key *key = ob_get_key(obn);
+ bActuator *act;
if(dupflag USER_DUP_ACT) {
BKE_copy_animdata_id_action((ID
*)obn-data);
if(key)
BKE_copy_animdata_id_action((ID*)key);
/* Update the duplicated action in the
action actuators */
- bActuator *act;
for (act= obn-actuators.first; act;
act=
act-next) {
if(act-type == ACT_ACTION) {
bActionActuator* actact
=
(bActionActuator*) act-data;
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
--
- Campbell
___
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
--
Jorge Vino Rodriguez
jo...@lunarworkshop.com
twitter: VinoBS
919.757.3066
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] blender UI state
Someone start a Wiki page and link it here, and I will contribute to it. I don't expect users to learn Blender at an advanced level without manuals and video tutorials. But like I said before: On Thu, Jan 19, 2012 at 7:50 PM, Jorge Rodriguez jo...@lunarworkshop.comwrote: Everything needed to operate Blender *at its most basic level* should be learnable through Blender itself. Notice: At its most basic level. If the most complicated strategy games can be learned from within the game, Blender can be as well. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] blender UI state
I volunteer for this UI business but of course it's up to the existing devs. As far as William Raynish's blog post goes, yes. Oh my god. Yes. I'm going to draw from that a lot as I work on this. I think I can implement many things he suggested. On Thu, Jan 19, 2012 at 9:14 AM, Knapp magick.c...@gmail.com wrote: * I would like to see a right click menu that provides copy and paste when right clicking text areas. Currently ctrl v,c and (x?) I know I know but it's good to provide another method. You clicked it by mistake and do NOT want to save. I have done this many times. Having a prompt does not solve this problem. If there's a prompt then accepting the prompt becomes an automatic part of the user's muscle memory. Then the user has saved when they don't want to and bam, same problem. Unless you mean, the user was trying to Ctrl-D instead or something? There's better ways to solve this problem. Incremental saves. Undos. Version control. Saving is such a universal feature that Blender should confirm to the norm, which is to only produce a popup dialog if a file name has not been chosen. Yep, done that too but I have never lost my work due to Blenders rather odd way of saving stuff. Step 1. Open Blender Step 2. Modify the default cube somehow. Move it around for instance. Do not save. Step 3. Click the window's X button. This closes Blender without asking to save changes. I'm on Windows so perhaps this behavior does not appear on other platforms. It's unacceptable. I have tried a lot of ways and totally disagree. The outliner keeps you from getting lost ... You need the properties all the time, what would you do with them? ... The time line is small and does not take up much space and is needed any time you do animation or anything else with time like particles. You need properties and scene view and timeline to do anything of substance, of course. That doesn't mean that these things should be part of Blender's default view. The point of the default view is new user experience. I realize that nobody here is a new user, so nobody here necessarily wants things that are only good for new users. But I consider myself a new user advocate, and not so long ago, a new user. I think that Blender can change and add new functionality that doesn't stifle existing users while making it easy for new users to learn. I get the sense that many people disregard the new user experience in exchange for power and information, I think this is a mistake. There are many more people who do not use Blender than there are who use it. If you want to increase Blender's adoption, you need to start thinking about new users. New users are concerned about two things. 1. How do I control the camera? 2. How do I edit the mesh in the most basic way? That's it. They don't yet care about animation, rendering, properties, cameras, materials, anything. All they care about is learning how to make an object worth animating, rendering, etc. Look at any tutorials, the first thing they go over is camera controls, the second thing is basic mesh editing. If you make these first steps confusing or difficult then they will abandon Blender as junk. Here are the steps a new user must go through to start editing a mesh. (Note: Yes all of this information is available through tutorials, but people don't like watching tutorials, especially if they're already familiar with other tools. Everything needed to operate Blender at its most basic level should be learnable through Blender itself.) 1. Change to edit mode. A new user doesn't know that this is necessary to edit a mesh. A new user doesn't know that the mesh can't be edited in object mode. The new user must look it up. It's not in a menu. It's in a dropdown labeled Object Mode - the user may not know what that means, or that it's a dropdown, or that clicking it allows mode changes. Edit Mode in that dropdown isn't visible unless the user clicks something. 2. Choose an edit type. The new user doesn't know how to do this. There are three buttons on the button bar that do this but they are buried in other crap and not obvious. This is also not available in a menu. 3. Select something in the mesh to edit. This is a problem since the user will try to left click and select is right click. It may not even occur to some people to try right click. It's really damn frustrating not to be able to select things. 4. Choose whether to Grab, Rotate, Scale. The user does not know these shortcut keys exist. The buttons on the toolbar that provide Maya style manipulators are not obvious, and not the recommended way of operating Blender. By now many people have quit. Even if they persevere, Blender has many other similar interface problems. Here's what I would like to see: 1. Change to edit mode. There is a larger button on screen that does this directly from Object mode. In fact, there should be four, one for Vertex, Edge, and Face, and one to return to Object. They are by default
Re: [Bf-committers] Transform tool tweaks
On Thu, Jan 19, 2012 at 11:33 AM, Yousef Hurfoush ba...@msn.com wrote: i patched and tested, clumsy: if you select and move right away it acts like hold and up (it transforms and confirms automatically!) , although i like the idea of holding and release on key up. I'm sorry. Can you explain this better? Break it down into steps for me to reproduce it and I'll see if I can fix it. On Thu, Jan 19, 2012 at 2:02 PM, Rainer Hohne raho...@googlemail.comwrote: Currently we have the choice of different interaction presets for users coming from a different package on the splash screen, so I would like to encourage you to make your changes accessible via this menu, keeping the interaction like it is for all who have grown accustomed to how Blender works over the years. I will be doing this. I do not wish to irritate existing users. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] blender UI state
On Thu, Jan 19, 2012 at 9:23 PM, Knapp magick.c...@gmail.com wrote: I know I did the first time I tried blender. The next time I found a video by gray-beard called something like learning the user interface and then all was good. I'd like Blender to be learnable without people having to go watch tutorials. The process of flipping to and from tutorial videos all the time is awfully disruptive. There's no reason it can't be more transparent. Yes it is really odd at first but I think it has persisted so long because it is a much better system. Sure, I believe you. I'm sure it is. I'm glad Blender is ahead of the curve in introducing new paradigms like this. I hear a lot of users say they enjoy Blender's right click select and that's great. Problem is, it frustrates the hell out of most users who have no idea why the left click doesn't select. It may be a better system but it's not one that any new users will be familiar with. Therefore, the default should be left click select. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Transform tool tweaks
On Wed, Jan 18, 2012 at 9:48 AM, Tobias Oelgarte tobias.oelga...@googlemail.com wrote: It bugs me that it destroys the option to add additional options to the tools by just pressing the same button multiple times. That is very quick and intuitive. I would not like to trade it against a press again to confirm. After much thinking and listening to feedback I'm going to find a way to update the patch to make this on option. I just learned about how RNA properties work with operators in Blender so it should be straightforward to implement. Then if this patch is used then you can keep the old behavior. I've been having some computer problems today but hopefully I can get it up before tomorrow. That is the main difference. You speak about simple interaction for new users. But i speak about fast interaction once learned. Yes this is a compromise to make. I disagree. I think that simple interaction and fast interaction are not mutually exclusive. In fact, I think my patch manages to keep interaction speeds (and in some cases make things faster) while at the same time making Blender more accessible to new users. I confess though, I am very concerned with new users. It's a primary motivation for me hacking Blender. After all, I am a new user, and one of the reasons I put off adopting Blender for so long is because of frustrations like the one I have addressed with this patch. I believe that Blender could have much more success if it made it easier for new users to adopt. In this sense I think Blender's user interface holds it back. It is my goal to address this, which is to everyone's benefit because more users == more developers, and more developers == more features. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] blender UI state
I'm glad that this topic is being discussed, as it is one of the primary motivations for me beginning work on Blender. Here is my list of things that I would like to see fixed, from a newbie's point of view: * There is a + to open the N properties (and other panels) but no - to close it. * Panels can be opened by dragging them out, but can't be closed by dragging them back. * The toolbar on the left is a good idea but is rough, some buttons are pointless and it needs to be neater. I would love to see the background panel disappear, and the buttons therein presented as floating buttons on top of the UI. Like how Silo does it. (http://goo.gl/7HChk See left.) This would give more area to the 3D view, which is what's really important. * I would like to see right clicking on things offer a Delete option. * When right clicking for some things there is no Rename option. * I would like to see a right click menu that provides copy and paste when right clicking text areas. * Why does pressing Ctrl-S prompt the user to save? Why would anybody ever not want to save when they just pressed Ctrl-S? What other program does this, ever? * Someone already mentioned that the button rows need to wrap and make a new row if they run out of space. I'll bet a lot of people don't know that you can scroll those things. But, you shouldn't ever have to. * When dialogs like the file dialog are open I always find myself clicking the Windows X button to close it, which closes Blender, often without saving my work. Needs another smaller (X) up there for closing the dialog without choosing a file. * I think it is inane that saving user preferences saves the entire current .blend to be loaded again with the File-New command. If I want to rebind a key in the middle of my work, it saves my entire project, and then I continue my work and next time I load Blender I am presented with an old version of my project. It should save only user preferences, like it claims it does. * In general I think the default Blender screen is too cluttered and should contain fewer panels. I think we can do away with the outliner and properties on the right, and also with the timeline on the bottom. If the user wants more panels, the user can create more panels. Advanced users already have their layout customized how they like it, presenting new users with 8 panels causes information overload, and turns people off Blender. So, a new user loading Blender for the first time might see something more like this: http://i41.tinypic.com/8yuet5.png I plan on working on many of these things, once I'm done with my work on the basic controls (see the Transform tool tweaks thread.) -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Transform tool tweaks
On Tue, Jan 17, 2012 at 11:42 AM, Knapp magick.c...@gmail.com wrote: It looks good but I would need to try it out to be sure. My one question is does RR still work? That is a command that I use a LOT. Sorry not familiar with the lingo, what is RR? Is it changing rotation type to and from trackball? Because yes that still works but I moved it to Shift-R. I'll be submitting a patch today I think. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Transform tool tweaks
On Tue, Jan 17, 2012 at 12:54 PM, Knapp magick.c...@gmail.com wrote: Yes, that is what it is. The lingo is just the short cut key(s) used to activate it. I am not sure I like having it moved to shift R because it still has not sunk in that I must use b and c instead of the old b and bb. Seems like a similar problem to me. Really I want BB back, but will not likely get it. I know that I am not the only one that feel that way. I have seen at least 2 tuts that complain about the BB change. Typing R or RR is very fast and easy to use. Having to reach to shift for a very common short cut key is a pain. I don't know about the rest of the users but I have a hard time hitting keys like shift ( I tend to hit cap lock instead). Still I am thinking that it is very likely new users will love your changes. Perhaps this is JUST IMOHO! I look forward to others reactions. Well let me ask you a question - which kind of rotation do you use more often, trackball or regular? I feel that if the more common rotation were default then it would alleviate this. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Transform tool tweaks
Then the solution I would suggest is to bind one rotation type to R and the other to perhaps Shift-R. It's the same amount of keypresses either way. I feel like, although the current workflow is changed by this method, the overall workflow becomes faster and more intuitive, so it's worth it. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Transform tool tweaks
A quick note just so we can all remain on the same page. When I'm talking about rotation in this topic, I'm referring to when the user is rotating an object and the view remains the same. I'm not referring to when the user is rotating the view. This feature does not affect view rotation. On Tue, Jan 17, 2012 at 3:29 PM, Tobias Oelgarte tobias.oelga...@googlemail.com wrote: Why not leave the default rotation at R and make the following possible: R = Start with default rotation Shift + R = Start with trackball Pressing either R or Shift+R again will toggle the mode. The feature I proposed in the top post of this thread makes pressing any transformation key (G, R, or S) a second time confirm the transformation. I made this change because I feel it is a more expected behavior to new users - If you press a button to enter a rotation mode then you should be able to press that button again to exit it. Not all users will expect this behavior, but I don't think many users (other than existing Blender users) would expect that pressing the button again should retain the new mode but modify it. The number of former users (again not including existing users trained on the current behavior) is in my opinion much greater than the number of latter users. In short, I expect that many existing Blender users may not like the key rebind, but I think that letting the user press the R button twice to approve the rotation is a more intuitive behavior than pressing it again to toggle. In the end though, my proposal is very similar to yours: R = Start with default rotation Shift + R = Start with trackball R again = Confirm the current rotation Pressing Shift+R again will toggle the mode. So it's the same, but pressing R again confirms instead of toggles, which of course is the whole point of my patch. I'm pretty satisfied with this patch now, I'll be submitting it shortly. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Transform tool tweaks - Patch available
The patch is now available here: http://projects.blender.org/tracker/index.php?func=detailaid=29919group_id=9atid=127 I would love it if people could try it out and inform me of any problems or suggestions. I would be happy to update the patch given feedback. Following is a reprint of the patch description: This patch is against svn r43478 Changes: * Pressing the grab/rotate/resize button while the tool is already active will cause the tool to confirm the current transformation. In the case of switching rotation modes, this functionality has been moved to Shift-R instead. * When using a transform tool bound to right click, right clicking will confirm instead of cancel; otherwise it will cancel like before. * Holding a transform button/key will drag the object. If the user holds for longer than 250ms or farther than 10 pixels then the action is treated like a drag and when the key is released the transformation is automatically confirmed. Notes: * This patch removes some duplicate code in the modal handler for transform events. * In order to support this patch some slight changes have been made in the way handler operators are called. Duplicate button/key presses are now filtered by the handler and not sent to the operator, and information about the handler/keymapitem which invoked the operator (if any) have been added to the wmOperator structure. * The previous event state also now includes the prevkeytime - the time that the previous keyboard key was pressed. Justification: This patch attempts to improve the usability of the transformation tools by implementing behavior which most users will expect. If a button is pressed once to activate a tool, than users can expect to be able to press that same button again to deactivate the tool. If the user presses and holds the button then the functionality should remain active for as long an the button is held down and then deactivate when it is released. In order to implement this behavior, the behavior when pressing the rotation button twice had to be changed. Before, the second press toggled the rotation type. This functionality has been moved to Shift-R. I recommend that the default bindings also be changed so that Shift-R activates rotation directly in trackball mode, to reduce the number of key presses required to access that mode. I feel that while the different behavior may cause some friction for some current Blender users, the new features should help users, new users especially, feel more comfortable with Blender. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Transform tool tweaks - Patch available
Thanks Martin I'd appreciate that a lot. I see you're the Transform module owner so it's good to know it's being looked at :) I tried to keep the workflow compatible with the current workflow. It should be entirely compatible with the exception of RR. If you have ideas of how to support both at once I would love to hear. On Tue, Jan 17, 2012 at 7:37 PM, Martin Poirier the...@yahoo.com wrote: Hi Jorge, I'll be looking at this as soon as I have time (probably on Thursday). Some of the changes (confirming with release among others) are stuff that I tried early on while porting transform to the 2.5 operator system and should be doable with the current keymap setup. If you want a workflow that isn't currently possible with the customization that exists, I generally think it's better to make the system flexible enough to support both (which might be what you did, haven't looked at the patch yet) and then discuss what the default keymaps/options should be. I'll get back to you once I've had a good look at your patch. Thanks, Martin From: Jorge Rodriguez jo...@lunarworkshop.com To: bf-blender developers bf-committers@blender.org Sent: Tuesday, January 17, 2012 9:25:07 PM Subject: Re: [Bf-committers] Transform tool tweaks - Patch available The patch is now available here: http://projects.blender.org/tracker/index.php?func=detailaid=29919group_id=9atid=127 I would love it if people could try it out and inform me of any problems or suggestions. I would be happy to update the patch given feedback. Following is a reprint of the patch description: This patch is against svn r43478 Changes: * Pressing the grab/rotate/resize button while the tool is already active will cause the tool to confirm the current transformation. In the case of switching rotation modes, this functionality has been moved to Shift-R instead. * When using a transform tool bound to right click, right clicking will confirm instead of cancel; otherwise it will cancel like before. * Holding a transform button/key will drag the object. If the user holds for longer than 250ms or farther than 10 pixels then the action is treated like a drag and when the key is released the transformation is automatically confirmed. Notes: * This patch removes some duplicate code in the modal handler for transform events. * In order to support this patch some slight changes have been made in the way handler operators are called. Duplicate button/key presses are now filtered by the handler and not sent to the operator, and information about the handler/keymapitem which invoked the operator (if any) have been added to the wmOperator structure. * The previous event state also now includes the prevkeytime - the time that the previous keyboard key was pressed. Justification: This patch attempts to improve the usability of the transformation tools by implementing behavior which most users will expect. If a button is pressed once to activate a tool, than users can expect to be able to press that same button again to deactivate the tool. If the user presses and holds the button then the functionality should remain active for as long an the button is held down and then deactivate when it is released. In order to implement this behavior, the behavior when pressing the rotation button twice had to be changed. Before, the second press toggled the rotation type. This functionality has been moved to Shift-R. I recommend that the default bindings also be changed so that Shift-R activates rotation directly in trackball mode, to reduce the number of key presses required to access that mode. I feel that while the different behavior may cause some friction for some current Blender users, the new features should help users, new users especially, feel more comfortable with Blender. -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ 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 -- Jorge Vino Rodriguez jo...@lunarworkshop.com twitter: VinoBS 919.757.3066 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
