- User Since
- Jul 20 2009, 6:53 PM (443 w, 2 d)
May 22 2015
Trouble with 'properties' is that we already have a Properties window type called that. It'd create unwanted confusion if there are two different types of areas with the same name.
May 19 2015
Nice! I understand the rationale between the two operators. However, I was not aware that Vertex Connect had been switched out with Vertex Path Connect using the same J key. Maybe it'd be best to keep regular Vertex Connect on the J key and the Vertex Path Connect on, say, ctrl-J or shift-J?
Hi, tested again on the OS X system. I couldn't reproduce it after all. Could just be an intel thing I guess.
Right now I'm at a Windows work computer where I get the same result.
These bugs make the skin modifier virtually useless, as you'll get these errors in most common cases. Would be fantastic to get this fixed!
Yup, way more sensible than the speakers. It's not audio, after all.
Dec 15 2014
Sep 26 2014
May 20 2014
Feb 17 2014
Jan 17 2014
Jan 14 2014
Jan 13 2014
@Adam Friesen (ace_dragon): That's a fairly important issue, but it's not really directly related to modifiers specifically. The way live updating works could be handled in a number of different ways. Probably the nicest way from a user perspective would be to have the view and UI elements be multithreaded, so that a slow updating viewport would not slow down the UI interaction. You always what the UI element to react instantly, even if it takes a while to update or display the result in the 3D View.
Yes, the Apply, Apply as Shape and Copy buttons could go on the same line as the enable/disable toggles, so that we don't add an extra row.
@michael knubben (michaelknubben): Yes, those are similar ideas.
Jan 9 2014
@Paweł Łyczkowski (plyczkowski): Seems good to me.
Jan 8 2014
Jan 7 2014
Maybe something that suggests extra speed or rough quality? Perhaps something that conveys 'playblast' rather than OpenGL specifically?
Jan 6 2014
Jan 5 2014
Updated original mockup with brighter text for the active tab like @jens verwiebe (jensverwiebe) suggested.
@Thomas Dinges (dingto): Yes that might be a good idea. Alternatively, we could place the plus at the top of the menu rather than the bottom. That way it would not move down with the list, so you could keep clicking + + + + + + + quickly to add seven items.
@Karja Krähwald (karja):
Ok, I'm trying to distill your points.
Figured out a way to make the radio buttons control clearer. It's now easier to see which is the selected item, using the same concept of 'empty widget' for the options that are not selected
@Paweł Łyczkowski (plyczkowski): yes, you are right that some controls become almost indistinguishable.
This is not directly related to this topic, but I'll answer your question:
Here are some examples of the difference seen in context.
The fact that text of the active is brighter is nice. It makes the active tab stand out more, and it's clear that it's highlighted over the other tabs.
@Campbell Barton (campbellbarton): For the tab metaphor to work, the active tab should have the same color as the area it relates to. That way, there's a connection between the area and the active tab. If the active tab is darker or brighter than the area it spawns, the visual metaphor breaks down, and it no longer looks like a tab.
Jan 4 2014
Ok, I split up the task. Hovering to hide/reveal information is here:
@Paul Andruchiewicz (unbekanntespezi): It already is still visible when you maximise the view. I don't get it.
@Campbell Barton (campbellbarton): The spacing is a definite improvement. Perhaps we can get rid of the I divider line though? It looks like part of the text and hampers the readability somewhat, and I don't think it's really needed.
@Jonathan Williamson (carter2422): That's true.
I think panel header should definitely have a different color. The above mockup and screenshot look quite strange to me though, when I look at them the first thing I see is the hierarchy inverted, as if the dark panel contents is above the light panel names?
@Scott Petrovic (scottpetrovic): While I see some value in increasing the header contrast, it doesn't really solve the main issue, which is what editor does the header belong to?
@Tycho TATITSCHEFF (tychota): Agreed, the border makes sense for colour swatches.
This makes sense. The use of meaningful units is important in Blender. This is an example of a place that needs it.
Would you like to create some new icons for this?
@Campbell Barton (campbellbarton): Yes that's true. They are not necessarily related. I could split this up to get two tasks instead?
@Campbell Barton (campbellbarton): I don't get the argument about it making the text in the buttons more cramped. If it only appears when there's nothing assigned, it doesn't make the text inside the fields anymore cramped at all.
@Paweł Łyczkowski (plyczkowski) also created these alternative icons in his mockup:
@Simon Repp (simonrepp): I don't think the issue you are outlining would occur, because Blender now has 'Continuous Grab' which means the cursor would internally stay put. Just try and drag a text field in a new build - you can drag forever :)
@Warren Bahler (russcript): right, that's a fairly good example of how the UI can become calmer going in this direction
Jan 3 2014
Yep, agreed from here too.
@Jonathan Williamson (carter2422): Indeed, this only requires changes to the theme.
I didn't propose a difference to the way we display IO options, but we could make them more compact by using tabs, like so:
Jan 2 2014
@Brecht Van Lommel (brecht): Agreed, makes sense, would be a great solution.
@Brecht Van Lommel (brecht): Ok, so it's like half the stuff in Particles it attached to the particle 'datablock', but the other half it attached directly to the object data?
@Brecht Van Lommel (brecht): Yes, it's true that we perhaps loose a bit of space this way. But you could still maximise the dialog if you want, so not sure it's really an issue?
Particles systems are not ID blocks and should not have an ID block browser. They can't be shared between objects so it doesn't make sense to choose them, you only have a list of them on an object.
Jan 1 2014
Yes, I think the Filter options (+ Show Hidden) could appear in a second row when Filter is enabled, like so:
Here are some updated mockups for improved File Browser design.
@Jonathan Williamson (carter2422): I don't think we should merge Bookmarks with System Bookmarks. I think we should merge System with System bookmarks. :) That way we have a clear separation between System stuff and Blender user stuff.
Dec 31 2013
@Simon Repp (simonrepp): Yes, the System Bookmarks is meant to reflect the bookmarks in the system-native file browser. It works on the Mac and afaik also on Windows, so that any folder added to the sidebar in Finder (or Explorer) also appears in Blender's System Bookmarks list.
This is a relevant issue, but I don't think it should be solved this way.
Dec 30 2013
How this will work in some areas is still unclear to me. For example object groups, modifiers, constraints, materials, textures, .. it's not entirely clear to me what would be displayed there. In general each object will have a list of things that may or may not match the others. Do you display that list only if it matches and otherwise blank or just for one object? Do you merge those lists (but do you really want to display all modifiers if you select a 1000 objects)?
I've been testing your patch, and it's a great visual improvement already. As @Jonathan Williamson (carter2422) mentions, if you are able to add vertical padding too it would be great.