If a window has child windows when it's destroyed, WindowServer will
now automatically tear down all of its children as well.
This is communicated to the client program through a vector of window
ID's included with the response to WindowServer::DestroyWindow.
This does feel a little bit awkward, but managing it on the client side
also seems a bit awkward.
When moving a window, we will now move any child windows by the same
position delta as the parent. This makes ComboBox popup list windows
follow the window they were opened by, which looks nice. :^)
If a window has another window in its Core::Object ancestor chain,
we now communicate that relationship to WindowServer so that it can
act with awareness of parent/child windows.
When clicking the window icon, we now pop up the window menu at the
bottom left of the icon, no matter where you clicked it.
Right-clicking the title bar still pops up at the event position.
The original implementation only sent out notifications when there was
something being drawn on screen. If nothing was going on, we'd get too
lazy and just not notify display links.
This obviously break requestAnimationFrame(), so now we just drive the
DisplayLinks at 60 fps no matter what. :^)
PR #1495fixes#1464 but only accounts for window menus. In File
Manager, for example, attempting to pop up the context menu on the file
name text box of the properties modal window, will result in the same
behavior.
Removing the code altogether solves the problem, altough I'm
not sure if it could have any bad implications.
I was thinking it might allow interaction with a parent window menu if
it remains open just before the popup window is shown, but I have not
seen a way to replicate this behavior.
This was not done previously and resulted in modal windows not being
able to accept input unless they were clicked one time if their parent
windows were the active input window.
Normally we focus any window that's added to the window stack. However,
for WindowType::Desktop this gets annoying since if the desktop manager
comes up after other GUI processes have already started, it steals the
focus from them.
Solve this by only auto-focusing desktop windows if they are the very
first window added.
Disconnecting from WindowServer without explicit calls to DestroyWindow
would leave nulled-out WeakPtr's in the AppletManager applet list.
This led to a null dereference when adding a new applet, since we were
assuming the list contained no nulled-out applets.
This patch fixes the issue by always unregistering applet windows from
the AppletManager in ~ClientConnection(). We also do an extra pass of
pruning any nulled-out WeakPtrs from the applet list when adding to it.
Fixes#1551.
This patch adds a specialized window type for notifications. They now
have a title bar on the right-hand side, with a close button.
This removes the need for the "Done" button in notifications, giving us
a bit more horizontal space overall.
Design based on a mock-up from @xTibor :^)
This patch adds GUI::DisplayLink, a mechanism for registering callbacks
that will fire at the display refresh rate.
Note that we don't actually know the screen refresh rate, but this is
instead completely driven by WindowServer's compositing timer. For all
current intents and purposes it does the job well enough. :^)
