Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overhaul the Gradient Editor #71746

Closed
wants to merge 0 commits into from
Closed

Conversation

MewPurPur
Copy link
Contributor

@MewPurPur MewPurPur commented Jan 20, 2023

I just wanted to implement snapping in the Gradient Editor. But when I pulled on that thread, the whole ball of yarn unraveled.

Refactoring

Previously, we had two sets of files (gradient_editor and gradient_editor_plugin).

gradient_editor had the GradientEditor class. This was for the colorful rectangle that lets you edit a gradient, having all the logic around GUI input on it and also the color selector.

gradient_editor_plugin had the EditorInspectorPluginGradient class, which included the GradientEditor and a small button for reversing the gradient. It also had the GradientReverseButton class, because... yeah, needed a hack just to add that button. This wasn't scalable.

I renamed GradientEditor to GradientEditorRect. The stuff inside EditorInspectorPluginGradient are essentially moved to the new GradientEditor, which includes a GradientEditorRect and regular buttons. These were all moved to one file like other editor plugins.

Before After
image image

Snap Button

Looks like this:

image

The slider and the vertical lines are only shown when snap is toggled.

I removed Ctrl+Drag (which snaps with 10 partitions) and Ctrl+Shift+Drag (which snaps with 40 partitions) as the snap button makes these tricks completely obsolete.

Shift+Drag still works and is quite useful to get two points near each other when snapping. I gave it a smaller threshold by default.

Improved Undo/Redo system

The undo/redo system wasn't functional. The single manager in _ramp_changed() left thousands of vague "Gradient Changed" messages in the output and would usually only lead you one step back before breaking, and that step back would usually not be where you wanted to get.

I didn't want to leave this system even more broken than before, so I modernized it. Now it has more descriptive messages and is more predictable. Code was simplified a lot too, removing some unused or unnecessary things.

Testing/Review on this would be appreciated because it might corrupt gradients if not done right!

Misc enhancements

  • Improved the condition for when the handle is drawn in black or white, to maximize its contrast.
Before After
image image
  • Added an indicator for overbright colors. (as shown in the previous section)
  • Added checkerboard background to handles with translucent colors.
  • Improved the condition for whether the color picker is shown above or below. If the color picker can fit neither below nor above, then it picks the direction with more space.
  • Added hover indicators:
    image
  • Improved the logic for keeping handles selected during operations (i.e. flipping when the gradient is reversed).
  • Visually glitched handles with offsets outside of the [0, 1] range are no longer shown.
  • Fixed typo in gradient.h (ponit -> point 🎠)

(dw you're not having deja vu. I screwed up my old PR with a bad rebase)

@MewPurPur
Copy link
Contributor Author

-_______-

@aaronfranke aaronfranke removed this from the 4.x milestone Feb 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants