- User Since
- Jul 20 2009, 6:53 PM (482 w, 11 h)
Sep 5 2018
Aug 29 2018
Aug 28 2018
Aug 27 2018
Aug 23 2018
Aug 22 2018
Aug 21 2018
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.