Re: [Bf-committers] Patch [#36028] New 4-column layout for the editor-type-selector menu...
I am not sure what to make of these new layouts yet, imho it's more complicated to scan 3 columns with no description or misleading title, than scanning through the list we have know. So I am not convinced here yet. ;) Am 07.07.2013 06:53, schrieb Gavin Howard: +1 to the last 3-column layout with no headers. Gavin H. On Sat, Jul 6, 2013 at 10:36 PM, David Jeske dav...@gmail.com wrote: Maybe something like this, with 2 columns: http://www.pasteall.org/43817 Not saying this is ideal, but I think trying to fit everything in columns with a single title per column constraints things too much. I think any of these non-flipping layouts would be a big improvement. The reason I'm going wider is to keep the common views within mouse-reach when menu opens up. Below is a reachability comparison. I think the difference in everyday usability would be significant. (Keeping 3d-view close is one of the justifications I hear for today's flipping menus) http://www.pasteall.org/pic/show.php?id=55034 As for the headers, we could just drop them. They are not a very important part of layout waypointing, memory, or everyday usability. They are mostly for new-users to get some idea what the categories are. However, if there isn't enough ontological correctness they confuse more than help. What do you/folks think about this 3 column layout? .. with no headers http://www.pasteall.org/pic/show.php?id=55036 It's the same as your ordering, except I put Node-Editor with the main stuff on the left because I think the compositor is as good a main view / start-point as the other things over there. (ignore the kind of nasty extra space below Editor Type.. it's a byproduct of the current menu code and could be fixed) ___ 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 -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Patch [#36028] New 4-column layout for the editor-type-selector menu...
I find all new layouts proposed to be a big improvement over the current long list that is, in my opinion, too long to scan efficiently when looking for a window type. I'm always annoyed about myself taking 5 seconds to find the right one in there. These two here seem to be the best ones to me, the left one could possibly turned upside down so that the commons window types are at the left bottom: http://www.pasteall.org/pic/show.php?id=55034 Then again, distance from the button shouldn't be an issue - once you know where the button is, the mouse is there in a fraction of a second anyway. I also don't think titles over the categories would be bad, because you can only really memorize where which window type is found if you know what the categories contain. I never even noticed they were in categories already until now, but because they aren't described (and the lines are very thin), so they have no positive effect right now. This could also be a user preference setting imo. 2013/7/7 Thomas Dinges blen...@dingto.org I am not sure what to make of these new layouts yet, imho it's more complicated to scan 3 columns with no description or misleading title, than scanning through the list we have know. So I am not convinced here yet. ;) Am 07.07.2013 06:53, schrieb Gavin Howard: +1 to the last 3-column layout with no headers. Gavin H. On Sat, Jul 6, 2013 at 10:36 PM, David Jeske dav...@gmail.com wrote: Maybe something like this, with 2 columns: http://www.pasteall.org/43817 Not saying this is ideal, but I think trying to fit everything in columns with a single title per column constraints things too much. I think any of these non-flipping layouts would be a big improvement. The reason I'm going wider is to keep the common views within mouse-reach when menu opens up. Below is a reachability comparison. I think the difference in everyday usability would be significant. (Keeping 3d-view close is one of the justifications I hear for today's flipping menus) http://www.pasteall.org/pic/show.php?id=55034 As for the headers, we could just drop them. They are not a very important part of layout waypointing, memory, or everyday usability. They are mostly for new-users to get some idea what the categories are. However, if there isn't enough ontological correctness they confuse more than help. What do you/folks think about this 3 column layout? .. with no headers http://www.pasteall.org/pic/show.php?id=55036 It's the same as your ordering, except I put Node-Editor with the main stuff on the left because I think the compositor is as good a main view / start-point as the other things over there. (ignore the kind of nasty extra space below Editor Type.. it's a byproduct of the current menu code and could be fixed) ___ 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 -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ 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
Re: [Bf-committers] RNA-gen question...
It's just simpler code in makesrna.c to put them in each file. I don't mind having them in a separate header, could be committed after the release. On Sun, Jul 7, 2013 at 9:37 AM, David Jeske dav...@gmail.com wrote: When doing grep/searches tracing things from python-to-C, I sometimes have a lucky keyword that matches something in the rna-gen extern prototypes which are repeated in every rna__gen file. They look like this... extern StructRNA RNA_BlendTexture; Is there a reason these are generated into every rna-gen-c file, rather than being generated into an rna_prorotypes_gen.h that can be included by every rna-gen-c file? For example, like this... http://www.pasteall.org/43828 Is there some reason that's bad or not done? ___ 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
Re: [Bf-committers] Patch [#36029] improvements to spline behavior with a SINGLE handle selected
FYI - After much deliberation about feedback on BA, I've decided to take a different route than I did with Patch [#36029]. I am going to create a NEW version of this spline-fix-patch which fixes the tooltips, bugs, and adds rotation constraint visuals -- while leaving the current behavior untouched -- where handle-set always affects only selected handles. I will also fix the wiki documentation to match the current behavior. Why? I created this patch because I want the documentation, tooltips, behavior, and visuals to all match -- it doesn't matter to me which way it works, so long as it's clear. When I started, the only thing that I understood was the documentation, partially because the current behavior is not documented and partially because bugs in the visuals make it confusing. Now that I fully understand the (intended) current behavior, I see a way to fix the tooltips, docs, and visuals which will be (mostly) consistent with the current behavior. Some factors in my thinking: - While using patch [#36029], I have seen that 90% of the confusion with the current system can be eliminated simply by showing visuals for rotation constrained handles. - I can see the desire for handle-set behavior which only touches the state of the handle(s) which are actually selected. But mostly: I've realized that the behavior inconsistency is not possible to eliminate with *either* approach without breaking file-format compatibility -- something which I don't think is worth it at this point. That inconsistency is the overloading of align and constraint behavior, such that an align handle in align/free is rotation constrained, but in align/align is not rotation constrained. The overloading also has the side-effect that there is no way to rotation-constrain both handles. Other features which have been requested are also not possible without some amount of file-format conversion/confusion.. including rotation constraining both handles, and length-mirroring both handles. ... new patch coming soon. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Rigid body Ik armature system?
I have been messing with TorqueTrackTo and ApplyForceToTarget instead could I have a rigid body IK solver with max torques on all bones and input target angle or tracking object ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] int vs enum use?
Is there any particular reason (besides legacy) that many parts of the code still use int/#define, instead of using enums? Even though C-compilers don't typecheck enums, there is a documentation / readability benefit to using enums. Using enum-forward declaration avoids any header nastiness. For example ... void BKE_nurbList_handles_set(struct ListBase *editnurb, int mode); void BKE_nurbList_handles_set(struct ListBase *editnurb, enum eHandleSetModes mode); The latter is much easier to understand and investigate. I'd personally like to make patches which simply add the proper enum types to help document things for myself and others. Any reason not to do this? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] int vs enum use?
One reason is that you can't do forward declarations of enums in header files like you can do with structs. That means you have to include header files in header files, which is generally avoided whenever possible. I don't think there's a good reason #defines are used instead of enums to define the actual values, it's mostly out of habit / copying the style of other files. There is no convention in the code style guidelines at the moment: http://wiki.blender.org/index.php/Dev:Doc/CodeStyle On Sun, Jul 7, 2013 at 8:54 PM, David Jeske dav...@gmail.com wrote: Is there any particular reason (besides legacy) that many parts of the code still use int/#define, instead of using enums? Even though C-compilers don't typecheck enums, there is a documentation / readability benefit to using enums. Using enum-forward declaration avoids any header nastiness. For example ... void BKE_nurbList_handles_set(struct ListBase *editnurb, int mode); void BKE_nurbList_handles_set(struct ListBase *editnurb, enum eHandleSetModes mode); The latter is much easier to understand and investigate. I'd personally like to make patches which simply add the proper enum types to help document things for myself and others. Any reason not to do this? ___ 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
Re: [Bf-committers] int vs enum use?
On Sun, Jul 7, 2013 at 3:53 PM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: One reason is that you can't do forward declarations of enums in header files [in ISO C] like you can do with structs. I see my confusion. gcc has a non-standard extension to support forward declarations of enums, so it worked fine for me. However, it's not ISO standard, and as far as I can see MSVC doesn't support it. http://stackoverflow.com/questions/7480217/c-forward-declaration-of-enums ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Color management broken?
Is there a reason that the color management transforms do not work on EXR files saves? Seems broken. With respect, TJS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Patch [#36028] New 4-column layout for the editor-type-selector menu...
Imho, alphabetical means not quite ideal for i18n UI display. In fact, the current list already got well-classified if looking closely a bit. However, if there really needs to be any goal for quick look-ups, I think a better solution would probably be trying to stress the role of icons, since images usually are more easier to identify than texts, everyone likes them. I mean, just imagine a software without icons :). In orther words, I mean it would be to* scale the default size of those icons a little bit* for the more eaiser and quick identification, probably. Second solution: Probably it could be considered to try *adding Shortcuts display* for them, I mean the current Shift + F1 to F12 thing. I know it's the most simple trick for all experts, which is well-known for sure. However, for new users? I doubt so. So, it may protencially suggestting those who want to use as many shorcuts as they can (and will) a more direct way to switch among editors. On Sun, Jul 7, 2013 at 10:45 PM, Harley Acheson harley.ache...@gmail.comwrote: I still think this has nothing to do with the list being too large. The order of the items on the list changes depending on whether it pops up or down, so we can't just remember them visually by location. And the order is non-visual so we have to do a linear scan instead of a binary one. We have to read almost all the items almost all the damn time. If we didn't do the swap, we could have any arrangement of items and it wouldn't matter much because they would stay in the same place. 3D View would always be at the top, and the item that is 1/3 down would always be there. Make the order *alphabetical* and we can then do a binary scan to find the items instead of a linear one. Combine the two and we could make the list much longer and we could still find items in it faster that we do now. Cheers, Harley ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Leon Cheung a.k.a. 老猫 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Patch [#36028] New 4-column layout for the editor-type-selector menu...
Short of a big overhall, there are also simple things we can do. The following shows the current menu on the left. On the right there has been some margin added to the left of the icons so they are not scrunched against the left. The separators are made a lot less invisible, and are not extended to the edges. http://www.pasteall.org/pic/show.php?id=55110 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Patch [#36028] New 4-column layout for the editor-type-selector menu...
This layout I like if the dividers were a little Dimmer as they are now it makes the menu too busy visually On 8 Jul 2013 14:17, Harley Acheson harley.ache...@gmail.com wrote: Short of a big overhall, there are also simple things we can do. The following shows the current menu on the left. On the right there has been some margin added to the left of the icons so they are not scrunched against the left. The separators are made a lot less invisible, and are not extended to the edges. http://www.pasteall.org/pic/show.php?id=55110 ___ 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
