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

List:       koffice
Subject:    some thoughts about the shell
From:       Simon Hausmann <shaus () helios ! Med ! Uni-Magdeburg ! DE>
Date:       2000-07-05 16:47:32
[Download RAW message or body]

Hi,

I browsed a bit the koffice sources and suddenly had an idea: I think it should be \
possible to get rid of all (or at least most) shell implementations (like \
kspread_shell or kword_shell) . I think the code in the shells could be completely \
centralized, making it possible (if we get rid of blahname_shell) to get rid of the \
linking dependency appname-links-against-libappnamepart.la (like kword links against \
libkwordpart ) . I was told that although we link against libappnamepart.la, the \
dlopen upon startup does dlopen a new libappnamepart.la instead of re-using the \
existing one (and in fact we always dlopen, as in KoApplication::start() we use \
KoDocumentEntry::create ) . So besides the "code cleanup" we would also get a \
"linking cleanup" :-) (Waldo once mentioned on irc that it even might become a \
problem (or reason for crashes) if have something like kword dlopen's libkwordpart \
although it already links against it on startup .

So let's see what we have in the shell code (duplicated) :

slotFilePrint()
{
  ( (BlahView *)rootView() )->printDlg();
}

I think that one can be easily implemented in a generic way by either using something \
like the extension concept (like we do for konqueror (browserExtension) ) (might be \
overkill for just one method though) or we dynamically query for a slot \
implementation through the Qt metaobject system and call that. Or, as third option, \
simply provide a virtual printDlg() method in KoView which the views can reimplement. \
I guess the latter is the easiest approach :-)

Some apps also reimplement setRootDocument and do something like
( (BlahView *)rootView() )->initGui()
in it. I think that can be also solved by simply making the view listen for the \
KParts::GUIActivateEvent event and call initGui() then.

Ah, next is the KoMainWindow( BlahFactory::global() ) constructor call in the shells. \
I think that's also easy to solve: As we always have a KoDocument implementation when \
we create a new Shell we also know the correct instance (we know it through the \
KoDocument object) . (in fact we would have to move all instance specific code which \
is currently in the KoMainWindow constructor to the setRootDocument method) .

Then we have the nativeFormatPattern and the nativeFormatName methods. I guess these \
are obsolete, too, as we can query that information through the KoDocument object \
                (->the KoDocument has an instance object
-> we can use the KService::serviceByDesktopName to get the KService object and then \
the KServiceType object to get all the information like filename patterns, name etc. \
).

Hmm, I guess the last thing is the about dialog (like in kword_shell) . But... can't \
we get the info for the about dialog from the shell's instance? (which we know as \
soon as we have the root document -> see above ) .

If I got things correctly, then there's only one thing left to "unlink" \
libkwordpart.la from kword.bin :) , the BlahFactory::aboutData() call in \
KCmdLineArgs::init( argc, argv, ... ) in main.cc . I'm not 100% sure about that one, \
but perhaps it can be solved with something like this:

int main( int argc, char **argv )
{
  KLibrary *lib = KLibLoader::self()->library( "kword" );
  KAboutData *(*newAboutData)() = (KAboutData *(*)())lib->symbol( \
"kword_newaboutdata" );  KCmdLineArgs::init( argc, argv, newAboutData() );
  ...
  ...
}


What do you all think? Does that make sense? Did I miss something?


Bye,
 Simon


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