fix dropdown position for gtk backend

[maurerdietmar]

We need to position internal windows (dropdowns, tooltips) relative
to the content area.

Signed-off-by: Dietmar Maurer [email protected]

[maurerdietmar]

I am quite unsure if we should add this logic into set_position(). Instead, we could use different get_position methods, i.e:

get_window_position: Returns the position of the window decoration top-left corner.
get_position: Returns the position of the content window top-left corner.

Also, I have only tested this on Debian/Linux.

[jneem]

This is tricky, unfortunately, and will definitely need testing on wayland because window positioning works differently there.

Note that we currently have the content_insets method that, when combined with get_position and set_position, should allow for handling the various cases. The gtk implementation of content_insets doesn't currently account for the window decorations, but maybe that should be changed? (I found this hint for how to calculate the decoration sizes.)

I think one reasonable choice for druid_shell would be to just say that set_position and get_position always work with the top-left coordinate of the window decorations (for both the child and the parent), and that content_insets on the parent window can be used if you want to position a child relative to the content of the parent.

If we want a friendly API for positioning child windows relative to the content of the parent, we could handle the insets in druid's new_sub_window function. I'd prefer this approach, because it's easier to keep cross-platform behavior sane and in sync if the druid-shell API is kept simple and orthogonal.

[maurerdietmar]

If we want a friendly API for positioning child windows relative to the content of the parent, we could handle the insets in druid's new_sub_window function. I'd prefer this approach, because it's easier to keep cross-platform behavior sane and in sync if the druid-shell API is kept simple and orthogonal.

Tried that, but how do I call content_insets() from inside new_sub_window? I have no idea how to get the WindowHandle there?

[jneem]

self.state.window or self.window(), where self here is the EventCtx (or UpdateCtx or LifeCycleCtx)

[maurerdietmar]

self.state.window or self.window(), where self here is the EventCtx (or UpdateCtx or LifeCycleCtx)

Thanks for the hint! Just updated the patch and implemented it as you suggested.

I haven't updated the doc comments for contents_insets() so far, because I am unsure what to write ...

[jneem]

I think you can just delete the doc on content_insets, because after this change there won't be anything special about our GTK implementation of them anymore.

[jneem]

According to the WindowLevel docs the difference between various levels is only in their z-order, so I don't think you should change behavior based on WindowLevel.

[maurerdietmar]

According to the WindowLevel docs the difference between various levels is only in their z-order, so I don't think you should change behavior based on WindowLevel.

Well, the docs also say:

Describes the purpose of a window and should be mapped appropriately to match platform conventions.

WindowLevel is also used to set the WM type hint, so this is by sure more than a Z-order.

Anyways, I cant see any other property which indicates the window type, so what exactly do you have in mind?

[jneem]

That's a good point, although it isn't particularly consistent with the previous sentence. I guess we need to figure out (and document!) what else WindowLevel is actually supposed to mean.

But I still think it would be surprising if window positioning worked differently for different kinds of windows: why should it be that tooltips are relative to the parent's content but modals are relative to the parent's window decorations?

[maurerdietmar]

But I still think it would be surprising if window positioning worked differently for different kinds of windows: why should it be that tooltips are relative to the parent's content but modals are relative to the parent's window decorations?

Agreed. That is why is suggested to use two different get_position methods (get_window_position and get_position).

[maurerdietmar]

Agreed. That is why is suggested to use two different get_position methods (get_window_position and get_position).

Please ignore that last argument - it does not really makes any difference.

But I still think it would be surprising if window positioning worked differently for different kinds of windows: why should it be that tooltips are relative to the parent's content but modals are relative to the parent's window decorations?

Thought a bit more about that, and it is quite obvious that dropdowns and tooltips need to be positioned relative to the content root.

[jneem]

I agree that it's very natural for dropdowns and tooltips to be positioned relative to the content. But there are also some disadvantages:

• it's undocumented
• it differs from established APIs, like gtk_window_move and (I think) SetWindowPos on windows, which are always relative to the window frame
• if we support other type hints in the future, we will need to decide (and document!) how they're treated

The first point is the big one: if we're going to go down this road, it needs to be clearly documented.

[maurerdietmar]

I agree that it's very natural for dropdowns and tooltips to be positioned relative to the content. But there are also some disadvantages

Ok, so I removed the code in make_sub_window - instead, the caller can easily handle that (I will send a patch for dropdown.rs once this gets applied)

[jneem]

Thanks for your patience!