forked from mirror/chromium
-
Notifications
You must be signed in to change notification settings - Fork 17
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[DoNotCarryForward] [ozone/wayland] Implement not implemented methods…
… in WaylandScreen. - GetDisplayForAcceleratedWidget: * This CL implements wl_surface_listener, which says what wl_output a wl_surface enters. That information is then used to identify on what display an accelerated widget is shown. To give more details, a WaylandWindow sets a wl_surface_listener now. As soon as that specific window enters a certain display, wl_surface_listener::enter event is called, and the WaylandWindow receives a pointer to that specific wl_output where it is shown. Then, the window uses WaylandOutputManager to identify the id of that display/output and stores it. Once the WaylandScreen::GetDisplayForAcceleratedWidget call comes, a WaylandWindow, which corresponds to that specific widget, is found and the id of the output it is shown on is taken. If there are two outputs used to show the window, the very first one is always used. - GetAcceleratedWidgetAtScreenPoint * This is a tricky one. To ensure right functionality, a widget under a cursor must be returned. But, Wayland clients cannot know where the windows are located in the global space coordinate system. Instead, it's possible to know widgets located on a surface local coordinate system (remember that clients cannot also know the position of the pointer in the global space coordinate system, but rather on a local surface coordinate system). That is, we will have to pretend that a single surface is a "display", where other widgets (child widgets are located in the surface local coordinate system, where the main surface has 0,0 origin) are shown. Whenever that surface is focused (the cursor is located under that widget), we will use it to determine if the point is on that main surface, a menu surface and etc. Note that bounds where widgets are shown will be fixed in the follow-up cl. Now, the widgets are not shown properly if the returned display has origin different from 0,0. That is, remember that wayland requires placing them relatively to the parent surface, which Chromium does not honor, but rather uses global space coordinate system. - GetDisplayNearestPoint and GetDisplayMatching: * Nothing special. Both of them use the existing helper methods. Bug: 875161, 890271, 890272 Change-Id: I7d6d8a7d6827cf639df2c3f0992deece156b2962
- Loading branch information
1 parent
1785f1f
commit 005f532
Showing
12 changed files
with
473 additions
and
63 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.