Commit graph

12 commits

Author SHA1 Message Date
Andreas Kling
2d244a70a1 WindowServer+LibGUI: Simplify handling of paint event rects
Now that Vector<T> is convertible to Vector<T, n>, we don't have to
manually copy the paint event rectangles.
2020-01-04 11:03:37 +01:00
Andreas Kling
8c8118fbf8 WindowServer+LibGUI: Taskbar should show all windows from each process
We were not sending the ID of the window that was listening for window
management (WM) events along with the WM messages. They only included
the "target" window's ID.

Since the taskbar's single window had the first window ID for its own
connection to the WindowServer, it meant that it would only receive
WM events for the first window ID in other processes as well.

This broke when I ported WindowServer to LibIPC.

Fix this by including the WM listener ID in all WM messages, and since
we're here anyway, get rid of a bunch of unnecessary indirection where
we were passing WM events through the WindowServer event loop before
sending them to the listener.
2020-01-02 03:29:21 +01:00
Andreas Kling
c7847d7c81 WindowServer+LibGUI: Mark window bitmaps volatile in occluded windows
WindowServer now tracks whether windows are occluded (meaning that
they are completely covered by one or more opaque windows sitting above
them.) This state is communicated to the windows via WindowStateChanged
messages, which then allow GWindow to mark its backing store volatile.

This reduces the effective memory impact of windows that are not at all
visible to the user. Very cool. :^)
2019-12-27 11:34:40 +01:00
Andreas Kling
519cb80a96 LibGUI+WindowServer: Mark minimized window backing stores as volatile
WindowServer will now send out a WindowStateChanged message to clients
when one of their windows is minimized.

This is then forwarded to the GWindow, which will try to mark its
underlying window backing store as volatile.

This allows the kernel to steal the memory used by minimized windows
in case it starts running low. Very cool! :^)
2019-12-26 12:06:07 +01:00
Andreas Kling
a79bac428b LibGUI+LibDraw: Add "Palette" concept for scoped color theming
GApplication now has a palette. This palette contains all the system
theme colors by default, and is inherited by a new top-level GWidget.
New child widgets inherit their parents palette.

It is possible to override the GApplication palette, and the palette
of any GWidget.

The Palette object contains a bunch of colors, each corresponding to
a ColorRole. Each role has a convenience getter as well.

Each GWidget now has a background_role() and foreground_role(), which
are then looked up in their current palette when painting. This means
that you no longer alter the background color of a widget by setting
it directly, rather you alter either its background role, or the
widget's palette.
2019-12-24 21:27:16 +01:00
Andreas Kling
411058b2a3 WindowServer+LibGUI: Implement basic color theming
Color themes are loaded from .ini files in /res/themes/
The theme can be switched from the "Themes" section in the system menu.

The basic mechanism is that WindowServer broadcasts a SharedBuffer with
all of the color values of the current theme. Clients receive this with
the response to their initial WindowServer::Greet handshake.

When the theme is changed, WindowServer tells everyone by sending out
an UpdateSystemTheme message with a new SharedBuffer to use.

This does feel somewhat bloated somehow, but I'm sure we can iterate on
it over time and improve things.

To get one of the theme colors, use the Color(SystemColor) constructor:

    painter.fill_rect(rect, SystemColor::HoverHighlight);

Some things don't work 100% right without a reboot. Specifically, when
constructing a GWidget, it will set its own background and foreground
colors based on the current SystemColor::Window and SystemColor::Text.
The widget is then stuck with these values, and they don't update on
system theme change, only on app restart.

All in all though, this is pretty cool. Merry Christmas! :^)
2019-12-23 20:33:01 +01:00
Andreas Kling
cfcb38dff1 WindowServer+LibGUI: Add data_type and data fields to drag operations
These fields are intended to carry the real meat of a drag operation,
and the "text" is just for what we show on screen (alongside the cursor
during the actual drag.)

The data field is just a String for now, but in the future we should
make it something more flexible.
2019-12-20 20:07:10 +01:00
Andreas Kling
571c4d3fb8 LibGUI: Allow finding the source of a GAction activation
When a GAction is activated by a menu, or by a toolbar button, you can
now use GAction::activator() to get a pointer to whomever activated it.

This can be used to implement context-specific behaviors in situations
where the same action is exposed through multiple paths.

This addresses an issue that was brought up in #826.
2019-12-09 21:29:43 +01:00
Andreas Kling
a7f414bba7 LibGUI+WindowServer: Start fleshing out drag&drop functionality
This patch enables basic drag&drop between applications.
You initiate a drag by creating a GDragOperation object and calling
exec() on it. This creates a nested event loop in the calling program
that only returns once the drag operation has ended.

On the receiving side, you get a call to GWidget::drop_event() with
a GDropEvent containing information about the dropped data.

The only data passed right now is a piece of text that's also used
to visually indicate that a drag is happening (by showing the text in
a little box that follows the mouse cursor around.)

There are things to fix here, but we're off to a nice start. :^)
2019-12-08 16:50:23 +01:00
Andreas Kling
f93c0dc489 LibIPC: Get client/server PIDs using getsockopt(SO_PEERCRED)
Instead of passing the PIDs back and forth in a handshake "Greet"
message, just use getsockopt(SO_PEERCRED) on both sides to get the same
information from the kernel.

This is a nice little simplification of the IPC protocol, although it
does not get rid of the handshake since we still have to pass the
"client ID" from the server to each client so they know how to refer
to themselves. This might not be necessary and we might be able to get
rid of this later on.
2019-12-06 18:39:59 +01:00
Andreas Kling
272d65e3e2 WindowServer: Port to the new IPC system
This patch introduces code generation for the WindowServer IPC with
its clients. The client/server endpoints are defined by the two .ipc
files in Servers/WindowServer/: WindowServer.ipc and WindowClient.ipc

It now becomes significantly easier to add features and capabilities
to WindowServer since you don't have to know nearly as much about all
the intricate paths that IPC messages take between LibGUI and WSWindow.

The new system also uses significantly less IPC bandwidth since we're
now doing packed serialization instead of passing fixed-sized structs
of ~600 bytes for each message.

Some repaint coalescing optimizations are lost in this conversion and
we'll need to look at how to implement those in the new world.

The old CoreIPC::Client::Connection and CoreIPC::Server::Connection
classes are removed by this patch and replaced by use of ConnectionNG,
which will be renamed eventually.

Goodbye, old WindowServer IPC. You served us well :^)
2019-12-02 11:11:05 +01:00
Andreas Kling
8a024a3305 LibGUI: Rename GEventLoop.{cpp,h} => GWindowServerConnection
The GEventLoop class is long gone, and the only class in these files is
GWindowServerConnection, so let's update the file names. :^)
2019-11-08 11:40:25 +01:00
Renamed from Libraries/LibGUI/GEventLoop.cpp (Browse further)