Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 05:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWebView/EventLoop/EventLoopImplementationQt.h

77 lines
2.2 KiB
C
Raw Normal View History

Ladybird: Run the Core::EventLoop with a Qt backend This patch adds EventLoopImplementationQt which is a full replacement for the Core::EventLoopImplementationUnix that uses Qt's event loop as a backend instead. This means that Core::Timer, Core::Notifier, and Core::Event delivery are all driven by Qt primitives in the Ladybird UI and WC processes.
2023-04-24 14:51:19 +02:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2022-2023, Andreas Kling <andreas@ladybird.org>
Ladybird: Run the Core::EventLoop with a Qt backend This patch adds EventLoopImplementationQt which is a full replacement for the Core::EventLoopImplementationUnix that uses Qt's event loop as a backend instead. This means that Core::Timer, Core::Notifier, and Core::Event delivery are all driven by Qt primitives in the Ladybird UI and WC processes.
2023-04-24 14:51:19 +02:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
Ladybird: Allow posting events to the Qt event loop from other threads Previously, a QTimer was used to start processing of our event queue in the main Qt event loop. Unfortunately, QTimers are not thread-safe, and disallow starting of a timer from a different thread than it was created in. Instead, use a dummy QObject to post a custom QEvent to the main loop from whatever thread we like, and process our event queue when it is received by our dummy object.
2023-07-04 04:37:36 -05:00
#include <AK/Badge.h>
Ladybird: Run the Core::EventLoop with a Qt backend This patch adds EventLoopImplementationQt which is a full replacement for the Core::EventLoopImplementationUnix that uses Qt's event loop as a backend instead. This means that Core::Timer, Core::Notifier, and Core::Event delivery are all driven by Qt primitives in the Ladybird UI and WC processes.
2023-04-24 14:51:19 +02:00
#include <AK/NonnullOwnPtr.h>
#include <LibCore/EventLoopImplementation.h>
Everywhere: Move the Ladybird folder to UI
2024-11-09 12:50:33 -05:00
LibWebView+Services+UI: Move the EventLoop implementations to LibWebView We currently compile the Qt event loop files multiple times, for every target which wants to use them. This patch moves these to LibWebView as a central location to avoid this.
2024-11-10 09:23:10 -05:00
class QEvent;
class QEventLoop;
class QSocketNotifier;
Ladybird: Run the Core::EventLoop with a Qt backend This patch adds EventLoopImplementationQt which is a full replacement for the Core::EventLoopImplementationUnix that uses Qt's event loop as a backend instead. This means that Core::Timer, Core::Notifier, and Core::Event delivery are all driven by Qt primitives in the Ladybird UI and WC processes.
2023-04-24 14:51:19 +02:00
LibWebView+Services+UI: Move the EventLoop implementations to LibWebView We currently compile the Qt event loop files multiple times, for every target which wants to use them. This patch moves these to LibWebView as a central location to avoid this.
2024-11-10 09:23:10 -05:00
namespace WebView {
Ladybird: Run the Core::EventLoop with a Qt backend This patch adds EventLoopImplementationQt which is a full replacement for the Core::EventLoopImplementationUnix that uses Qt's event loop as a backend instead. This means that Core::Timer, Core::Notifier, and Core::Event delivery are all driven by Qt primitives in the Ladybird UI and WC processes.
2023-04-24 14:51:19 +02:00
UI/Qt: Do not create signal notifiers until after an event loop exists We are currently creating a signal socket and socket notifier before the Qt event loop itself has been created. Thus, when we receive a signal, we are not actually notified when we write that signal number to the signal socket. This was also the source of the following error message being displayed on every launch of the browser: QSocketNotifier: Can only be used with threads started with QThread
2024-10-01 11:49:07 -04:00
class EventLoopImplementationQt;
Ladybird: Allow posting events to the Qt event loop from other threads Previously, a QTimer was used to start processing of our event queue in the main Qt event loop. Unfortunately, QTimers are not thread-safe, and disallow starting of a timer from a different thread than it was created in. Instead, use a dummy QObject to post a custom QEvent to the main loop from whatever thread we like, and process our event queue when it is received by our dummy object.
2023-07-04 04:37:36 -05:00
class EventLoopImplementationQtEventTarget;
LibCore+Ladybird: Add EventLoopManager interface for persistent state Things such as timers and notifiers aren't specific to one instance of Core::EventLoop, so let's not tie them down to EventLoopImplementation. Instead, move those APIs + signals & a few other things to a new EventLoopManager interface. EventLoopManager also knows how to create a new EventLoopImplementation object.
2023-04-25 17:38:48 +02:00
class EventLoopManagerQt final : public Core::EventLoopManager {
Ladybird: Run the Core::EventLoop with a Qt backend This patch adds EventLoopImplementationQt which is a full replacement for the Core::EventLoopImplementationUnix that uses Qt's event loop as a backend instead. This means that Core::Timer, Core::Notifier, and Core::Event delivery are all driven by Qt primitives in the Ladybird UI and WC processes.
2023-04-24 14:51:19 +02:00
public:
LibCore+Ladybird: Add EventLoopManager interface for persistent state Things such as timers and notifiers aren't specific to one instance of Core::EventLoop, so let's not tie them down to EventLoopImplementation. Instead, move those APIs + signals & a few other things to a new EventLoopManager interface. EventLoopManager also knows how to create a new EventLoopImplementation object.
2023-04-25 17:38:48 +02:00
EventLoopManagerQt();
virtual ~EventLoopManagerQt() override;
virtual NonnullOwnPtr<Core::EventLoopImplementation> make_implementation() override;
Ladybird: Run the Core::EventLoop with a Qt backend This patch adds EventLoopImplementationQt which is a full replacement for the Core::EventLoopImplementationUnix that uses Qt's event loop as a backend instead. This means that Core::Timer, Core::Notifier, and Core::Event delivery are all driven by Qt primitives in the Ladybird UI and WC processes.
2023-04-24 14:51:19 +02:00
LibCore: Remove unused "visible for timer purposes" concept This was a long-unused leftover from SerenityOS.
2025-08-11 11:45:39 +02:00
virtual intptr_t register_timer(Core::EventReceiver&, int milliseconds, bool should_reload) override;
LibCore+Ladybird: Don't force timer ids to be integer just to remap them If we don't force event loop to fit timer id into integer, we can eliminate awkward IDAllocator inside EventLoopImplementations.
2024-02-18 00:11:38 -05:00
virtual void unregister_timer(intptr_t timer_id) override;
Ladybird: Run the Core::EventLoop with a Qt backend This patch adds EventLoopImplementationQt which is a full replacement for the Core::EventLoopImplementationUnix that uses Qt's event loop as a backend instead. This means that Core::Timer, Core::Notifier, and Core::Event delivery are all driven by Qt primitives in the Ladybird UI and WC processes.
2023-04-24 14:51:19 +02:00
virtual void register_notifier(Core::Notifier&) override;
virtual void unregister_notifier(Core::Notifier&) override;
Ladybird+LibCore: Use QCoreApplication to drive the main Qt event loop Using QEventLoop works for everything but it breaks *one* little feature that we care about: automatically quitting the app when all windows have been closed. That only works if you drive the outermost main event loop with a QCoreApplication instead of a QEventLoop. This is unfortunate, as it complicates our API a little bit, but I'm sure we can think of a way to make this nicer someday. In order for QCoreApplication::exec() to process our own ThreadEventQueue, we now have a zero-timer that we kick whenever new events are posted to the thread queue.
2023-04-25 16:53:07 +02:00
virtual void did_post_event() override;
Ladybird: Allow posting events to the Qt event loop from other threads Previously, a QTimer was used to start processing of our event queue in the main Qt event loop. Unfortunately, QTimers are not thread-safe, and disallow starting of a timer from a different thread than it was created in. Instead, use a dummy QObject to post a custom QEvent to the main loop from whatever thread we like, and process our event queue when it is received by our dummy object.
2023-07-04 04:37:36 -05:00
static bool event_target_received_event(Badge<EventLoopImplementationQtEventTarget>, QEvent* event);
Ladybird+LibCore: Use QCoreApplication to drive the main Qt event loop Using QEventLoop works for everything but it breaks *one* little feature that we care about: automatically quitting the app when all windows have been closed. That only works if you drive the outermost main event loop with a QCoreApplication instead of a QEventLoop. This is unfortunate, as it complicates our API a little bit, but I'm sure we can think of a way to make this nicer someday. In order for QCoreApplication::exec() to process our own ThreadEventQueue, we now have a zero-timer that we kick whenever new events are posted to the thread queue.
2023-04-25 16:53:07 +02:00
Ladybird/Qt: Add Qt implementation of register/unregister_signal
2024-06-29 23:18:20 -06:00
virtual int register_signal(int, Function<void(int)>) override;
virtual void unregister_signal(int) override;
LibCore+Ladybird: Add EventLoopManager interface for persistent state Things such as timers and notifiers aren't specific to one instance of Core::EventLoop, so let's not tie them down to EventLoopImplementation. Instead, move those APIs + signals & a few other things to a new EventLoopManager interface. EventLoopManager also knows how to create a new EventLoopImplementation object.
2023-04-25 17:38:48 +02:00
UI/Qt: Do not create signal notifiers until after an event loop exists We are currently creating a signal socket and socket notifier before the Qt event loop itself has been created. Thus, when we receive a signal, we are not actually notified when we write that signal number to the signal socket. This was also the source of the following error message being displayed on every launch of the browser: QSocketNotifier: Can only be used with threads started with QThread
2024-10-01 11:49:07 -04:00
void set_main_loop_signal_notifiers(Badge<EventLoopImplementationQt>);
LibCore+Ladybird: Add EventLoopManager interface for persistent state Things such as timers and notifiers aren't specific to one instance of Core::EventLoop, so let's not tie them down to EventLoopImplementation. Instead, move those APIs + signals & a few other things to a new EventLoopManager interface. EventLoopManager also knows how to create a new EventLoopImplementation object.
2023-04-25 17:38:48 +02:00
private:
Ladybird/Qt: Add Qt implementation of register/unregister_signal
2024-06-29 23:18:20 -06:00
static void handle_signal(int);
Ladybird: Allow posting events to the Qt event loop from other threads Previously, a QTimer was used to start processing of our event queue in the main Qt event loop. Unfortunately, QTimers are not thread-safe, and disallow starting of a timer from a different thread than it was created in. Instead, use a dummy QObject to post a custom QEvent to the main loop from whatever thread we like, and process our event queue when it is received by our dummy object.
2023-07-04 04:37:36 -05:00
NonnullOwnPtr<EventLoopImplementationQtEventTarget> m_main_thread_event_target;
Ladybird/Qt: Add Qt implementation of register/unregister_signal
2024-06-29 23:18:20 -06:00
QSocketNotifier* m_signal_socket_notifier { nullptr };
int m_signal_socket_fds[2] = { -1, -1 };
Ladybird: Allow posting events to the Qt event loop from other threads Previously, a QTimer was used to start processing of our event queue in the main Qt event loop. Unfortunately, QTimers are not thread-safe, and disallow starting of a timer from a different thread than it was created in. Instead, use a dummy QObject to post a custom QEvent to the main loop from whatever thread we like, and process our event queue when it is received by our dummy object.
2023-07-04 04:37:36 -05:00
};
LibCore+Ladybird: Add EventLoopManager interface for persistent state Things such as timers and notifiers aren't specific to one instance of Core::EventLoop, so let's not tie them down to EventLoopImplementation. Instead, move those APIs + signals & a few other things to a new EventLoopManager interface. EventLoopManager also knows how to create a new EventLoopImplementation object.
2023-04-25 17:38:48 +02:00
class EventLoopImplementationQt final : public Core::EventLoopImplementation {
public:
static NonnullOwnPtr<EventLoopImplementationQt> create() { return adopt_own(*new EventLoopImplementationQt); }
virtual ~EventLoopImplementationQt() override;
virtual int exec() override;
virtual size_t pump(PumpMode) override;
virtual void quit(int) override;
virtual void wake() override;
LibCore+LibWebView: Restore was_exit_requested to EventLoop This method was removed in e015a43b51192be888638d3da752c488e85b54d2 However, it was not exactly *unused* as the commit message would say. This method was the only thing that allowed spin_until to exit when the event loop was cancelled. This happens normally when IPC connections are closed, but also when the process is killed. The logic to properly handle process exit from event loop spins needs to actually notify the caller that their goal condition was not met though. That will be handled in a later commit.
2025-04-29 15:41:18 -06:00
virtual bool was_exit_requested() const override;
Userland: Rename Core::Object to Core::EventReceiver This is a more precise description of what this class actually does.
2023-08-06 18:09:39 +02:00
virtual void post_event(Core::EventReceiver& receiver, NonnullOwnPtr<Core::Event>&&) override;
LibCore+Ladybird: Add EventLoopManager interface for persistent state Things such as timers and notifiers aren't specific to one instance of Core::EventLoop, so let's not tie them down to EventLoopImplementation. Instead, move those APIs + signals & a few other things to a new EventLoopManager interface. EventLoopManager also knows how to create a new EventLoopImplementation object.
2023-04-25 17:38:48 +02:00
UI/Qt: Do not create signal notifiers until after an event loop exists We are currently creating a signal socket and socket notifier before the Qt event loop itself has been created. Thus, when we receive a signal, we are not actually notified when we write that signal number to the signal socket. This was also the source of the following error message being displayed on every launch of the browser: QSocketNotifier: Can only be used with threads started with QThread
2024-10-01 11:49:07 -04:00
void set_main_loop();
Ladybird: Run the Core::EventLoop with a Qt backend This patch adds EventLoopImplementationQt which is a full replacement for the Core::EventLoopImplementationUnix that uses Qt's event loop as a backend instead. This means that Core::Timer, Core::Notifier, and Core::Event delivery are all driven by Qt primitives in the Ladybird UI and WC processes.
2023-04-24 14:51:19 +02:00
private:
LibCore+Ladybird: Add EventLoopManager interface for persistent state Things such as timers and notifiers aren't specific to one instance of Core::EventLoop, so let's not tie them down to EventLoopImplementation. Instead, move those APIs + signals & a few other things to a new EventLoopManager interface. EventLoopManager also knows how to create a new EventLoopImplementation object.
2023-04-25 17:38:48 +02:00
friend class EventLoopManagerQt;
Ladybird+LibCore: Use QCoreApplication to drive the main Qt event loop Using QEventLoop works for everything but it breaks *one* little feature that we care about: automatically quitting the app when all windows have been closed. That only works if you drive the outermost main event loop with a QCoreApplication instead of a QEventLoop. This is unfortunate, as it complicates our API a little bit, but I'm sure we can think of a way to make this nicer someday. In order for QCoreApplication::exec() to process our own ThreadEventQueue, we now have a zero-timer that we kick whenever new events are posted to the thread queue.
2023-04-25 16:53:07 +02:00
EventLoopImplementationQt();
bool is_main_loop() const { return m_main_loop; }
LibWebView+Services+UI: Move the EventLoop implementations to LibWebView We currently compile the Qt event loop files multiple times, for every target which wants to use them. This patch moves these to LibWebView as a central location to avoid this.
2024-11-10 09:23:10 -05:00
NonnullOwnPtr<QEventLoop> m_event_loop;
Ladybird+LibCore: Use QCoreApplication to drive the main Qt event loop Using QEventLoop works for everything but it breaks *one* little feature that we care about: automatically quitting the app when all windows have been closed. That only works if you drive the outermost main event loop with a QCoreApplication instead of a QEventLoop. This is unfortunate, as it complicates our API a little bit, but I'm sure we can think of a way to make this nicer someday. In order for QCoreApplication::exec() to process our own ThreadEventQueue, we now have a zero-timer that we kick whenever new events are posted to the thread queue.
2023-04-25 16:53:07 +02:00
bool m_main_loop { false };
Ladybird: Run the Core::EventLoop with a Qt backend This patch adds EventLoopImplementationQt which is a full replacement for the Core::EventLoopImplementationUnix that uses Qt's event loop as a backend instead. This means that Core::Timer, Core::Notifier, and Core::Event delivery are all driven by Qt primitives in the Ladybird UI and WC processes.
2023-04-24 14:51:19 +02:00
};
}
Reference in a new issue Copy permalink