Does guix maintain z-order between parents and their children?

Question

In other words, is there a way to draw a child window/widget below its parent?
I can control Z-order between siblings by using gx_widget_attach(parent, child) and gx_widget_back_attach(parent, child) and all the children will be displayed with the correct z-order relative to each other.

All the drawing operations in my application seem to be initiated from root window's drawing function which recursively draws all its children so it seems to be impossible to draw a child before drawing its parent. Is there an alternate drawing mechanism that supports this? The documentation hints that views are responsible for this, but there is no clear way to achieve it.

Answer 1

You can't draw a child behind it's parent, but you could make the parent transparent if you wanted to see what is behind the parent. GUIX only keeps views for the "top-level" children, i.e. children added to the root window. Views basically mean that top-level windows aren't allowed to draw over each other, so if one window is partially covering another, that window in the back will be forced to draw into views that don't overlap with the window in the front. It's a trade-off between optimizing drawing and the memory/time it takes to maintain the view list.

It's a bit odd if all the drawing is initiated from the root window, you generally have control over that in terms of what you are marking dirty. If the root window isn't dirty it shouldn't be redrawing from the bottom up like that. Of course a lot of APIs automatically mark the target widget dirty so keep that in mind.

Back to drawing a child below it's parent, I'm really not sure what you mean by that, because if you did that the parent would just draw over the child anyway right, so what's the point? But I have to add to my first answer in that you could override the drawing function the parent, call gx_widget_children_draw(), and then call the parent widget's draw function if you really wanted to draw the children first. The standard draw function is organize like

 draw_this
 draw_children

But nothing prevents you from defining your own drawing function and reversing that order. Again I'm not clear on what you are trying to accomplish so if this doesn't help please provide more details or maybe a picture. Thanks!

Ken

Answer 2

Hello @Ehsan ,

I see the issue. Yes, we can add an "always_on_top" style, I added this to our task backlog. And as you surely noticed, child widgets are not allowed to draw outside their parents boundary, so in your pic Screen #1 would be clipped to the NavigationWindow boundry if it is a child widget of NavigationWindow.

In the near term, I can think of a few things that should work:

1) You said that Screen #1 does handle some of the user-defined input events, which means to me it has an event handler. In that event handler, you don't have to pass the user-defined events to the parent, you can direct them specifically to the NavigationWindow, either by calling that windows's event handler directly:

   pNavigationWindow->gx_widget_event_process_function(pNavigationWindow, event);  

or by setting the event.gx_event_target field to point at he NavigationWindow and pushing the event back into the GUIX event queue:

  event.gx_event_target = pNavigationWindow;  
  gx_system_event_send(event);  

You would only want to do this for your user-defined key events, system events need to go to widget's parent or it will break things.

2) You can direct your input events straight to the NavigationWindow if you know which events should be routed there, again by setting the gx_event_target field, but this time do it in your key input driver.

3) I would suggest that you turn off the "Enabled" style for Screen #1, in which case it would not receive input focus, but since you said that this screen actually does need to see some of the input that isn't going to work for you.

4) Override the root window event process function. No matter where your user-defined events start out, they are going to end up at the root window event handler if nothing in between traps them. So use gx_widget_event_process_set(root_window, my_root_window_event_handler) to catch these events at the end of the chain, and if they need to go to the NavigationWindow then write a little loop to search for the NavigationWindow in root window's child list and if/when found send the event there.

I understand that none of these are exactly convenient, but let me know if any of these will get your app working they way you want it to work.

Best Regards,