-
Notifications
You must be signed in to change notification settings - Fork 567
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
make most window types have a child window #1919
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! I'd probably wait a bit to see if anyone else objects...
@@ -102,13 +102,23 @@ pub(crate) struct WindowHandle { | |||
/// a view. Also, this is better for hosted applications such as VST. | |||
nsview: WeakPtr, | |||
idle_queue: Weak<Mutex<Vec<IdleKind>>>, | |||
parent: Option<Box<crate::WindowHandle>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the Box
is unnecessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no because mac is different. It would be an infinitely big struct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the others already have a reference in between the window handle and this option, mac doesnt.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why does mac need to store parent handle though?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To change the coordinate space relative to the parent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see, it's because on mac you've put the parent directly in the WindowHandle
. Why not put it in ViewState
, so it's more similar to the other platforms?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont exactly know how to get that from the WindowHandle
:(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't test because I don't have a mac, but looking at set_focused_text_field
gives a hint, I think:
// Here, self is a &WindowHandle
if let Some(view) = self.nsview.load().as_ref() {
let state: *mut c_void = *view.get_ivar("viewState");
let state = &mut (*(state as *mut ViewState));
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yes I see, thanks! pushed the changes
Id actualy first like to do some discussion about popups, to popups also need to have a parent? and do they also need to be in the parents coordinate space? Thinking about this again it seems that popups maybe should use the global coordinate space. |
nvm I forgot that we have |
Co-authored-by: Manmeet Maan <[email protected]>
I believe x11 backend position translation is TODO? |
X11 tooltips dont work, I could add the set_position conversion but it wouldn't do anything. |
no, I think they work now (at least the sub_window example does) |
also the tooltip? I get
|
This comment has been minimized.
This comment has been minimized.
For me it gets opened as a non-floating window, but that's fine-ish. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay as discussed I do have some longer-term ambitions here, but in the meantime this seems reasonable!
// TODO: Maybe collin can get this into a state where modal windows follow the parent? | ||
// There is an API to do child windows, (https://developer.apple.com/documentation/appkit/nswindow/1419152-addchildwindow) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure you can move the parent while a modal is presented?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tooltips and dropdowns suffer from the same issue, we expect them to be closed when moving a window but ATM that is upto the user to program. It might still be worth implementing for those? if not Ill remove the comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ATM that is upto the user to program.
is it possible? We don't have any windowmove events
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
uhh oh. If I am going to be implementing proper parent tracking, I can only do this for GTK and with some research probably X11. Others will have to help me on different platforms.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should give windowmove events and then the user should do whatever they like (move with the window or close the popup)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, lets put that in another MR to not bloat this one.
Co-authored-by: Colin Rofls <[email protected]>
This can be merged, right? (modulo conflicts) |
I fixed the conflicts, I think this should be ok to merge now. |
This PR somehow killed DropDown entirely on at least Windows. It doesn't do anything anymore (no window spawns). Update: |
EDIT: Could be that I broke something during the merge conflicts? |
Nvm, you are right. This was indeed already broken on master one commit before your PR got merged. I'll look into deeper bisecting this later today (or I'll just send a PR, since even on the older commit when it still worked, it was far from looking like a drop down in the first place) |
Tooltip in sub-windows example definitely got worse in Windows. Reverting the latest commit on |
ctx.window().get_position() | ||
+ window_pos.to_vec2() | ||
+ cursor_size.to_vec2(), | ||
(window_pos.to_vec2() + cursor_size.to_vec2()).to_point(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sjoshid these lines? That means the coordinate space for tool-tips isn't calculated correctly. what doesnt work anymore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could it be some DPI scaling? I cant really test but ill check if I can spot something related to that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem, at least on Windows, is that the cursor position received in TooltipController
is in window coords. So we need to go from window coords to screen coords because screen coords is what Windows expect when you create a tooltip.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes that conversion happens in win/window.rs. So that should be handled. Instead of adding the parent window coordinates in the users code we do it in druid_shell.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No because those coordinates are in global space while they should be in window space. they are converted to global space by druid_shell
not the client code. This was part of the change, so it should work. Maybe it cant get the parents state? that could be an issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The solution i gave in previous comment is basically the old code. That was dumb on my part. lol. The previous code didnt make much sense to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where in shell is this conversion happening?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* Implementation differs slightly from linebender#1919. Unlike linebender#1919, this does NOT store parent window handle in `WindowState`. If you want to access parent window handle AFTER creating window use [GetParent](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getparent). * Handles scaling. * Tooltip example in nursery tested with these changes. If this is accepted, I'll make changes in nursery too.
implement #1919 for x11 backend
This does a couple of things.
It adds the notion of parent and child windows. all non-main windows have a parent window.
All non-main windows have their coordinate space shifted, so that the origin is the location of the main window.
This is usefull in almost all usecases.
This also removes the option to change the level after the fact. At least the GTK backend doesnt support this, and it would just be extra work to move all the widgets to the new window. I also dont think there is any usecase for this.
This solves positioning not working in wayland (#1757) and resolves the discussion over at #1824.