Commit b8dbac0b authored by Nikolai Kosjar's avatar Nikolai Kosjar

Rename "[Mm]ethod(s)" to "[Ff]unction(s)"

Only methods as programming functions are affected. Besides renaming
some actions like "Switch Between Function Declaration/Definition" this
mostly touches (api) code comments.

This is a follow-up patch to commit 872bfb70.

Change-Id: Icb65e8d73b59a022f8885b14df497169543a3b92
Reviewed-by: default avatarhjk <hjk121@nokiamail.com>
parent a48315ee
......@@ -357,7 +357,7 @@
\image addressbook-tutorial-part2-signals-and-slots.png
Finally, set the window title to "Simple Address Book" using the
\l{QWidget::}{setWindowTitle()} function. The tr() method allows us
\l{QWidget::}{setWindowTitle()} function. The tr() function allows us
to translate user interface strings.
\snippet examples/addressbook-sdk/part2/addressbook.cpp window title
......@@ -827,7 +827,7 @@
when you enter a contact name to look up. Once you click the
dialog's \c findButton, the dialog is hidden and the result code is set to
either QDialog::Accepted or QDialog::Rejected by the FindDialog's
\c findClicked() method. This ensures that you only search for a contact
\c findClicked() function. This ensures that you only search for a contact
if you have typed something in the FindDialog's line edit.
Then proceed to extract the search string, which in this case is
......
......@@ -86,10 +86,10 @@
backward source code compatibility in patch releases, so:
\list
\li Do not add or remove any public API (e.g. global functions,x
public/protected/private methods).
\li Do not reimplement methods (not even inlines,
nor protected or private methods).
\li Do not add or remove any public API (e.g. global functions,
public/protected/private member functions).
\li Do not reimplement functions (not even inlines,
nor protected or private functions).
\li Check
\l {http://wiki.qt-project.org/index.php/Binary_Compatibility_Workarounds}{Binary Compatibility Workarounds}
for ways to preserve binary compatibility.
......@@ -687,7 +687,7 @@
will not remove the const modifier.
\li Do not use \c dynamic_cast, use \c {qobject_cast} for QObjects, or
refactor your design, for example by introducing a \c {type()}
method (see QListWidgetItem), unless you know what you do.
function (see QListWidgetItem), unless you know what you do.
\endlist
\section2 Compiler and Platform-specific Issues
......@@ -854,7 +854,7 @@
binary 0, instead of comparing it to 0.0, or, preferred, move
such code into an implementation file.
\li Do not hide virtual methods in subclasses (\{-Woverloaded-virtual}).
\li Do not hide virtual functions in subclasses (\{-Woverloaded-virtual}).
If the baseclass A has a virtual \c {int val()} and subclass B an
overload with the same name, \c {int val(int x)}, the A \c val function
is hidden. Use the \c using keyword to make it visible again, and
......
......@@ -34,7 +34,7 @@ bool ExamplePlugin::initialize(const QStringList &arguments, QString *errorStrin
// Load settings
// Add actions to menus
// Connect to other plugins' signals
// In the initialize method, a plugin can be sure that the plugins it
// In the initialize function, a plugin can be sure that the plugins it
// depends on have initialized their members.
Q_UNUSED(arguments)
......@@ -62,7 +62,7 @@ bool ExamplePlugin::initialize(const QStringList &arguments, QString *errorStrin
void ExamplePlugin::extensionsInitialized()
{
// Retrieve objects from the plugin manager's object pool
// In the extensionsInitialized method, a plugin can be sure that all
// In the extensionsInitialized function, a plugin can be sure that all
// plugins that depend on it are completely initialized.
}
......
......@@ -20,11 +20,11 @@ public:
ExamplePlugin();
~ExamplePlugin();
//! [plugin methods]
//! [plugin functions]
bool initialize(const QStringList &arguments, QString *errorString);
void extensionsInitialized();
ShutdownFlag aboutToShutdown();
//! [plugin methods]
//! [plugin functions]
//! [slot]
private slots:
......
......@@ -276,11 +276,11 @@
All \QC plugins must be derived from \l{ExtensionSystem::IPlugin} and
are QObjects.
\snippet exampleplugin/exampleplugin.h plugin methods
\snippet exampleplugin/exampleplugin.h plugin functions
The base class defines basic methods that are called during the life cycle
The base class defines basic functions that are called during the life cycle
of a plugin, which are here implemented for your new plugin.
These methods and their roles are described in detail in
These functions and their roles are described in detail in
\l{The Plugin Life Cycle}.
\snippet exampleplugin/exampleplugin.h slot
......@@ -296,8 +296,8 @@
All the necessary header files from the plugin code itself,
from the Core plugin, and from Qt are included in the beginning of the file.
The setup of the menu and menu item
is done in the plugin's \c{initialize} method, which is the first thing called
after the plugin constructor. In that method, the plugin can be sure that the basic
is done in the plugin's \c{initialize} function, which is the first thing called
after the plugin constructor. In that function, the plugin can be sure that the basic
setup of plugin's that it depends on has been done, for example the Core plugin's
\c{ActionManager} instance has been created.
......
......@@ -37,8 +37,8 @@
tracks the state of the plugin.
You can get the \l{ExtensionSystem::PluginSpec} instances via the
plugin manager's \l{ExtensionSystem::PluginManager::plugins()}{plugins()}
method, or, after a plugin is loaded, through the plugin's
\l{ExtensionSystem::IPlugin::pluginSpec()}{pluginSpec()} method.
function, or, after a plugin is loaded, through the plugin's
\l{ExtensionSystem::IPlugin::pluginSpec()}{pluginSpec()} function.
\li Sets the plugins to \c Read state.
......@@ -61,15 +61,15 @@
\li Sets the plugins to \c Loaded state.
\li Calls the \l{ExtensionSystem::IPlugin::initialize()}{initialize()} methods of
all plugins in the order of the load queue. In the \c initialize method,
\li Calls the \l{ExtensionSystem::IPlugin::initialize()}{initialize()} functions of
all plugins in the order of the load queue. In the \c initialize function,
a plugin should make sure that all exported interfaces are set up and available
to other plugins. A plugin can assume that plugins they depend on have set up
their exported interfaces. For example, the \c Core plugin sets up the
\l{Core::ActionManager}, \l{Core::EditorManager} and all other publicly available
interfaces, so other plugins can request and use them.
The \l{ExtensionSystem::IPlugin::initialize()}{initialize()} method of a plugin
The \l{ExtensionSystem::IPlugin::initialize()}{initialize()} function of a plugin
is a good place for
\list
\li registering objects in the plugin manager's object pool
......@@ -82,8 +82,8 @@
\li Sets the plugins to \c Initialized state.
\li Calls the \l{ExtensionSystem::IPlugin::extensionsInitialized()}{extensionsInitialized()}
methods of all plugins in \e reverse order of the load queue. After
the \c extensionsInitialized method, a plugin should be fully initialized, set up
functions of all plugins in \e reverse order of the load queue. After
the \c extensionsInitialized function, a plugin should be fully initialized, set up
and running. A plugin can assume that plugins that depend on it are fully set up,
and can finish the initialization of parts that can be extended by other plugins.
For example, the \c Core plugin assumes that all plugins have registered
......@@ -97,10 +97,10 @@
and afterwards \l{Core::ICore::coreOpened()}{coreOpened()}.
After startup, when the event loop of \QC is running, the plugin manager calls
the \l{ExtensionSystem::IPlugin::delayedInitialize()}{delayedInitialize()} methods of all
the \l{ExtensionSystem::IPlugin::delayedInitialize()}{delayedInitialize()} functions of all
plugins in \e reverse order of the load queue. The calls are done on the main thread, but
separated by a delay of a few milliseconds to ensure responsiveness of \QC.
In the \c delayedInitialize method, a plugin can perform non-critical initialization
In the \c delayedInitialize function, a plugin can perform non-critical initialization
that could unnecessarily delay showing the \QC UI if done during startup.
After all delayed initializations are done the \l{ExtensionSystem::PluginManager}{PluginManager}
......@@ -111,14 +111,14 @@
plugin manager starts its shutdown sequence:
\list 1
\li Calls the \l{ExtensionSystem::IPlugin::aboutToShutdown()}{aboutToShutdown()} methods of
\li Calls the \l{ExtensionSystem::IPlugin::aboutToShutdown()}{aboutToShutdown()} functions of
all plugins in the order of the load queue. Plugins should perform measures
for speeding up the actual shutdown here, like disconnecting signals that
would otherwise needlessly be called.
If a plugin needs to delay the real shutdown for a while, for example if
it needs to wait for external processes to finish for a clean shutdown,
the plugin can return \l{ExtensionSystem::IPlugin::AsynchronousShutdown} from this
method. This will make the plugin manager wait with the next step, and keep the main
function. This will make the plugin manager wait with the next step, and keep the main
event loop running, until all plugins requesting AsynchronousShutdown have sent
the asynchronousShutdownFinished() signal.
......
......@@ -199,7 +199,7 @@
\l{The Plugin Manager, the Object Pool, and Registered Objects}{global object pool}
via ExtensionSystem::PluginManager::getObjectByName() or
ExtensionSystem::PluginManager::getObjectByClassName(), and use QMetaObject functions to call
methods on it.
functions on it.
\section2 Command Line Arguments
......@@ -210,7 +210,7 @@
line parsing and sanity checks based on that information.
If the plugin manager finds matching command line arguments for a plugin,
it passes them on to the plugin's
\l{ExtensionSystem::IPlugin::initialize()}{initialize()} method.
\l{ExtensionSystem::IPlugin::initialize()}{initialize()} function.
All command line argument definitions are enclosed by a single \c argumentList
tag. The individual command line arguments are defined by the \c argument tag,
......
......@@ -38,13 +38,13 @@
and retrieved depending on different criteria.
Most interaction of plugins with the plugin manager should be done through the
ExtensionSystem::IPlugin interface, but the following tables summarize some methods
ExtensionSystem::IPlugin interface, but the following tables summarize some functions
and signals that can be useful for plugins.
See the ExtensionSystem::PluginManager reference documentation for the complete list.
\table
\header
\li Method
\li Function
\li Description
\row
\li instance()
......@@ -97,9 +97,9 @@
All objects of a specified type can be retrieved from the object pool
via the \l{ExtensionSystem::PluginManager::getObjects()}{getObjects()} and
\l{ExtensionSystem::PluginManager::getObject()}{getObject()} methods.
They are aware of Aggregation::Aggregate, so these methods use the Aggregation::query() methods
instead of qobject_cast to determine the matching objects.
\l{ExtensionSystem::PluginManager::getObject()}{getObject()} functions.
They are aware of Aggregation::Aggregate, so these functions use the Aggregation::query()
functions instead of qobject_cast to determine the matching objects.
It is also possible to retrieve an object with a specific object name with
\l{ExtensionSystem::PluginManager::getObjectByName()}{getObjectByName()}
......
......@@ -240,7 +240,7 @@
The complete code of \c webpagewizard.cpp looks as follows:
\snippet webpagewizard/webpagewizard.cpp 0
The registration of the wizard in the \c initialize() method
The registration of the wizard in the \c initialize() function
of a plugin looks like:
\snippet webpagewizard/webpagewizardplugin.cpp 0
*/
......@@ -1011,7 +1011,7 @@
easier to employ the Dumper Python class for that purpose. The Dumper
Python class contains a complete framework to take care of the \c iname and
\c addr fields, to handle children of simple types, references, pointers,
enums, known and unknown structs as well as some convenience methods to
enums, known and unknown structs as well as some convenience functions to
handle common situations.
The member functions of the \gui{Dumper} class are the following:
......@@ -1021,7 +1021,7 @@
\li \gui{__init__(self)} - Initializes the output to an empty string and
empties the child stack. This should not be used in user code.
\li \gui{put(self, value)} - Low level method to directly append to the
\li \gui{put(self, value)} - Low level function to directly append to the
output string. That is also the fastest way to append output.
\li \gui{putField(self, name, value)} - Appends a name='value' field.
......
......@@ -151,13 +151,13 @@
You can also select the symbol and press \key F2, or right-click the symbol
and select \gui {Follow Symbol Under Cursor} to move to its definition or
declaration. This feature is supported for namespaces, classes, methods,
declaration. This feature is supported for namespaces, classes, functions,
variables, include statements, and macros.
To switch between the definition and declaration of a method, place the
To switch between the definition and declaration of a function, place the
cursor on either and press \key {Shift+F2} or right-click and select \gui
{Switch Between Method Declaration/Definition}. For example, this allows
you to navigate from anywhere within a method body directly to the method
{Switch Between Function Declaration/Definition}. For example, this allows
you to navigate from anywhere within a function body directly to the function
declaration.
Links are opened in the same split by default. To open links in the next
......
......@@ -45,7 +45,7 @@
Use the incremental and advanced search to search from currently
open projects or files on the file system or use the locator to
browse through projects, files, classes, methods, documentation and
browse through projects, files, classes, functions, documentation and
file systems.
\li \l{Refactoring}
......
......@@ -43,7 +43,7 @@
\li Class fields
\li Virtual methods
\li Virtual functions
\endlist
......@@ -1062,9 +1062,9 @@
\li Interpret the \key Tab and \key Backspace key presses.
\li Indent the contents of classes, methods, blocks, and namespaces.
\li Indent the contents of classes, functions, blocks, and namespaces.
\li Indent braces in classes, namespaces, enums, methods, and blocks.
\li Indent braces in classes, namespaces, enums, functions, and blocks.
\li Control switch statements and their contents.
......@@ -1178,14 +1178,14 @@
You can indent public, protected, and private statements and declarations
related to them within classes.
You can also indent statements within methods and blocks and declarations
You can also indent statements within functions and blocks and declarations
within namespaces.
\image qtcreator-code-style-content.png "Content options"
\section1 Specifying Settings for Braces
You can indent class, namespace, enum and method declarations and code
You can indent class, namespace, enum and function declarations and code
blocks.
\image qtcreator-code-style-braces.png "Braces options"
......@@ -1422,7 +1422,7 @@
\endlist
\note You can also select \gui{Edit > Find/Replace > Advanced Find >
C++ Symbols} to search for classes, methods, enums, and declarations
C++ Symbols} to search for classes, functions, enums, and declarations
either from files listed as part of the project or from all files that
are used by the code, such as include files.
......@@ -1523,7 +1523,7 @@
\li Create variable declarations
\li Create method declarations and definitions
\li Create function declarations and definitions
\endlist
......@@ -1817,21 +1817,21 @@
}
\endcode
\li Method name
\li Function name
\row
\li Add 'Function' Declaration
\li Inserts the member function declaration that matches the member function
definition into the class declaration. The function can be public,
protected, private, public slot, protected slot, or private slot.
\li Method name
\li Function name
\row
\li Switch with Next/Previous Parameter
\li Moves a parameter down or up one position in a parameter list.
\li Parameter in the declaration or definition of a function or method
\li Parameter in the declaration or definition of a function
\row
\li Extract Method
\li Moves the selected code to a new method and replaces the block of
code with a call to the new method. Enter a name for the method in
\li Extract Function
\li Moves the selected code to a new function and replaces the block of
code with a call to the new function. Enter a name for the function in
the \gui {Extract Function Refactoring} dialog.
\li Block of code selected
\row
......@@ -1875,8 +1875,8 @@
\li Generate Missing Q_PROPERTY Members
\li Adds missing members to a Q_PROPERTY:
\list
\li \c read method
\li \c write method, if there is a WRITE
\li \c read function
\li \c write function, if there is a WRITE
\li \c {onChanged} signal, if there is a NOTIFY
\li data member with the name \c {m_<propertyName>}
\endlist
......@@ -2187,7 +2187,7 @@
\endlist
Filters locating files also accept paths, such as \c {tools/*main.cpp}.
Filters locating class and method definitions also accept namespaces,
Filters locating class and function definitions also accept namespaces,
such as \c {Utils::*View}.
By default, the following filters are enabled and you do not need to use
......
......@@ -45,7 +45,7 @@
\li \l{Searching with the Locator}
The locator provides one of the easiest ways in \QC to browse
through projects, files, classes, methods, documentation and
through projects, files, classes, functions, documentation and
file systems.
\endlist
......
......@@ -391,14 +391,14 @@
\row
\li Follow symbol under cursor
Works with namespaces, classes, methods, variables, include
Works with namespaces, classes, functions, variables, include
statements and macros
\li F2
\row
\li Rename symbol under cursor
\li Ctrl+Shift+R
\row
\li Switch between method declaration and definition
\li Switch between function declaration and definition
\li Shift+F2
\row
\li Open type hierarchy
......
......@@ -212,7 +212,7 @@
\section1 Locating Files
The \gui Locator provides one of the easiest ways in \QC to browse
through projects, files, classes, methods, documentation and file systems.
through projects, files, classes, functions, documentation and file systems.
To quickly access files not directly mentioned in your project, you can
create your own locator filters. That way you can locate files in a
directory structure you have defined.
......
......@@ -56,7 +56,7 @@
output panes (7).
You can use the locator (6) to to browse through projects, files, classes,
methods, documentation, and file systems.
functions, documentation, and file systems.
\section1 Modes
......
......@@ -281,17 +281,17 @@
The locator can be used to open files, but opening files is also just a
step on the way to accomplish a task. For example, consider the following
use case: \e {Fix AMethod in SomeClass which comes from
use case: \e {Fix AFunction in SomeClass which comes from
someclass.cpp/someclass.h}.
With a tabbed user interface, developers would search for someclass.cpp in
the tab bar, and then search for \c {::AMethod}, only to find out that the
method is not located in that file. They would then search for someclass.h
the tab bar, and then search for \c {::AFunction}, only to find out that the
function is not located in that file. They would then search for someclass.h
in the tab bar, find our that the function is inline, fix the problem, and
forget where they came from.
With \QC, developers can type \c {Ctrl+K m AMet} to find the method.
Typically, they only need to type 3 to 4 characters of the method name.
With \QC, developers can type \c {Ctrl+K m AFun} to find the function.
Typically, they only need to type 3 to 4 characters of the function name.
They can then fix the problem and press \key Alt+Back to go back to where
they were.
......
......@@ -38,7 +38,7 @@ QT_BEGIN_NAMESPACE
class QScriptEngine;
class QDeclarativeEngine;
// Helper methods to access private API through a stable interface
// Helper functions to access private API through a stable interface
// This is used in the qmljsdebugger library of QtCreator.
class QMLJSDEBUGGER_EXTERN QDeclarativeDebugHelper
{
......
......@@ -34,7 +34,7 @@ bool %PluginName%Plugin::initialize(const QStringList &arguments, QString *error
// Load settings
// Add actions to menus
// Connect to other plugins' signals
// In the initialize method, a plugin can be sure that the plugins it
// In the initialize function, a plugin can be sure that the plugins it
// depends on have initialized their members.
Q_UNUSED(arguments)
......@@ -57,7 +57,7 @@ bool %PluginName%Plugin::initialize(const QStringList &arguments, QString *error
void %PluginName%Plugin::extensionsInitialized()
{
// Retrieve objects from the plugin manager's object pool
// In the extensionsInitialized method, a plugin can be sure that all
// In the extensionsInitialized function, a plugin can be sure that all
// plugins that depend on it are completely initialized.
}
......
......@@ -29,10 +29,10 @@
/*
All firstToken/lastToken methods below which have a doxygen comment with
All firstToken/lastToken functions below which have a doxygen comment with
\generated in it, will be re-generated when the tool "cplusplus-update-frontend" is run.
For methods which are hand-coded, or which should not be changed, make sure that
For functions which are hand-coded, or which should not be changed, make sure that
the comment is gone.
*/
......
......@@ -56,7 +56,7 @@
other components in the Aggregate to the outside.
Specifically that means:
\list
\li They can be "cast" to each other (using query and query_all methods).
\li They can be "cast" to each other (using query and query_all functions).
\li Their life cycle is coupled, i.e. whenever one is deleted all of them are.
\endlist
Components can be of any QObject derived type.
......@@ -69,7 +69,7 @@
[...]
MyInterface *object = new MyInterface; // this is single inheritance
\endcode
The query method works like a qobject_cast with normal objects:
The query function works like a qobject_cast with normal objects:
\code
Q_ASSERT(query<MyInterface>(object) == object);
Q_ASSERT(query<MyInterfaceEx>(object) == 0);
......@@ -105,7 +105,7 @@
/*!
\fn T *Aggregate::component()
Template method that returns the component with the given type, if there is one.
Template function that returns the component with the given type, if there is one.
If there are multiple components with that type a random one is returned.
\sa Aggregate::components()
......@@ -115,7 +115,7 @@
/*!
\fn QList<T *> Aggregate::components()
Template method that returns all components with the given type, if there are any.
Template function that returns all components with the given type, if there are any.
\sa Aggregate::component()
\sa Aggregate::add()
......
......@@ -474,7 +474,7 @@ void Document::setGlobalNamespace(Namespace *globalNamespace)
* Extract the function name including scope at the given position.
*
* Note that a function (scope) starts at the name of that function, not at the return type. The
* implication is that this method will return an empty string when the line/column is on the
* implication is that this function will return an empty string when the line/column is on the
* return type.
*
* \param line the line number, starting with line 1
......
......@@ -687,7 +687,7 @@ QString Preprocessor::State::guardStateToString(int guardState)
* occurs inside the #ifndef block, but not nested inside other
* #if/#ifdef/#ifndef blocks.
*
* This method tracks the state, and is called from \c updateIncludeGuardState
* This function tracks the state, and is called from \c updateIncludeGuardState
* which handles the most common no-op cases.
*
* @param hint indicates what kind of token is encountered in the input
......@@ -857,7 +857,7 @@ _Lagain:
// to the macro that generated this token. In either case, the macro
// that generated the token still needs to be blocked (!), which is
// recorded in the token buffer. Removing the blocked macro and the
// empty token buffer happens the next time that this method is called.
// empty token buffer happens the next time that this function is called.
} else {
// No token buffer, so have the lexer scan the next token.
tk->setSource(m_state.m_source);
......
......@@ -64,10 +64,10 @@
\list 1
\li All plugin libraries are loaded in \e{root-to-leaf} order of the
dependency tree.
\li All plugins' initialize methods are called in \e{root-to-leaf} order
\li All plugins' initialize functions are called in \e{root-to-leaf} order
of the dependency tree. This is a good place to put
objects in the plugin manager's object pool.
\li All plugins' extensionsInitialized methods are called in \e{leaf-to-root}
\li All plugins' extensionsInitialized functions are called in \e{leaf-to-root}
order of the dependency tree. At this point, plugins can
be sure that all plugins that depend on this plugin have
been initialized completely (implying that they have put
......@@ -79,7 +79,7 @@
Plugins have access to the plugin manager
(and its object pool) via the PluginManager::instance()
method.
function.
*/
/*!
......@@ -87,10 +87,10 @@
\brief Called after the plugin has been loaded and the IPlugin instance
has been created.
The initialize methods of plugins that depend
on this plugin are called after the initialize method of this plugin
The initialize functions of plugins that depend
on this plugin are called after the initialize function of this plugin
has been called. Plugins should initialize their internal state in this
method. Returns if initialization of successful. If it wasn't successful,
function. Returns if initialization of successful. If it wasn't successful,
the \a errorString should be set to a user-readable message
describing the reason.
......@@ -100,11 +100,11 @@
/*!
\fn void IPlugin::extensionsInitialized()
\brief Called after the IPlugin::initialize() method has been called,
\brief Called after the IPlugin::initialize() function has been called,
and after both the IPlugin::initialize() and IPlugin::extensionsInitialized()
methods of plugins that depend on this plugin have been called.
functions of plugins that depend on this plugin have been called.
In this method, the plugin can assume that plugins that depend on
In this function, the plugin can assume that plugins that depend on
this plugin are fully 'up and running'. It is a good place to
look in the plugin manager's object pool for objects that have
been provided by dependent plugins.
......@@ -115,17 +115,17 @@
/*!
\fn bool IPlugin::delayedInitialize()
\brief Called after all plugins' IPlugin::extensionsInitialized() method has been called,
and after the IPlugin::delayedInitialize() method of plugins that depend on this plugin
\brief Called after all plugins' IPlugin::extensionsInitialized() function has been called,
and after the IPlugin::delayedInitialize() function of plugins that depend on this plugin
have been called.
The plugins' delayedInitialize() methods are called after the application is already running,
The plugins' delayedInitialize() functions are called after the application is already running,
with a few milliseconds delay to application startup, and between individual delayedInitialize
method calls. To avoid unnecessary delays, a plugin should return true from the method if it
function calls. To avoid unnecessary delays, a plugin should return true from the function if it
actually implements it, to indicate that the next plugins' delayedInitialize() call should
be delayed a few milliseconds to give input and paint events a chance to be processed.
This method can be used if a plugin needs to do non-trivial setup that doesn't
This function can be used if a plugin needs to do non-trivial setup that doesn't
necessarily needs to be done directly at startup, but still should be done within a
short time afterwards. This can increase the felt plugin/application startup
time a lot, with very little effort.
......@@ -139,16 +139,16 @@
\brief Called during a shutdown sequence in the same order as initialization
before the plugins get deleted in reverse order.
This method should be used to disconnect from other plugins,
This function should be used to disconnect from other plugins,
hide all UI, and optimize shutdown in general.
If a plugin needs to delay the real shutdown for a while, for example if
it needs to wait for external processes to finish for a clean shutdown,
the plugin can return IPlugin::AsynchronousShutdown from this method. This
the plugin can return IPlugin::AsynchronousShutdown from this function. This
will keep the main event loop running after the aboutToShutdown() sequence
has finished, until all plugins requesting AsynchronousShutdown have sent
the asynchronousShutdownFinished() signal.
The default implementation of this method does nothing and returns
The default implementation of this function does nothing and returns
IPlugin::SynchronousShutdown.
Returns IPlugin::AsynchronousShutdown if the plugin needs to perform
......@@ -160,7 +160,7 @@
/*!
\fn QObject *IPlugin::remoteCommand(const QStringList &options, const QStringList &arguments)
\brief When \QC is executed with the -client argument while already another instance of \QC
is running, this method of plugins is called in the running instance.
is running, this function of plugins is called in the running instance.
Plugin-specific arguments are passed in \a options, while the rest of the
arguments are passed in \a arguments.
......@@ -215,7 +215,7 @@ PluginSpec *IPlugin::pluginSpec() const
/*!
\fn void IPlugin::addObject(QObject *obj)
Convenience method that registers \a obj in the plugin manager's
Convenience function that registers \a obj in the plugin manager's
plugin pool by just calling PluginManager::addObject().
*/
void IPlugin::addObject(QObject *obj)
......@@ -225,7 +225,7 @@ void IPlugin::addObject(QObject *obj)
/*!
\fn void IPlugin::addAutoReleasedObject(QObject *obj)
Convenience method for registering \a obj in the plugin manager's
Convenience function for registering \a obj in the plugin manager's
plugin pool. Usually, registered objects must be removed from
the object pool and deleted by hand.
Objects added to the pool via addAutoReleasedObject are automatically
......@@ -241,7 +241,7 @@ void IPlugin::addAutoReleasedObject(QObject *obj)
/*!
\fn void IPlugin::removeObject(QObject *obj)
Convenience method that unregisters \a obj from the plugin manager's
Convenience function that unregisters \a obj from the plugin manager's
plugin pool by just calling PluginManager::removeObject().
*/
void IPlugin<