|
|
|
|
-------------------------------------------------------------------------
|
|
|
|
|
| This document answers some questions about how the startup of KOffice
|
|
|
|
|
| applications works. This file was put together by
|
|
|
|
|
| Eric R. Turner <eric.r.turner@bitbreather.com>
|
|
|
|
|
| from the answers given by David Faure <faure@kde.org>
|
|
|
|
|
-------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
Q: Where is the pointer to the application's instance of KAboutData
|
|
|
|
|
data stored?
|
|
|
|
|
|
|
|
|
|
A: In a static member of the TDECmdLineArgs class.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Q: One of the arguments to KAboutData's constructor is the program
|
|
|
|
|
name. Will this be used later to run the program?
|
|
|
|
|
|
|
|
|
|
A: No (by the time the KAboutData's constructor is called, the program
|
|
|
|
|
is already running). The program name is in fact the "instance name",
|
|
|
|
|
which is used to locate the application's own data
|
|
|
|
|
(/share/apps/<application name>/...) and many other things.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Q: What is the "+[file]" option passed to TDECmdLineArgs?
|
|
|
|
|
|
|
|
|
|
A: KCmdLineOptions describe the TDECmdLineArgs. "+[file]" means that the
|
|
|
|
|
command line arguments can be one or more file names, and that these
|
|
|
|
|
arguments are optional.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Q: What is I18N_NOOP()?
|
|
|
|
|
|
|
|
|
|
A: I18N_NOOP() marks the options description for translation to other
|
|
|
|
|
languages.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Q: What is a KoApplicationInterface used for?
|
|
|
|
|
|
|
|
|
|
A: It allows a KOffice application to participate in Inter-Process
|
|
|
|
|
Communication and Remote Procedure Calls via DCOP.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Q: What is the .desktop file?
|
|
|
|
|
|
|
|
|
|
A: It's responsible for the menu entry, standard KDE stuff. In KOffice
|
|
|
|
|
we add a few useful tags to it, in particular the "native mime type"
|
|
|
|
|
of the component (e.g. application/x-kword for kword).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Q: Is the .desktop file generated by hand?
|
|
|
|
|
|
|
|
|
|
A: Yes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Q: What's a KoDocumentEntry? I couldn't find it in lib/kofficecore.
|
|
|
|
|
|
|
|
|
|
A: KoDocumentEntry describes a KOffice component (i.e. it's a
|
|
|
|
|
representation in memory of the data contained in the .desktop
|
|
|
|
|
file). It's in kofficecore/koQueryTrader.h.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Q: Is the show() method of KoMainWindow where the application actually
|
|
|
|
|
appears to the user?
|
|
|
|
|
|
|
|
|
|
A: Yes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Q: How does KoMainWindow->show() bring up the correct application (how
|
|
|
|
|
does it know we want to show one app or another)?
|
|
|
|
|
|
|
|
|
|
A: The KoMainWindow is the same for all. But KoDocumentEntry was
|
|
|
|
|
created from specific application data, and koQueryTrader klopens the
|
|
|
|
|
library containing this component. The very same mechanism is used to
|
|
|
|
|
1) embed other components inside the app, 2) create any kind of
|
|
|
|
|
koffice document, e.g. in koshell. All the KOffice applications are in
|
|
|
|
|
fact very small wrappers that simply dlopen their own compnent - with
|
|
|
|
|
the code in kofficecore, which can also dlopen ANY component.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Q: The KoApplication object doesn't store pointers to the KoDocument
|
|
|
|
|
nd KoMainWindow objects. Do these objects communicate with each other
|
|
|
|
|
later on, and if so, is that done through DCOP?
|
|
|
|
|
|
|
|
|
|
A: The KoMainWindow knows about the KoDocument[s] inside it. The
|
|
|
|
|
KoMainWindows are in a static linked list, if one really wants to
|
|
|
|
|
iterateover all windows in the application, but this is rarely needed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Q: How does KoMainWindow relate to KoDocument and KoView?
|
|
|
|
|
|
|
|
|
|
A: KOffice applications reimplement KoDocument and KoView. But the
|
|
|
|
|
KoMainWindow is the same class for all, since it doesn't have any
|
|
|
|
|
app-specific stuff. It's GUI, i.e. menus and toolbars, are provided by
|
|
|
|
|
1) itself (the standard stuff like the File and Help menus), 2) the
|
|
|
|
|
document's actions, and 3) the view's actions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Q: How do KoDocument and KoView relate to each other?
|
|
|
|
|
|
|
|
|
|
A: KoDocument can have one or more KoViews, which allows the user to
|
|
|
|
|
have multiple views of the same document. In a single KoMainWindow
|
|
|
|
|
this might be accomplished using the "split view" feature. KoView[s]
|
|
|
|
|
of the same document can be in separate KoMainWindow[s].
|
