------------------------------------------------------------------------- | This document answers some questions about how the startup of KOffice | applications works. This file was put together by | Eric R. Turner | from the answers given by David Faure ------------------------------------------------------------------------- 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//...) 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].