Modify child_window example #4054
Conversation
…ith a different color than the parent window and made it so the child windows fill a grid instead of stacking on top of one another
examples/util/fill.rs
Outdated
| @@ -70,7 +70,7 @@ mod platform { | |||
| } | |||
| } | |||
|
|
|||
| pub fn fill_window(window: &dyn Window) { | |||
| pub fn fill_window(window: &dyn Window, color: u32) { | |||
There was a problem hiding this comment.
I'd suggest to just add a new function fill_window, which calls fill_window_with_color, which uses the default color we're using, thus way you don't have to change any example at all, except the child one.
examples/child_window.rs
Outdated
| if window_id == self.parent_window_id.unwrap() { | ||
| fill::fill_window(window.as_ref(), 0xff181818); | ||
| } else { | ||
| fill::fill_window(window.as_ref(), 0xffbbbbbb); |
There was a problem hiding this comment.
Maybe we should just cycle color for child?
There was a problem hiding this comment.
Leaving the parent window empty like in the window example and then just the childs are filled?
There was a problem hiding this comment.
The parent will have the default color, and childs will have different color for each of them.
There was a problem hiding this comment.
You want the childs colors to be deterministic or random? Mostly asking because it changes wherever I make the color a function of their position or their window id
There was a problem hiding this comment.
Similar how you did with the position, but also with color, so it'll be deterministic defined by the number of child you've opened.
There was a problem hiding this comment.
The index I'm using to calculate the position right now is a throwaway value because the child object doesn't already have a way for me to store it, that's why I said making the color a function of the position
There was a problem hiding this comment.
I mean, how you exactly implement it doesn't really matter. I'd probably just make a counter for number of child windows opened and use it to generate things.
There was a problem hiding this comment.
I think I may be misunderstanding something, doesn't redraw_request get called for each frame? I thought using a counter instead of a value linked to the child window would end up with every child having the same color because they'd end up being filled with the same color as whatever the last counter number dictated
There was a problem hiding this comment.
counter is tied to a child window, so it stays the same for the window your drawing. it also means that you store that color somewhere.
…til/fill.rs and defined fill_window with it
Currently, the child_window example fills the child windows with the same color as the parent window, so the creation and presence of a child window is only perceptible through the terminal messages. In addition to that, all child windows are placed on top of one another.
What I did was change the fill_window function defined in examples/util/fill.rs so that it accepts a color argument, then I had to copy the color that was hardcoded and put it as argument on all calls to fill_window on the other examples. I originally wanted use transparency on the parent window instead, changing the alpha channel of the color on fill_window and adding the transparency attribute to the parent window but, while it worked for me, there's an open issue in transparency (#2502) so I decided it may not be a good idea
After that I added a child_counter to spawn_child_window of the child_window example and use it to calculate a position for the new child_window on a 5 column grid. Also changed the child window size from 200x200 to 128x96 so that a 5x5 grid gets formed if the initial size of the parent window is kept.