beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-22 15:40:19 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/Ladybird/Qt/EventLoopImplementationQt.h

90 lines
2.8 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 12:51:19 +00:00
/*
* Copyright (c) 2022-2023, Andreas Kling <kling@serenityos.org>
*
* 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 09:37:36 +00: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 12:51:19 +00:00
#include <AK/HashMap.h>
#include <AK/NonnullOwnPtr.h>
#include <AK/OwnPtr.h>
#include <LibCore/EventLoopImplementation.h>
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 09:37:36 +00:00
#include <QEvent>
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 12:51:19 +00:00
#include <QEventLoop>
#include <QSocketNotifier>
#include <QTimer>
namespace Ladybird {
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 09:37:36 +00: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 15:38:48 +00: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 12:51:19 +00: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 15:38:48 +00: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 12:51:19 +00:00
Userland: Rename Core::Object to Core::EventReceiver This is a more precise description of what this class actually does.
2023-08-06 16:09:39 +00:00
virtual int register_timer(Core::EventReceiver&, int milliseconds, bool should_reload, Core::TimerShouldFireWhenNotVisible) 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 12:51:19 +00:00
virtual bool unregister_timer(int timer_id) override;
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 14:53:07 +00: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 09:37:36 +00: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 14:53:07 +00: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 15:38:48 +00:00
// FIXME: These APIs only exist for obscure use-cases inside SerenityOS. Try to get rid of them.
virtual int register_signal(int, Function<void(int)>) override { return 0; }
virtual void unregister_signal(int) override { }
private:
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 09:37:36 +00:00
NonnullOwnPtr<EventLoopImplementationQtEventTarget> m_main_thread_event_target;
};
class QtEventLoopManagerEvent final : public QEvent {
public:
static QEvent::Type process_event_queue_event_type()
{
static auto const type = static_cast<QEvent::Type>(QEvent::registerEventType());
return type;
}
QtEventLoopManagerEvent(QEvent::Type type)
: QEvent(type)
{
}
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 15:38:48 +00: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;
Userland: Rename Core::Object to Core::EventReceiver This is a more precise description of what this class actually does.
2023-08-06 16:09:39 +00: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 15:38:48 +00:00
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 12:51:19 +00:00
// FIXME: These APIs only exist for obscure use-cases inside SerenityOS. Try to get rid of them.
virtual void unquit() override { }
virtual bool was_exit_requested() const override { return false; }
virtual void notify_forked_and_in_child() 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 14:53:07 +00:00
void set_main_loop() { m_main_loop = true; }
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 12:51:19 +00: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 15:38:48 +00: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 14:53:07 +00:00
EventLoopImplementationQt();
bool is_main_loop() const { return m_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 12:51:19 +00:00
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 14:53:07 +00: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 12:51:19 +00:00
};
}
Reference in a new issue Copy permalink