- User Since
- Nov 27 2010, 3:30 PM (373 w, 2 d)
Apr 29 2014
I am going to go MIA on this for a little while. I was starting to spend some time getting this all re-arranged in C (was struggling with externalizing everything Python). There is another open source project I that has my heart right now and need to switch gears to for a little bit (Krita).
Mar 29 2014
Mar 28 2014
@Alessio Cappini (lsscpp) - that is a good idea, but that might not fit in with what this thread is about. That feature already kind of exists. If you are opening a file and go into grid view, it will show you a preview as the thumbnail. Is that good enough?
Mar 2 2014
I like this! +1. I can't speak for how it is implemented in the patch, but adding commas makes large numbers easier to read. It would be nice if this would carry over to make it more global, but that might be too much work for now.
Feb 11 2014
The topology tools are almost as important as changing your brush size in my opinion, so I think it needs to be visible as much as possible. Dynamic topology also seems to turn itself off in quite a few situations, which can be trouble when you are "snake hooking" or using other brushes. Unless you have wireframe on, it can be hard to tell if you are just pushing vertices around or tessellating them.
Feb 8 2014
@Bryce C (BC369) I think a lot of people also agree with the end goal of moving all headers consistently to the top, but the info area needs to be modified before something like that can happen. Your mockup completely removes the info space which contains file, window, help, etc. Having two menus right on top of each other needs to be addressed first. There is already a lot of discussion about ways to update the info space that is going on here
I think the deeper issue is that the UI is currently too inflexible to have a good solution for the grease pencil. The grease pencil isn't going to be very easy to use because it has all three of these areas. Fixing the issue here will make it inconsistent with the current UI patterns that we have. The current separation with tools seem to be this.
Jan 29 2014
@Jonathan Williamson (carter2422) I like this arrangement for the tabs. I was just playing around with sculpting and moving a lot of these things to other tabs will really clean it up. To your point, many of the options aren't used much, so they really can be tucked away under the new tabs.
Jan 7 2014
@William Reynish (billrey) - I am personally not in favor of having tabs by the options. Exporting options are usually done as a separate step in most applications. You pick your file to save as one step, click save/export, file browser disappears, then a modal window shows up up with additional options for exporting format.
@Andrew Buttery (axb) maybe campbell knows what is going on. That is one reason why I originally listed has as a reviewer because I thought he might know something about the history of these two properties.
Jan 6 2014
@Andrew Buttery (axb) nice!!
Jan 5 2014
@lonarn - The menu is partially contextual, so if you don't have a 3D editor open, it won't display any 3D options. Things like Scene and layout selection will always be visible.
Jan 4 2014
I am sure it is possible to add it into the code base. This feature is almost done, so adding that might be better as a new task. For now @Brecht Van Lommel (brecht) suggested putting separator() instead of the empty space. That should be ok for now.
@William Reynish (billrey) good point. The contrast shows that it is a header, but doesn't really associate which editor it belongs to.
+1 Rounded corners are a good idea to separate the spaces.
@Jonathan Williamson (carter2422) - the icon_only works with RNA properties, but not menus (just tested it). I can't find icon-only menus anywhere else. I have to manually add empty spaces to the menu text parameter, otherwise the icons go outside of the button and look odd.
Jan 2 2014
I agree that the modal window is a slightly better option since you don't have to worry about the info bar. It is one of the few instances when info bar isn't relevant to what you are doing (user preferences being the other). It isn't a major issue though. The non-overlapping aspect is a little cleaner with leaving it in its space. The file name on the bottom isn't that critical either. It is on the top on Mac OS, so it isn't that odd to have it there. I think as long as the filters and operations are in close proximity to the respective fields, that is most important.
Jan 1 2014
@William Reynish (billrey) nice mockups. This looks nice! I agree with your points in yellow with the first attachment. This is the direction I would go as well.
Dec 30 2013
I created a diff. This patch can be closed.
Dec 29 2013
@William Reynish (billrey) Some good points.
I tried making a diff, but it doesn't like uploading it since I included a PNG file with a new icon. It keeps giving me an exception when I upload the zip file. I usually use Diffs when it is just text changes. Maybe I am not doing it right.
Dec 27 2013
cool, that is what I was thinking. Icons were done elsewhere and has an icon argument in C, but didn't know how well it was implemented with menus since I couldn't find it. I will see what I can do! thanks.
I can try to start coding this one. It looks like it will be just some python changes and a little bit of C (removing +/- from header). I haven't seen icons for menus before, so need to do some research on best approach. Icon menus usually have been for showing enums. Maybe there is an optional argument for icon with menus?
Dec 26 2013
These sound good to me.
ok. The current proposal is better than it currently is, so I would be ok with Brecht's suggestions. I guess I am stuck on the whole "collapsible menu" idea. I just don't like that concept since it isn't used anywhere else like that (to my knowledge). Other applications seem to find solutions to avoid needing something it. "Creative" UI solutions aren't usually the most user-friendly - but I guess the only people that will have to deal with it are advanced users for the their special cases.
@Campbell Barton (campbellbarton) - great point with other interfaces that are using that system.
Dec 24 2013
I think we need to still leave the functionality in for advanced users, but have the +/- button removed from the header. For advanced users who really want fine tuned controls, I think it would be ok to leave it in a context click menu.
@Brecht Van Lommel (brecht) - in regards to your screenshot, would this only be visible when the menu is hidden? It looks nice, but this would also create two different workflows for showing and hiding the menus.
@Brecht Van Lommel (brecht) will people accidentally "lose" their menus if the "+/-" button is completely removed (save the context menu option)? This potential confusion seems very specific to Blender. I have not seen this functionality in any other program I have come across. It doesn't seem like an intuitive system to continue.
I see. It is partially helpful for that situation (depending on what your monitor resolution is). I can see all of the layers on my screen, but I have a 1920x1080 monitor.
I would be ok with leaving it in the right menu. Just to clarify, this would potentially be removed from all spaces, not just the info space that I highlighted.
Dec 17 2013
@William Reynish (billrey) That sounds good to me. I am not very familiar with dealing with physics and rigidbodies in Blender. I haven't really used them in Blender, so forgive me for my ignorance. :)
What about these shading options?
Dec 10 2013
@William Reynish (billrey): the main point is that this tools is more complex than what is shown. Condensing the tool to one area isn't going to fix the fundamental issue. It needs to communicate better with what it is doing based off of the context (selecting one object, selecting multiple objects, etc).
These transform properties seem to be doing a lot. Maybe the object properties isn't the best place for this. It is used in quite a few contexts outside of just object properties (edit, multiple selections, other?). It is obviously confusing people, including me, about what it does.
Dec 9 2013
sounds good. We can just leave it as is for now.
I see. Maybe this is a larger discussion for later on what needs to happen. I have noticed some conflict between what goes in the 3D View settings and the properties space. They seem to have an ambiguous relationship currently. I also see other things repeated like naming the object in both places.
diff in review D81
This is pretty minor. I can work on a fix if no other devs want to worry about it (if it is actually a bug)
thanks Brecht. Shoot, I didn't realize that code was in a PHP file. I could have done that. thanks.
Dec 8 2013
I agree with @William Reynish (billrey) that we need to use one paradigm for tabs. Whatever we decide, we don't want different implementations for how to change tabs.
This is a good idea. I didn't even know this information was stored twice.
I just tested this out and they appear to be doing exactly the same thing. The lock options update each other when they are changed as well. I am not clear on how the transform tools are different. If they are, the UI doesn't isn't communicating it.
Dec 7 2013
I would vote that these tools are moved to the properties space under the physics tab. I would put them under the rest of the rigid boy tools when rigid body is enabled for the object (Rigid Body, Rigid Body Collisions). I don't believe these operations exist anywhere else on the UI, so I wouldn't just completely remove them.
Dec 2 2013
If no other developer can work on it, I can try to do this myself.
Dec 1 2013
I don't think the window needs to be made larger with this change. You already have to scroll with most of these panels (including the one in the screenshot). It will just add a little more scrolling to what is existing. I think just the Python changes would be sufficient.
Nov 28 2013
The screenshot includes just one instance for reference. This issue could include looking over all of the user preferences areas to make sure spacing is consistent.
Nov 25 2013
I personally think a beginner would have no idea what "auto-pack" even means. I would think it would flow better to prompt the person when they load an external file that is greater than XXX MB if auto-pack is enabled. When they hit upload, let them know what uploading large files will do, and give them an option to disable auto-pack there.