Introduce ghost mode for elements #85

Vectornaut · 2025-05-19T07:55:03Z

Vectornaut commented

2025-05-19 07:55:03 +00:00

On the branch to be merged, any element of an assembly can be put in "ghost mode," making it intangible and increasing its transparency. Being intangible means the element is ignored when you click to select on the display. Ghost mode is toggled using a checkbox in the outline view.

This pull request should commute with #87.

On the branch to be merged, any element of an assembly can be put in "ghost mode," making it intangible and increasing its transparency. Being intangible means the element is ignored when you click to select on the display. Ghost mode is toggled using a checkbox in the outline view. This pull request should commute with #87.

Vectornaut added 4 commits 2025-05-19 07:55:04 +00:00

Allow each sphere to have its own opacity ba1d87812f

To confirm that we haven't accidentally changed the rendering behavior,
we still give every sphere the same default opacity.

Introduce ghost mode fc230e4993

Elements in ghost mode are intangible. Spheres in ghost mode are also
more transparent. Points in ghost mode should probably be more
transparent too, but that hasn't been implemented yet.

Make points more transparent in ghost mode 592f327e62

Combine color and opacity on push to scene

/ test (pull_request) Successful in 2m27s

Details

2aa1adcd07

Vectornaut referenced this pull request

2025-05-21 01:25:08 +00:00

Dispatch normalization routines correctly #87

glen commented

2025-05-30 00:39:11 +00:00

Any reason you didn't just make colors have an alpha channel everywhere, as opposed to adding an opacity argument to the push command and then having this combine channels function inside push so that there are opaque 3-channel colors in some places and separately a concept of a 4-channel color_with_opacity, that seems a bit verbose? Would it be simpler to have one concept of (4-channel) color everywhere? Just a thought, let me know what you think.

Vectornaut commented

2025-05-30 01:04:54 +00:00

Any reason you didn't just make colors have an alpha channel everywhere […]?

I was thinking that when we add a user-facing opacity setting, we'll also need to figure out how it interacts with the "ghost mode" opacity changes, and I didn't want to think about that yet.

We already have an analogous situation with color. There's a user-facing color setting, but selecting an element also affects its color, and we have formulas that do the color adjustment for spheres and points (which are currently the same for both element types).

We could easily make up a similar formula for opacity, but it wouldn't be informed by any real interface considerations, because we don't have a real need for a user-facing opacity setting yet.

> Any reason you didn't just make colors have an alpha channel everywhere […]? I was thinking that when we add a user-facing opacity setting, we'll also need to figure out how it interacts with the "ghost mode" opacity changes, and I didn't want to think about that yet. We already have an analogous situation with color. There's a user-facing color setting, but selecting an element also affects its color, and we have formulas that do the color adjustment for [spheres](src/commit/2aa1adcd070e0d6bce288c079fb3cee7383e411e/app-proto/src/display.rs#L119) and [points](src/commit/2aa1adcd070e0d6bce288c079fb3cee7383e411e/app-proto/src/display.rs#L173) (which are currently the same for both element types). We could easily make up a similar formula for opacity, but it wouldn't be informed by any real interface considerations, because we don't have a real need for a user-facing opacity setting yet.

glen commented

2025-06-01 03:06:42 +00:00

@Vectornaut wrote in #85 (comment):

a user-facing color setting

Well, it's more of a color setting API -- the app user has no way to set the color of an element.

I guess this PR is working as is, but it just seems like a roundabout way to deal with colors... it's a bit hard for me to imagine that the ultimate version of the software will use this collection of abstractions and interfaces to deal with colors, that's all. What do you think? Just confirm that you think that having this PR working as is outweighs the value of trying to adopt a more streamlined and uniform representation of colors now, and we'll move on. Or if you actually decide that it would be good to refactor the color representations now, that's fine as well. Let me know either way.

@Vectornaut wrote in https://code.studioinfinity.org/StudioInfinity/dyna3/pulls/85#issuecomment-2908: > a user-facing color setting Well, it's more of a color setting API -- the app user has no way to set the color of an element. I guess this PR is working as is, but it just seems like a roundabout way to deal with colors... it's a bit hard for me to imagine that the ultimate version of the software will use this collection of abstractions and interfaces to deal with colors, that's all. What do you think? Just confirm that you think that having this PR working as is outweighs the value of trying to adopt a more streamlined and uniform representation of colors now, and we'll move on. Or if you actually decide that it would be good to refactor the color representations now, that's fine as well. Let me know either way.

Vectornaut referenced this pull request

2025-06-01 22:54:13 +00:00

Add direct opacity parameters for elements #88

Vectornaut commented

2025-06-01 22:59:04 +00:00

I guess this PR is working as is, but it just seems like a roundabout way to deal with colors... it's a bit hard for me to imagine that the ultimate version of the software will use this collection of abstractions and interfaces to deal with colors, that's all. What do you think? Just confirm that you think that having this PR working as is outweighs the value of trying to adopt a more streamlined and uniform representation of colors now, and we'll move on.

This certainly shouldn't be the final form of the color API, because the Element structure should eventually include parameters that provide direct control over opacity. I've opened issue #88 to discuss that. However, I still think we should hold off on refactoring until we've spent more time to exploring the interface and thinking about user needs.

> I guess this PR is working as is, but it just seems like a roundabout way to deal with colors... it's a bit hard for me to imagine that the ultimate version of the software will use this collection of abstractions and interfaces to deal with colors, that's all. What do you think? Just confirm that you think that having this PR working as is outweighs the value of trying to adopt a more streamlined and uniform representation of colors now, and we'll move on. This certainly shouldn't be the final form of the color API, because the `Element` structure should eventually include parameters that provide direct control over opacity. I've opened issue #88 to discuss that. However, I still think we should hold off on refactoring until we've spent more time to exploring the interface and thinking about user needs.

glen commented

2025-06-02 15:54:17 +00:00

OK, works as advertised, leaving color refactoring to #88, passes tests. Merging.

glen merged commit a671a8273a into main

2025-06-02 15:56:08 +00:00

glen referenced this pull request from a commit

2025-06-02 15:56:09 +00:00

Introduce ghost mode for elements (#85)

Vectornaut reviewed 2025-06-09 18:56:29 +00:00

Vectornaut left a comment

I just noticed this apparent regression, and I wanted to check whether it was intentional before filing an issue.

app-proto/src/outline.rs

					
				@ -202,7 +202,11 @@ fn ElementOutlineItem(element: Rc<dyn Element>) -> View {

				                    ) {

				                        div(class="element-label") { (label) }

				                        div(class="element-representation") { (rep_components) }

				                        div(class="status")

Vectornaut commented

2025-06-09 18:51:53 +00:00

Did we intentionally remove this indicator, which flags an element with an invalidly specified regulator when the regulator list is closed? The removal looks like a regression—especially because we didn't remove the associated CSS—but I wanted to check in case we decided on it in a meeting and I forgot to write it down.

glen commented

2025-07-28 03:23:38 +00:00

I think I never responded to this. If you think there should be some indication of a regulator with bad input (or something like that) and there currently is no such indication, absolutely feel free to file an issue. I don't recall any discussion that we should not have such an indication. (And hopefully filing issues/recording notes in some permanent online fashion immediately after our meetings will help with confidence on such matters!)