Made the very two one pixel wider (14x15) but it shouldn’t be a problem, since each icon pokes out of 14x14 matrix with dot of just two pixels. Goodbye lil’ fishies.
What do You think about replacing the wrench with a hammer in Tools icon, @billrey? To me wrench is perfectly ok.
@Alberto - no, his avatar has different colour 
At least I can spot it 
I told to bill, because he confuse me with him
Any consensus on splitting out the keyframe left/right icons to the right as I advocated for above? I think it makes it easier to deal with and more visually balanced.
Honestly it’s probably just a matter of visuals, as hardly anyone uses those buttons afaik. It does look a little cleaner to me.
I’m glad you’ve got a version you’re trying out.
Design wise you did a nice job on the version with the wrench, but in practice it’s confusing to have two icons in the properties panel that include a wrench (I’ve seen it trip people up dozens of times already.)
Please concider making this change, it will save many newbies and teachers so much time.
It’s even worse when helping someone online and I can’t see which buttons they are pressing, they assume they have clicked the “wrench icon” for modifiers, when in actuality they clicked the tool settings, and now I’m stuck trying to help because of the miscommunication.
Please please please @billrey @jendrzych consider swapping the wrench in the tool settings icon before the UI freeze.
just out of curiosity and digging up a bit in the history of blender. Why someone thought it would be a good idea to use a wrench for modifier icon ? Wouldnt other symbol be used to describe the nature of modifiers as nondestructive and ultimately …layers ?
because wrench tool is one of the standard icons for modyfication. the gear is usually for settings and the tool icon isusually for tool or when u want modiffy something.
That was my suggestion too, I think it would work nicely.
Splitting out the keyframe buttons to a separate group seems like a good idea to me as well.
The other buttons are rather playback related, whereas the keyframe buttons are more animation related. Furthermore, I think that it’s common to skip back and forth between keyframes, which is much easier if the buttons are next to each other.
Not sure if the latest icon draft works for this though:
Initially, the idea was to add “next/prev frame” buttons.
I don’t really see any point in adding the prev/next frame here. You can already do that in the current frame number field on the right - it already has arrows to go to prev & next frames.
but you have to move your mouse in another place
@L0Lock You don’t click anywhere to move from one frame to another. Who wants to work that slowly? You press the arrow keys on the keyboard. No need to add additional oversized buttons just for that. That area is wide enough as it is.
With that logic there shouldn’t be any buttons at all.
I like the simplicity: [record button] [4 playback buttons] [left/right keyframe jump buttons] and then using the left/right arrows on the current frame indicator on the right side. If you start bunching up more than four buttons in one place it becomes hard to see and navigate without excess thought. I’d like to strongly advocate separating the keyframe jump left/right buttons to the group to the right, because they are not related to playback like the other four buttons are, so they should not be mixed. It’s certainly a very fast thing to change in code, is it possible for this to be done today before the UI freeze?
Yes, that’s exactly what my Blender looks like most of the time.
This is all it takes @Keavon
diff --git a/release/scripts/startup/bl_ui/space_time.py b/release/scripts/startup/bl_ui/space_time.py
index d2c41f13ee3..b6dede30e01 100644
--- a/release/scripts/startup/bl_ui/space_time.py
+++ b/release/scripts/startup/bl_ui/space_time.py
@@ -42,7 +42,6 @@ class TIME_HT_editor_buttons(Header):
row = layout.row(align=True)
row.operator("screen.frame_jump", text="", icon='REW').end = False
- row.operator("screen.keyframe_jump", text="", icon='PREV_KEYFRAME').next = False
if not screen.is_animation_playing:
# if using JACK and A/V sync:
# hide the play-reversed button
@@ -58,9 +57,12 @@ class TIME_HT_editor_buttons(Header):
sub = row.row(align=True)
sub.scale_x = 1.4
sub.operator("screen.animation_play", text="", icon='PAUSE')
- row.operator("screen.keyframe_jump", text="", icon='NEXT_KEYFRAME').next = True
row.operator("screen.frame_jump", text="", icon='FF').end = True
+ row = layout.row(align=True)
+ row.operator("screen.keyframe_jump", text="", icon='NEXT_KEYFRAME').next = True
+ row.operator("screen.keyframe_jump", text="", icon='PREV_KEYFRAME').next = False
+
layout.separator_spacer()
row = layout.row()
– It is not clear whether this icon means MMB clicking or wheel scrolling.
– It currently looks like click.
– While should be click and drag. (for the Rotate View)
Or not, it is not clear…
UPD:
Ok, this two icons mean “Middle Mouse” and “Tweak Middle” events,
but still, for example for Rotate View, it looks wrong from a user perspective.
You deffinitely should repost this in the Paper-Cut section. Or even better - start there a thread “misused icons” with this very issue as first post. A thread for reporting wrong use of existing icons, but not related to design issues. Low hanging fruits I mean. I bet there’re tons of such tiny bits to track down.
It’s tricky to fix. The status bar items are automatically generated from the keymap. It’s similar to the right-click menus:
It would be nicer if it read ‘Context Menu’ but internally it is calling an operator called Call Menu which then refers to the context menus.
Ideally, it would actually put the name of the menu it refers to there.