- User Since
- Mar 7 2010, 9:01 PM (466 w, 6 d)
I thought this “line width” was intended to only affect lines in the 3D editor? With it changing everything it makes it more complex to determine how big something is since this is independent of user scale. We currently have a very large number of unnoticed “off by a pixel” errors because of this.
Fri, Feb 15
I guess I'm the only one who thinks this is not an issue
Well ignoring any political aspects to it (just don't mention my name. LOL), the parts to be thought through carefully are mostly about "extending" selection while changing modes.
This is not just a cosmetic issue...
To be honest, I don't think the first solution could be implemented in practice because the howls of protest would be unbearable. LOL. But it could be thought through. I had suggested using ctrl-click for current behavior, but that was wrong. That suggestion was really about just swapping the default behavior with the current Shift behavior. And we do have some (fairly) consistent rules on how shift, ctrl, and alt change selection behaviors.
Another, less extreme idea, that does not require any behavior changes.
Probably not an acceptable answer, but...one thought is to not (somehow) highlight hidden behavior, but remove the hidden behavior...
Although I do agree that this can be dealt with in a number of ways, I think we should *ALSO* make the default starting theme show a small amount of opacity for those areas.
Thu, Feb 14
Fixed with this commit:
Mon, Feb 11
If this gets approved and committed I will then propose adding some more cursors as per Gavin's suggestion: Four different "hover" cursors for the corners so you can see which zone you would hit.
Sun, Feb 10
No worries, just playing with the idea.
Thu, Feb 7
I don't understand the rationale behind your points...order should be reversed, like it is on the rest of the menus.
Just in case my long explanation was unclear...
Wed, Feb 6
In fact there will probably be more collapsible sections in popovers in the future
First, I love the idea of editors always having an (optional) header on top and (optional) footer at bottom. So I am very in favor of removing the option of headers on the bottom.
Tue, Feb 5
Mon, Feb 4
Yes @William Reynish (billreynish), this method is definitely an improvement in the vast majority of cases. And is now no worse, and probably a bit better, at the extremes.
Okay, my previous idea about the keyframe colors were dumb. I cannot manufacture a kind of "yellow" that is recognizable as yellow when shown against a white background regardless of what shadows are used.
Actually there might not be too many worms in the can...
Yes, when that second line, draw_selected_name(), is shown there are some instances where the text is not intended to be white. I did nothing with those because I didn't quite understand their usages. The only thing changed it is that they would use the same shadow as the other overlay text.
Sun, Feb 3
Yes, I can't anything that breaks it.
I added an "icon_color" member to wmGizmo (to go along with "color" and "color_hi"). That way when it is about to draw the gizmo icons it can get the colors from there instead of just using TH_TEXT. Since that is populated from the View3D values this means that the icons can be different if you have multiple 3D viewports open with different backgrounds.
if Shading Type is Rendered, then ED_view3d_background_color_get() will return an arbitrary dark-ish value that results in strong white text, dark shadows, etc
- Saving Text color, shadow, scrim color in View3D's overlay struct
- Draw viewport name overlay with View3D text color
- Draw selected name overlay with View3D text color
- Clamp text color and shadow colors to (0-1)
- Gizmo uses View3D's scrim color
- Replaced gray approximation with more accurate multiplied version
- Overlay text shadow size increased back to 5 (original value)
- Scrim behind navigate widget gets lower opacity
- Scrim color (circle behind widget) always increases contrast
Sat, Feb 2
About the only thing "controversial" in here is the idea of overwriting the area's theme colors TH_TEXT and TH_TEXT_HI and making their values dynamic instead. But I like that idea the most as it means that anything trying to write to the 3D viewport, even with python, will get the benefit if they use those colors.
If we had to do just one of the two patches, it is this one to look at first.
Wed, Jan 30
Thinking this through, there might be some ways to improve it to make it fit with other ideas....
Tue, Jan 29
to be fair I think what you already did is neat
That does look pretty sweet. But...
The times this helps the most is for light icons on a lighter background.
Could the soft shadows not be drawn outside the icon boundary?
Yes @William Reynish (billreynish) the shadow size is fixed.
Whoops, meant to add...
Mon, Jan 28
Sun, Jan 27
The changes in here are independent of my proposal to nudge the corner zones right into the corners, so both could be done or neither. But the two patches do touch some of the same areas so there could be commit conflicts. So if one of these is committed I will then update the other.
Thu, Jan 24
Wow, zombie task from 2013.
Not to pedantic but there might be some things to think through with cursors...
Wed, Jan 23
@William Reynish (billreynish): I haven't found a cursor editor that directly supports this older format. Not that I mind the lack of color though.
Forgot to mention @William Reynish (billreynish), that if things work out how I hope they will, then I might be making some new custom cursors.
I've just been making comments on this task because I didn't know where else to comment since patches get closed.
Okay, the patch was accepted that added a (small) threshold of movement before action is taken, regardless of where in that corner zone you start at. It also makes the zone slightly taller.
Tue, Jan 22
Yes, I've seen those mockups. Unfortunately that is beyond my puny skills with the Blender source, which seems best suited for moving things around by one pixel. LOL.
There was a small non-breaking error.
No, that would be well beyond this type of patch. This is just the first part (of a few?) that should make the actual drag in and off those corner splitters a bit better. I am wanting to make them easier to hit, have less precision needed to use, yield less accidental incorrect operations, and (maybe) have some feedback during operation.
Hmm... I see a small error in there.
Mon, Jan 21
Please note that this patch has overlap with a different patch and so now this (small) change has already been made.
I am now testing a patch that pushes those corner action zones right into the corners, as I mentioned earlier. It does make it much easier to do these split/join operations when the two adjoining areas are not separated by the "move" area.
The amount set for threshold before action is taken is 0.2 of a widget_unit. This was the very minimum amount that I could use that would still make a noticeable difference. I wanted it to be a minimal amount so that the least amount of change occurs with this patch to keep it as atomic as possible. So we can explore later what that value should be.
Sun, Jan 20
Just to clarify my comment about limiting the allowed angles for drag. This patch will make it so that the drag illustrated below will be less likely to create a vertical split of the Properties menu, which is what it does now. The patch makes it so such a drag does nothing, rather than treat it as if you had dragged perfectly horizontally.
The resting zone does really not exist at the moment, you have
to move immediately while clicking to define the direction.
Sat, Jan 19
Jan 17 2019
And about the general behavior itself:
What I'd really like to do is discuss this a little bit. So I'd love someone to correct my following assumptions:
Jan 15 2019
Jan 14 2019
Jan 13 2019
Jan 12 2019
Jan 9 2019
Jan 7 2019
And If we do accept this patch then we are getting a much nicer alignment of the header names, whether they have checkmarks or not. Which mean that afterward I can submit a very small patch that aligns subpanels nicer:
Jan 6 2019
Jan 1 2019
Dec 31 2018
I still say just close this ticket.
Dec 30 2018
You are probably right, as I can't find an example where the two would be different. It looks like
they had different uses prior to XP, but are equivalent since.
The relevant MSDN document: