[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice
Subject: Re: some thoughts about the shell
From: Werner Trobin <wtrobin () mandrakesoft ! com>
Date: 2000-07-05 17:22:26
[Download RAW message or body]
Simon Hausmann wrote:
>
> 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 .
Cool :)
> 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 :-)
Agreed. The last one is the way to go IMHO. The only thing I don't
know is whether the virtual method should be in the doc or in the
view. I'd rather see that as a "document-action," but I didn't look
at the code.
> 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.
IMVHO this can be done directly in the CTOR and we can remove this
method. (at least from what I've seen in KWord).
> 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. ).
Okay... this is slower, but it shouldn't matter at all as we
need this stuff only for File -> Open and so on :)
> 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?
Sounds really cute :)
I'd like to add a paragraph:
What about removing all the main.cc files and providing only one
executable? Then we could create links to this executable
(e.g. the executable is named koffice and we link kword to koffice).
On startup we check argv[0] and use this to load the correct
library. This should also work for the foo_newaboutdata magic.
I really think that these are some good ideas above Simon - what do
you think of "the last paragraph"?
--
Werner Trobin - wtrobin@mandrakesoft.com
[prev in list] [next in list] [prev in thread] [next in thread]