- User Since
- Jul 20 2009, 6:53 PM (500 w, 4 d)
Thu, Feb 14
Jan 22 2019
Dec 16 2018
Dec 4 2018
Nov 29 2018
Nov 22 2018
Nov 12 2018
Nov 9 2018
Nov 8 2018
Oct 21 2018
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.