Agreed @Bastien Montagne (mont29), removing the delta location shortcut is preferred.
Jun 11 2018
May 7 2018
Dec 11 2017
Nov 14 2017
If we need to have both systems, then I think it should probably be the active tool that shows in the top bar instead of the redo properties. Since I guess the hierarchy then is more Mode > Tool > Operator, and anything modal should probably be clearly indicated at the top of the workspace.
Oct 31 2017
I believe we can close this now that Collections are mostly implemented? This no longer applies.
@David (activemotionpictures) sorry but this is not the right place for these proposals. You can create a WIKI page if you with the proposal. Design Tasks here should only be created by the UI Team or a developer after it's been discussed and approved.
In 2.80 the proposal is to still support multiple output nodes, and have the last selected one as the active. However, instead of storing it per material, we would stored it per material, per engine.
The majority of the issues related to displaying the Operator settings would be solved if it can be placed on left or right of the screen.
To be sure I follow, the current proposal is to support a single Output node, with it outputting the correct data per engine behind the scenes? Such that the user doesn't have to change anything?
To pick a different example, say we add edit-mesh Edge Rotate as a tool:
Having to select, then click anywhere on the screen to rotate the edge - is awkward.
Single click to rotate the edge under the cursor fits in with what I think users expect.
I see this as the one major problem we have with the current top bar/tool settings and tool system. It works great for most tools, but not so well for those tools that're editor-specific (knife, extrude, uv pack, etc). I don't have any good proposals to improve this. My only current thought is that it may be worth considering keeping the tool settings in editor-specific headers rather than tied to the top bar.
They could draw differently and in general they shouldn't be mixed in with regular operator buttons (they should get their own panel, at least be visually separated. placing them next to regular operators will be too confusing).
My gut reaction is to go with option 1, but I can see how option 2 would make more consistent sense so far as overrides go. If I had to choose I'd go option 1 right now.
I pretty much agree with all of these, except the pop confirmation for delete.
Mar 13 2017
Testing on Ubuntu Linux with Unity desktop, it seems to be working correctly.
Here's a patch on top of this diff to simplify the UI to a single Interface Size setting relative to the system DPI. It also keeps the UI size the same for existing user preferences.
It would be good to hear from the UI team if they agree with this simplification.
Jan 20 2017
It is useful for example for installation of some plugins which are placed in 'Scripts' folder. For example Blend4Web SDK use this installation method. And many artists use SDK instead of plugin due to it's advantages.
Dec 29 2016
My thought is that icons should only adjust sizes with DPI changes. Otherwise UIs (particularly add-on UIs) will very quickly become inconsistent and break visual alignments.
Nice changes @Mike Pan (mpan3). At first glance I don't see any issues!
Dec 21 2016
Nov 16 2016
@West (Formula409) can you provide some specifics that're actionable? In the keymap revamp we're working to address many of these observations, but without specifics there's nothing we can really take away from your feedback other than it's difficult, which isn't particularly helpful.
Sep 25 2016
Fantastic, thanks @Julian Eisel (Severin)!
Sep 20 2016
@Julian Eisel (Severin) wrote:> That being said, I'm afraid we've by far surpassed the point where we can improve anything or prevent something from getting too bad without major reworking. So TBH I don't think we should bother with this any longer and just fix this inconsistency by apply this patch.
Sep 19 2016
I'm conflicted on this. This is more of a fix for a previously missing component, like @Paweł Łyczkowski (plyczkowski) said, but at the same time there are many, many missing theme items like this. If we approve every one of them on the basis of it being a "fix" then we still have the problem of excessive theme items.
Sep 16 2016
Sep 5 2016
Aug 3 2016
Looks good to me.
Apr 27 2016
Yes! This is a great improvement @Brecht Van Lommel (brecht). Consistency for the win.
Apr 26 2016
@Albert (wevon) I'm not quite sure how filling open combinations on the keyboard+mouse specifically applies to this discussion, much more applicable to T37417, but either way we should be careful about just filling all the "empty space". Doing so greatly restricts artists ability to customize hotkeys to their liking.
Apr 25 2016
@Paweł Łyczkowski (plyczkowski) interesting idea with widgets on the boundary of the selection...I have a hard time imagining it working in practice, though. The main reason being that your handles would be constantly moving with the view angle and would require constant recalculation in order to not obscure the selection. Additionally it presents the problem of the handles being very far apart from one another (in many instances), requiring much more mouse movement to manipulate them. Extra mouse movement needs to be avoided to reduce fatigue.
Seems to me we (perhaps @Paweł Łyczkowski (plyczkowski) and myself?) should take some time to define a baseline modal interaction design parameter for other devs to work off. Otherwise we're just going to continue running into differing implementations like this that cause problems with one input device or another.
At risk of opening a lengthy discussion, I think it might be worth stepping back for and asking what do we want to enable the artist to do?
Apr 18 2016
Mar 23 2016
Ah one quick change @Mikhail Rachinskiy (alm).
I'm happy with this now. Big improvement over status quo.
Mar 15 2016
Archiving for inactivity.
Mar 8 2016
Agreed @Campbell Barton (campbellbarton), better to make more specific tasks in future (note to self).
Unless there's anything else I suggest we close this out.
Closing this for inactivity and no clearly needed changes against current design. If issues arise will create new task.
Good call @Campbell Barton (campbellbarton). I'll close and create new, more specific ones as they come up
I'm with @Campbell Barton (campbellbarton) on this one. Unless there's a very clear icon change, that makes good sense, then it's better to leave as is for the sake of manuals. I think we mostly all agree that the F is a bad representation, but none of the other proposals are all that much better in my opinion.
@michael knubben (michaelknubben) I don't off the top of my head, it's been a while. We can bring this back up during the UI meeting if needed. The Save/Delete popups are the most drastic changes, so if anything are worth discussing again.
- Make scaling acceleration based. fast movements can change values at a higher scale.
- We could detect when the cursor stops moving the mouse and reset the non-linear-scale. (So fast motions can be non-linear as they are now, but slow motion after can still be precise).
- Non linear scale could be rounded to more even units. (so its always scaling by 1x, 2x, 5x, 10x... so as not to give such *random* looking results).
All that said, I rather only do these if its really clear improvement - and I have the impression they're more like small tweaks which some users like but annoy others.
The first 2 suggestions for eg rely on dynamic scaling, which may sound handy, but means moving cursor to original location won't have the same value.
Mar 7 2016
@Julian Eisel (Severin) if we're able to address the issue of showing the keymap in the tooltip then this can probably get committed. I'd like to give it a run through again, though, just need to pull down and compile when I've got a moment.
After some thought, maybe uniform scale widget is overkill... I can't think of a design where it would not just clutter the whole thing. After all one just needs to press S to scale.
Right, can't think of a good way either. I'm open for ideas though.
Sounds good @Brendon Murphy (meta-androcto). I see no issue with waiting 'til 2.8 for merging.
Sorry guys, this got lost in my email. Agreed to close, thanks @Bastien Montagne (mont29)
Feb 29 2016
This looks good to me @Brendon Murphy (meta-androcto). The latest revision is a very good improvement on 2.76, and the updates for Object Data in place of Relations is much clearer to me as well.
for spot size widget aperture size appearance, a cone (the yellow one) instead of an arrow :-)
@blend-it (blend-it) this task is specifically for the Transform widget.
Toggling Visibility of Widgets
Draw a panel for the active object in which its widgets can be enabled/disabled individually (similar to "Display" for cameras).
Add a toggle button next to every button represented by a widget (similar to how it's done in the transform panel in the properties region, where you can press the 'lock' icon to disable the widget for this axis)
Feb 25 2016
With this coming up in the mailing list again, thoughts adding this as a user prefer after all @Julian Eisel (Severin)?
Feb 17 2016
Maybe we could do something closer to what we had originally - you choose metric, then presets are shown only for metric.
Feb 16 2016
These are very good changes @Mikhail Rachinskiy (alm)
Feb 15 2016
I've not tested this yet but also major +1 from me for usability improvement.
Jan 16 2016
Jan 13 2016
Jan 1 2016
Dec 16 2015
If push comes to shove, I'm also fine with the eye icon, though :) It's better than the material orb.
This is a good suggestion. The material orb really doesn't make any sense here.
Oct 26 2015
Oct 25 2015
A lot of this may be irrelevant with 2.8 if we're able to get the shading workflow in place.
Many of these issues will be (attempted to be) addressed in the upcoming, simple keymap: T37417
Oct 6 2015
It would seem it is indeed something with my user preferences.
Oct 4 2015
Sep 21 2015
Agreed on the filled draw-style @Campbell Barton (campbellbarton). I also find it more aesthetically pleasing.
Sep 18 2015
This is the super old version. If I find some time I may resubmit the updated version but for now it's good to close. Thanks @Brendon Murphy (meta-androcto)
Sep 9 2015
@codemanx I was referring to the ability to explicitly start a new line with \n and whether it was supported when defining tool tips in Python for new operators.
I'm actually confused as to why people seem upset/concerned that the UI Team made their goals for the LMB input clear. What is wrong with the UI Team stating upfront that they intend to change the default?
@Benjamin Tolputt (btolputt) it was more of an issue of miscommunication with goals and intents. I've updated both the parent task and this one to better reflect actual goals and status.
Ignore me, clearly I should get more coffee. I completely mis-read that.
I should add, I'm not convinced that the core issue is actually a problem because we already change out the icon on the menu to be the current selection. In other words a new user can learn what editor is active by what icon is displayed. Seems to me this is more effective than a highlight of some kind would be.
@Campbell Barton (campbellbarton) D1450 works well, although personally I find it weird. I find it weird because when I open the menu I immediately feel like my cursor has jumped, since I'm expecting the highlight to be at my cursor location. Admittedly I've never really found the original issue to be a problem, but that could simply be experience.
That's nice @Campbell Barton (campbellbarton)! I don't really agree with the idea of having full paragraphs in tool-tips but supported multiple lines is really valuable.
Maybe that's something that can be tackled in T45352
Might be worth updating the details then :)
I like this @Julian Eisel (Severin). Is the red being pulled from the theme? In my testing it doesn't seem to be, but it probably should for the sake of compatibility with themes.
This is a nice little feature @Marcelo Mutzbauer (1xundoredo). It works quite well from the user side (I cannot speak to the code side).
The new keymap needs to be created, evaluated, iterated on... after that a decision would be made.
Yup agreed, which is really where we are at now. At the end of the day the keymap may get rejected and that's okay; but as it is right now the goal has been to create one that uses LMB default.
Sep 8 2015
Absolutely @Diego Gangl (januz). So long as we successfully use Action / Selection inputs everywhere then it should not be an issue. Most likely we'll run into a few hard-coded areas that'll need resolved, but that'll be tackled when we get to it.
For what it's worth, my understanding of the consensus over many discussion was that we'd move to LMB in the new keymap by default but with the ability to switch instantly as preferred. Technically this is already doable in the current keymap, but there's lots of conflicts and problems. Of of my goals with this new keymap is to resolve those conflicts such that LMB/RMB switch actually works as it should.