1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
|
-------------------------------------------------------------------------
| 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 TDEAboutData
data stored?
A: In a static member of the TDECmdLineArgs class.
Q: One of the arguments to TDEAboutData's constructor is the program
name. Will this be used later to run the program?
A: No (by the time the TDEAboutData'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: TDECmdLineOptions 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].
|
