[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Getting Started (long post)
From:       "Eric R. Turner" <eric.r.turner () bitbreather ! com>
Date:       2002-07-26 4:55:53
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 24 July 2002 11:37 pm, Carsten Pfeiffer wrote:

> You can either pass the application name to KApplication or to the
> KAboutData object. In KWord's case, see kwaboutdata.h (KAboutData should be
> used in almost any other application as well.)

Let me see if I get this straight. Working with the example KOffice program:

The first thing in main() is a call to the static method KCmdLineArgs::init( 
argc, argv, newExampleAboutData()) 

The newExampleAboutData() function creates an instance of KAboutData, which is 
stored (via a pointer) in the KCmdLineArgs class (not in an object of the 
class because we haven't instantiated one, right?).

One of the arguments to KAboutData's constructor is the program name 
"example". Will this be used later to actually run the example program?

KCmdLineArgs::init() strips the path off of argv[0] (the program path and 
name?), gets the current working directory, keeps a pointer to the KAboutData 
object, and calls KApplication::addCmdLineOptions (which adds some other Qt 
and KDE options to KCmdLineArgs).

Then main() adds these options to KCmdLineArgs: "+[file]", I18N_NOOP("File to 
Open"), and 0. What is the "+[file]" all about? Why that format? What's it 
do?

Ok, so we have this static KCmdLineArgs class that knows a bunch of stuff 
about the example program because it has a KAboutData object filled with 
example-specific data.

Now we declare a KoApplication object. Several things are done in the 
constructor, including the creation of a KoApplicationInterface object which 
I assume is how other applications can use DCOP to interact with this 
application. (Anyone want to explain to me what the first four method calls 
do in the constructor?)

Back in main(), the app attaches to the DCOP server and registers itself so 
that other processes can communicate with the app.

Now the fun part begins. The app calls it's start() method. Start does a 
number of things:

     1. start() looks up the native mime type for this application, and then 
creates a KoDocumentEntry. The comment says that start() is finding the 
desktop file. What is this desktop file? Is it generated by hand or by an 
app? What's a KoDocumentEntry? I couldn't find it in lib/kofficecore.

     2. Assuming there were arguments obtained from KCmdLineArgs, start() 
creates a KoDocument and a KoMainWindow for each argument (are the arguments 
names of files to open?). When the show() method of KoMainWindow is called, 
is this when the application actually appears to the user? I'm still having 
difficulties seeing how KoMainWindow->show() brings up the correct 
application (how does it know we want to show the "example" app versus any 
other apps?). Also, the KoApplication object doesn't store pointers to the 
KoDocument and KoMainWindow objects... do these objects communicate with each 
other later on, and if so, is that done through DCOP? 

Ok, I'll stop. Sorry about the long post. I just <em>really</em> want to 
understand how this whole thing works! Perhaps it would be good to write a 
tutorial document. I promise that if I actually ever understand this well 
enough, I'll write it!

Regards,
Eric

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9QNZeB//mkbVZTXARAnpjAKCeWBYn/CAdDUANqSOX6o3WoLmqmQCg50OE
9NVtl92xFkPo6YmniQdOtHc=
=Uh9s
-----END PGP SIGNATURE-----

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]