Struct rute::auto::core_application::CoreApplication
source · pub struct CoreApplication<'a> { /* private fields */ }
Expand description
Notice these docs are heavy WIP and not very relevent yet
This class is used by non-GUI applications to provide their event loop. For non-GUI application that uses Qt, there should be exactly one QCoreApplication object. For GUI applications, see QGuiApplication. For applications that use the Qt Widgets module, see QApplication.
QCoreApplication contains the main event loop, where all events from the operating system (e.g., timer and network events) and other sources are processed and dispatched. It also handles the application’s initialization and finalization, as well as system-wide and application-wide settings.
The Event Loop and Event Handling
The event loop is started with a call to exec(). Long-running operations can call processEvents() to keep the application responsive.
In general, we recommend that you create a QCoreApplication,
QGuiApplication or a QApplication object in your main()
function as early as possible. exec() will not return until
the event loop exits; e.g., when quit() is called.
Several static convenience functions are also provided. The QCoreApplication object is available from instance(). Events can be sent with sendEvent() or posted to an event queue with postEvent(). Pending events can be removed with removePostedEvents() or dispatched with sendPostedEvents().
The class provides a quit() slot and an aboutToQuit() signal.
Application and Library Paths
An application has an applicationDirPath() and an applicationFilePath(). Library paths (see QLibrary) can be retrieved with libraryPaths() and manipulated by setLibraryPaths(), addLibraryPath(), and removeLibraryPath().
Internationalization and Translations
Translation files can be added or removed using installTranslator() and removeTranslator(). Application strings can be translated using translate(). The QObject::tr() and QObject::trUtf8() functions are implemented in terms of translate().
Accessing Command Line Arguments
The command line arguments which are passed to QCoreApplication’s constructor should be accessed using the arguments() function.
Note: QCoreApplication removes option -qmljsdebugger="...".
It parses the
argument of qmljsdebugger,
and then removes this option plus its argument.
For more advanced command line option handling, create a QCommandLineParser.
Locale Settings
On Unix/Linux Qt is configured to use the system locale settings by
default. This can cause a conflict when using POSIX functions, for
instance, when converting between data types such as floats and
strings, since the notation may differ between locales. To get
around this problem, call the POSIX function setlocale(LC_NUMERIC,"C")
right after initializing QApplication, QGuiApplication or QCoreApplication
to reset the locale that is used for number formatting to -locale.
See also: GuiApplication
[AbstractEventDispatcher
]
[EventLoop
]
{Semaphores Example}
{Wait Conditions Example}
Licence
The documentation is an adoption of the original Qt Documentation and provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation.
Implementations
sourceimpl<'a> CoreApplication<'a>
impl<'a> CoreApplication<'a>
sourcepub fn set_organization_domain(org_domain: &str)
pub fn set_organization_domain(org_domain: &str)
Returns the list of command-line arguments.
Usually arguments().at(0) is the program name, arguments().at(1) is the first argument, and arguments().last() is the last argument. See the note below about Windows.
Calling this function is slow - you should store the result in a variable when parsing the command line.
Warning: On Unix, this list is built from the argc and argv parameters passed to the constructor in the main() function. The string-data in argv is interpreted using QString::fromLocal8Bit(); hence it is not possible to pass, for example, Japanese command line arguments on a system that runs in a Latin1 locale. Most modern Unix systems do not have this limitation, as they are Unicode-based.
On Windows, the list is built from the argc and argv parameters only if modified argv/argc parameters are passed to the constructor. In that case, encoding problems might occur.
Otherwise, the arguments() are constructed from the return value of GetCommandLine()
As a result of this, the string given by arguments().at(0) might not be the program name on Windows, depending on how the application was started.
See also: [application_file_path()
]
[CommandLineParser
]
sourcepub fn organization_domain() -> String
pub fn organization_domain() -> String
The value is used by the QSettings class when it is constructed using the empty constructor. This saves having to repeat this information each time a QSettings object is created.
On Mac, QSettings uses organizationDomain() as the organization if it’s not an empty string; otherwise it uses organizationName(). On all other platforms, QSettings uses organizationName() as the organization.
See also: organizationName applicationName applicationVersion
pub fn set_organization_name(org_name: &str)
sourcepub fn organization_name() -> String
pub fn organization_name() -> String
The value is used by the QSettings class when it is constructed using the empty constructor. This saves having to repeat this information each time a QSettings object is created.
On Mac, QSettings uses organizationDomain() as the organization if it’s not an empty string; otherwise it uses organizationName(). On all other platforms, QSettings uses organizationName() as the organization.
See also: organizationDomain applicationName
pub fn set_application_name(application: &str)
sourcepub fn application_name() -> String
pub fn application_name() -> String
The value is used by the QSettings class when it is constructed using the empty constructor. This saves having to repeat this information each time a QSettings object is created.
If not set, the application name defaults to the executable name (since 5.0).
See also: organizationName
organizationDomain
applicationVersion
[application_file_path()
]
pub fn set_application_version(version: &str)
sourcepub fn application_version() -> String
pub fn application_version() -> String
If not set, the application version defaults to a platform-specific value determined from the main application executable or package (since Qt 5.9):
-
Platform
-
Source
-
Windows (classic desktop)
-
PRODUCTVERSION parameter of the VERSIONINFO resource
-
Universal Windows Platform
-
version attribute of the application package manifest
-
macOS, iOS, tvOS, watchOS
-
CFBundleVersion property of the information property list
-
Android
-
android:versionName property of the AndroidManifest.xml manifest element
On other platforms, the default is the empty string.
See also: applicationName organizationName organizationDomain
sourcepub fn set_setuid_allowed(allow: bool)
pub fn set_setuid_allowed(allow: bool)
Allows the application to run setuid on UNIX platforms if allow is true.
If allow is false (the default) and Qt detects the application is running with an effective user id different than the real user id, the application will be aborted when a QCoreApplication instance is created.
Qt is not an appropriate solution for setuid programs due to its large attack surface. However some applications may be required to run in this manner for historical reasons. This flag will prevent Qt from aborting the application when this is detected, and must be set before a QCoreApplication instance is created.
Note: It is strongly recommended not to enable this option since it introduces security risks.
sourcepub fn is_setuid_allowed() -> bool
pub fn is_setuid_allowed() -> bool
Returns true if the application is allowed to run setuid on UNIX platforms.
See also: CoreApplication::set_setuid_allowed
sourcepub fn instance() -> Option<CoreApplication<'a>>
pub fn instance() -> Option<CoreApplication<'a>>
Returns a pointer to the application’s QCoreApplication (or QGuiApplication/QApplication) instance.
If no instance has been allocated, null
is returned.
sourcepub fn exec() -> i32
pub fn exec() -> i32
Enters the main event loop and waits until exit() is called. Returns the value that was passed to exit() (which is 0 if exit() is called via quit()).
It is necessary to call this function to start event handling. The main event loop receives events from the window system and dispatches these to the application widgets.
To make your application perform idle processing (by executing a special function whenever there are no pending events), use a QTimer with 0 timeout. More advanced idle processing schemes can be achieved using processEvents().
We recommend that you connect clean-up code to the
aboutToQuit()
signal, instead of putting it in
your application’s main()
function because on some platforms the
exec() call may not return. For example, on Windows
when the user logs off, the system terminates the process after Qt
closes all top-level windows. Hence, there is no guarantee that the
application will have time to exit its event loop and execute code at
the end of the main()
function after the exec()
call.
See also: [quit()
]
[exit()
]
[process_events()
]
Application::exec
sourcepub fn exit(retcode: i32)
pub fn exit(retcode: i32)
Processes all pending events for the calling thread according to the specified flags until there are no more events to process.
You can call this function occasionally when your program is busy performing a long operation (e.g. copying a file).
In the event that you are running a local loop which calls this function continuously, without an event loop, the DeferredDelete events will not be processed. This can affect the behaviour of widgets, e.g. QToolTip, that rely on DeferredDelete
events to function properly. An alternative would be to call sendPostedEvents() from within that local loop.
Calling this function processes events only for the calling thread.
See also: [exec()
]
[Timer
]
[EventLoop::process_events
]
[flush()
]
[send_posted_events()
]
Overloads processEvents() Processes pending events for the calling thread for maxtime milliseconds or until there are no more events to process, whichever is shorter.
You can call this function occasionally when your program is busy doing a long operation (e.g. copying a file).
Calling this function processes events only for the calling thread.
See also: [exec()
]
[Timer
]
[EventLoop::process_events
]
Processes all pending events for the calling thread according to the specified flags until there are no more events to process.
You can call this function occasionally when your program is busy performing a long operation (e.g. copying a file).
In the event that you are running a local loop which calls this function continuously, without an event loop, the DeferredDelete events will not be processed. This can affect the behaviour of widgets, e.g. QToolTip, that rely on DeferredDelete
events to function properly. An alternative would be to call sendPostedEvents() from within that local loop.
Calling this function processes events only for the calling thread.
See also: [exec()
]
[Timer
]
[EventLoop::process_events
]
[flush()
]
[send_posted_events()
]
Overloads processEvents() Processes pending events for the calling thread for maxtime milliseconds or until there are no more events to process, whichever is shorter.
You can call this function occasionally when your program is busy doing a long operation (e.g. copying a file).
Calling this function processes events only for the calling thread.
See also: [exec()
]
[Timer
]
[EventLoop::process_events
]
Tells the application to exit with a return code.
After this function has been called, the application leaves the main event loop and returns from the call to exec(). The exec() function returns returnCode. If the event loop is not running, this function does nothing.
By convention, a returnCode of 0 means success, and any non-zero value indicates an error.
It’s good practice to always connect signals to this slot using a QueuedConnection . If a signal connected (non-queued) to this slot is emitted before control enters the main event loop (such as before calls exec() ), the slot has no effect and the application never exits. Using a queued connection ensures that the slot will not be invoked until after control enters the main event loop.
Note that unlike the C library function of the same name, this function does return to the caller – it is event processing that stops.
See also: [quit()
]
[exec()
]
sourcepub fn send_event<E: EventTrait<'a>, O: ObjectTrait<'a>>(
receiver: &O,
event: &E
) -> bool
pub fn send_event<E: EventTrait<'a>, O: ObjectTrait<'a>>(
receiver: &O,
event: &E
) -> bool
Sends event event directly to receiver receiver, using the notify() function. Returns the value that was returned from the event handler.
The event is not deleted when the event has been sent. The normal approach is to create the event on the stack, for example:
See also: [post_event()
]
[notify()
]
sourcepub fn post_event<E: EventTrait<'a>, O: ObjectTrait<'a>>(
receiver: &O,
event: &E,
priority: i32
)
pub fn post_event<E: EventTrait<'a>, O: ObjectTrait<'a>>(
receiver: &O,
event: &E,
priority: i32
)
Adds the event event, with the object receiver as the receiver of the event, to an event queue and returns immediately.
The event must be allocated on the heap since the post event queue will take ownership of the event and delete it once it has been posted. It is not safe to access the event after it has been posted.
When control returns to the main event loop, all events that are stored in the queue will be sent using the notify() function.
Events are sorted in descending priority order, i.e. events with a high priority are queued before events with a lower priority. The priority can be any integer value, i.e. between INT_MAX and INT_MIN, inclusive; see Qt::EventPriority for more details. Events with equal priority will be processed in the order posted.
See also: [send_event()
]
[notify()
]
[send_posted_events()
]
[t::event_priority()
]
sourcepub fn send_posted_events<O: ObjectTrait<'a>>(receiver: &O, event_type: i32)
pub fn send_posted_events<O: ObjectTrait<'a>>(receiver: &O, event_type: i32)
Immediately dispatches all events which have been previously queued with QCoreApplication::postEvent() and which are for the object receiver and have the event type event_type.
Events from the window system are not dispatched by this function, but by processEvents().
If receiver is null, the events of event_type are sent for all objects. If event_type is 0, all the events are sent for receiver.
Note: This method must be called from the thread in which its QObject parameter, receiver, lives.
See also: [flush()
]
[post_event()
]
sourcepub fn remove_posted_events<O: ObjectTrait<'a>>(receiver: &O, event_type: i32)
pub fn remove_posted_events<O: ObjectTrait<'a>>(receiver: &O, event_type: i32)
Removes all events of the given eventType that were posted using postEvent() for receiver.
The events are not dispatched, instead they are removed from the queue. You should never need to call this function. If you do call it, be aware that killing events may cause receiver to break one or more invariants.
If receiver is null, the events of eventType are removed for all objects. If eventType is 0, all the events are removed for receiver. You should never call this function with eventType of 0. If you do call it in this way, be aware that killing events may cause receiver to break one or more invariants.
pub fn has_pending_events() -> bool
sourcepub fn starting_up() -> bool
pub fn starting_up() -> bool
Sends event to receiver: receiver ->event( event). Returns the value that is returned from the receiver’s event handler. Note that this function is called for all events sent to any object in any thread.
For certain types of events (e.g. mouse and key events),
the event will be propagated to the receiver’s parent and so on up to
the top-level object if the receiver is not interested in the event
(i.e., it returns false).
There are five different ways that events can be processed; reimplementing this virtual function is just one of them. All five approaches are listed below:
- Reimplementing paintEvent() , mousePressEvent() and so on. This is the most common, easiest, and least powerful way.
- Reimplementing this function. This is very powerful, providing complete control; but only one subclass can be active at a time.
- Installing an event filter on QCoreApplication::instance(). Such an event filter is able to process all events for all widgets, so it’s just as powerful as reimplementing notify(); furthermore, it’s possible to have more than one application-global event filter. Global event filters even see mouse events for disabled widgets . Note that application event filters are only called for objects that live in the main thread.
- Reimplementing QObject::event() (as QWidget does). If you do this you get Tab key presses, and you get to see the events before any widget-specific event filters.
- Installing an event filter on the object. Such an event filter gets all the events, including Tab and Shift+Tab key press events, as long as they do not change the focus widget.
Future direction: This function will not be called for objects that live outside the main thread in Qt 6. Applications that need that functionality should find other solutions for their event inspection needs in the meantime. The change may be extended to the main thread, causing this function to be deprecated.
Warning: If you override this function, you must ensure all threads that process events stop doing so before your application object begins destruction. This includes threads started by other libraries that you may be using, but does not apply to Qt’s own threads.
See also: [Object::event
]
[install_native_event_filter()
]
Returns true
if an application object has not been created yet;
otherwise returns false.
See also: [closing_down()
]
sourcepub fn closing_down() -> bool
pub fn closing_down() -> bool
X11
Returns true
if the application objects are being destroyed;
otherwise returns false.
See also: [starting_up()
]
sourcepub fn application_dir_path() -> String
pub fn application_dir_path() -> String
Returns the directory that contains the application executable.
For example, if you have installed Qt in the C:\Qt
directory, and you run the regexp
example, this function will
return .
On MacOS and iOS this will point to the directory actually containing the executable, which may be inside an application bundle (if the application is bundled).
Warning: On Linux, this function will try to get the path from the
/proc
file system. If that fails, it assumes that argv[0]
contains the absolute file name of the executable. The
function also assumes that the current directory has not been
changed by the application.
See also: [application_file_path()
]
sourcepub fn application_file_path() -> String
pub fn application_file_path() -> String
Returns the file path of the application executable.
For example, if you have installed Qt in the /usr/local/qt
directory, and you run the regexp
example, this function will
return .
Warning: On Linux, this function will try to get the path from the
/proc
file system. If that fails, it assumes that argv[0]
contains the absolute file name of the executable. The
function also assumes that the current directory has not been
changed by the application.
See also: [application_dir_path()
]
sourcepub fn application_pid() -> i64
pub fn application_pid() -> i64
Returns the current process ID for the application.
sourcepub fn add_library_path(arg0: &str)
pub fn add_library_path(arg0: &str)
Returns a list of paths that the application will search when dynamically loading libraries.
The return value of this function may change when a QCoreApplication
is created. It is not recommended to call it before creating a
QCoreApplication. The directory of the application executable ( not
the working directory) is part of the list if it is known. In order
to make it known a QCoreApplication has to be constructed as it will
use argv[0]
to find it.
Qt provides default library paths, but they can also be set using a qt.conf file. Paths specified in this file will override default values. Note that if the qt.conf file is in the directory of the application executable, it may not be found until a QCoreApplication is created. If it is not found when calling this function, the default library paths will be used.
The list will include the installation directory for plugins if
it exists (the default installation directory for plugins is INSTALL/plugins,
where INSTALL
is the directory where Qt was
installed). The colon separated entries of the QT_PLUGIN_PATH
environment variable are always added. The plugin installation
directory (and its existence) may change when the directory of
the application executable becomes known.
If you want to iterate over the list, you can use the foreach
pseudo-keyword:
See also: [set_library_paths()
]
[add_library_path()
]
[remove_library_path()
]
[Library
]
{How to Create Qt Plugins}
Prepends path to the beginning of the library path list, ensuring that it is searched for libraries first. If path is empty or already in the path list, the path list is not changed.
The default path list consists of a single entry, the installation
directory for plugins. The default installation directory for plugins
is INSTALL/plugins,
where INSTALL
is the directory where Qt was
installed.
The library paths are reset to the default when an instance of QCoreApplication is destructed.
See also: [remove_library_path()
]
[library_paths()
]
[set_library_paths()
]
sourcepub fn remove_library_path(arg0: &str)
pub fn remove_library_path(arg0: &str)
Removes path from the library path list. If path is empty or not in the path list, the list is not changed.
The library paths are reset to the default when an instance of QCoreApplication is destructed.
See also: [add_library_path()
]
[library_paths()
]
[set_library_paths()
]
pub fn flush()
pub fn is_quit_lock_enabled() -> bool
pub fn set_quit_lock_enabled(enabled: bool)
sourcepub fn quit()
pub fn quit()
The default is true.
See also: [EventLoopLocker
]
Tells the application to exit with return code 0 (success). Equivalent to calling QCoreApplication::exit(0).
It’s common to connect the QGuiApplication::lastWindowClosed() signal to quit(), and you also often connect e.g. QAbstractButton::clicked() or signals in QAction, QMenu, or QMenuBar to it.
It’s good practice to always connect signals to this slot using a QueuedConnection . If a signal connected (non-queued) to this slot is emitted before control enters the main event loop (such as before calls exec() ), the slot has no effect and the application never exits. Using a queued connection ensures that the slot will not be invoked until after control enters the main event loop.
Example:
See also: [exit()
]
[about_to_quit()
]
[GuiApplication::last_window_closed
]
sourcepub fn set_about_to_quit_event_ud<F, T>(&self, data: &'a T, func: F) -> &Selfwhere
F: Fn(&T) + 'a,
T: 'a,
pub fn set_about_to_quit_event_ud<F, T>(&self, data: &'a T, func: F) -> &Selfwhere
F: Fn(&T) + 'a,
T: 'a,
This signal is emitted when the application is about to quit the main event loop, e.g. when the event loop level drops to zero. This may happen either after a call to quit() from inside the application or when the user shuts down the entire desktop session.
The signal is particularly useful if your application has to do some last-second cleanup. Note that no user interaction is possible in this state.
See also: [quit()
]
pub fn set_about_to_quit_event<F>(&self, func: F) -> &Selfwhere
F: Fn() + 'a,
pub fn set_custom_event<F>(&self, func: F) -> &Selfwhere
F: Fn(&Event<'_>) + 'a,
pub fn build(&self) -> Self
Trait Implementations
sourceimpl<'a> Clone for CoreApplication<'a>
impl<'a> Clone for CoreApplication<'a>
sourcefn clone(&self) -> CoreApplication<'a>
fn clone(&self) -> CoreApplication<'a>
1.0.0 · sourcefn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read more