Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-22 09:03:22 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibGUI/GWindowServerConnection.h

50 lines
2.4 KiB
C
Raw Normal View History

Rename all the LibGUI classes to GClassName.
2019-01-20 04:49:48 +01:00
#pragma once
LibIPC: Move IPC client/server connection templates to LibIPC Move over the CoreIPC::Server and CoreIPC::Client namespace stuff into LibIPC where it will soon becomes LibIPC-style things.
2019-12-02 09:52:07 +01:00
#include <LibIPC/IServerConnection.h>
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 09:33:37 +01:00
#include <WindowServer/WindowClientEndpoint.h>
#include <WindowServer/WindowServerEndpoint.h>
Rename all the LibGUI classes to GClassName.
2019-01-20 04:49:48 +01:00
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 09:33:37 +01:00
class GWindowServerConnection
LibIPC: Rename base classes to IClientConnection and IServerConnection This matches what we're already calling the server-side subclasses better, though we'll probably want to find some better names for the client-side classes eventually.
2019-12-02 09:58:25 +01:00
: public IServerConnection<WindowClientEndpoint, WindowServerEndpoint>
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 09:33:37 +01:00
, public WindowClientEndpoint {
LibCore: Convert CTCPSocket to ObjectPtr, add construct() helper The C_OBJECT macro now also inserts a static construct(...) helper into the class. Now we can make the constructor(s) private and instead call: auto socket = CTCPSocket::construct(arguments); construct() returns an ObjectPtr<T>, which we'll later switch to being a NonnullRefPtr<T>, once everything else in in place for ref-counting.
2019-09-21 10:13:34 +02:00
C_OBJECT(GWindowServerConnection)
Rename all the LibGUI classes to GClassName.
2019-01-20 04:49:48 +01:00
public:
Port LibGUI to use CIPCClientSideConnection As a consequence, move to use an explicit handshake() method rather than calling virtuals from the constructor. This seemed to not bother AClientConnection, but LibGUI crashes (rightfully) because of it.
2019-07-17 18:28:30 +02:00
GWindowServerConnection()
LibIPC: Rename base classes to IClientConnection and IServerConnection This matches what we're already calling the server-side subclasses better, though we'll probably want to find some better names for the client-side classes eventually.
2019-12-02 09:58:25 +01:00
: IServerConnection(*this, "/tmp/portal/window")
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 09:33:37 +01:00
{
handshake();
}
WindowServer: Begin refactoring towards a fully asynchronous protocol. In order to move the WindowServer to userspace, I have to eliminate its dependence on system call facilities. The communication channel with each client needs to be message-based in both directions.
2019-02-13 17:54:30 +01:00
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 09:33:37 +01:00
virtual void handshake() override;
LibGUI: Revert GWindowServerConnection to being a singleton This was a mistake, of course. Nested event loops don't need (or want) independent server connections. We initialize the connection early in GEventLoop for e.g. users that want to get the size of a GDesktop before the connection has been established. Bug noticed by Andreas, introduced by me ;-)
2019-07-17 20:57:27 +02:00
static GWindowServerConnection& the();
LibGUI: Implement nested event loops to support dialog boxes. This patch adds a simple GMessageBox that can run in a nested event loop. Here's how you use it: GMessageBox box("Message text here", "Message window title"); int result = box.exec(); The next step is to make the WindowServer respect the modality flag of these windows and prevent interaction with other windows in the same process until the modal window has been closed.
2019-03-19 00:01:02 +01:00
Rename all the LibGUI classes to GClassName.
2019-01-20 04:49:48 +01:00
private:
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 09:33:37 +01:00
virtual void handle(const WindowClient::Paint&) override;
virtual void handle(const WindowClient::MouseMove&) override;
virtual void handle(const WindowClient::MouseDown&) override;
virtual void handle(const WindowClient::MouseDoubleClick&) override;
virtual void handle(const WindowClient::MouseUp&) override;
virtual void handle(const WindowClient::MouseWheel&) override;
virtual void handle(const WindowClient::WindowEntered&) override;
virtual void handle(const WindowClient::WindowLeft&) override;
virtual void handle(const WindowClient::KeyDown&) override;
virtual void handle(const WindowClient::KeyUp&) override;
virtual void handle(const WindowClient::WindowActivated&) override;
virtual void handle(const WindowClient::WindowDeactivated&) override;
virtual void handle(const WindowClient::WindowCloseRequest&) override;
virtual void handle(const WindowClient::WindowResized&) override;
virtual void handle(const WindowClient::MenuItemActivated&) override;
virtual void handle(const WindowClient::ScreenRectChanged&) override;
virtual void handle(const WindowClient::ClipboardContentsChanged&) override;
virtual void handle(const WindowClient::WM_WindowRemoved&) override;
virtual void handle(const WindowClient::WM_WindowStateChanged&) override;
virtual void handle(const WindowClient::WM_WindowIconBitmapChanged&) override;
virtual void handle(const WindowClient::WM_WindowRectChanged&) override;
virtual void handle(const WindowClient::AsyncSetWallpaperFinished&) override;
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
virtual void handle(const WindowClient::DragDropped&) override;
virtual void handle(const WindowClient::DragAccepted&) override;
virtual void handle(const WindowClient::DragCancelled&) override;
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:24:26 +01:00
virtual void handle(const WindowClient::UpdateSystemTheme&) override;
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
virtual void handle(const WindowClient::WindowStateChanged&) override;
Port LibGUI to use CIPCClientSideConnection As a consequence, move to use an explicit handshake() method rather than calling virtuals from the constructor. This seemed to not bother AClientConnection, but LibGUI crashes (rightfully) because of it.
2019-07-17 18:28:30 +02:00
};
Reference in a new issue Copy permalink