Fullscreen windows are rendered alone and above everything else when they
are active, and as part of the regular window stack order when something
else is active.
Currently windows cannot be made fullscreen after-the-fact, but must have
the fullscreen flag included in their CreateWindow message.
It should not possible to interact with the menu, taskbar or window frame
while the active window is fullscreened. :^)
The wheel events will end up in GWidget::mousewheel_event(GMouseEvent&)
on the client-side. This patch also implements basic wheel scrolling in
GScrollableWidget via this mechanism. :^)
There's no point in painting if it can't be seen anyway. We also make sure
to request a repaint when un-minimizing, so the window gets a chance to
repaint itself then.
This patch moves to sending up to 32 rects at a time when coordinating the
painting between WindowServer and its clients. Rects are also merged into
a minimal DisjointRectSet on the server side before painting.
Interactive resize looks a lot better after this change, since we can
usually do all the repainting needed in one go.
This was pretty straightforward thanks to the work I did separating out
LibCore from LibGUI already. :^)
- WSMessageLoop now inherits from CEventLoop.
- WSMessage now inherits from CEvent.
- WSMessageReceiver goes away.
Now there is only one event loop in Serenity. Very nice!
Any GWidget can have a tooltip and it will automatically pop up below the
center of the widget when hovered. GActions added to GToolBars will use
the action text() as their tooltip automagically. :^)
The window is simply ignored in the painting and hit testing traversal
when in minimized state, same as we do for invisible windows.
The WM_SetActiveWindow message (sent by Taskbar) brings it back into the
non-minimized state. :^)
The window frame is an object that contains a window, its title bar and
window border. This way WSWindowManager doesn't have to know about all the
different types of window borders, titlebar rects, etc.
These events are identical, so it's silly to send both. Just broadcast
window state changes everywhere instead, it doesn't matter when it was
added as clients are learning about this asynchronously anyway.
I originally thought I would do this inside WindowServer, but let's try to
make it as a standalone app that communicates with WindowServer instead.
That will allow us to use LibGUI. :^)
When a mouse button is pressed inside a window, put that window into an
automatic mouse tracking state where all mouse events are sent to that
window until all mouse buttons are released.
This might feel even better if it only cared about the mouse buttons you
actually pressed while *inside* the windows to get released, I don't know.
I'll have to use it for a while and see how it's like.
