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

List:       koffice
Subject:    Re: A kind of preview... (brainstroming)
From:       Werner Trobin <wtrobin () carinthia ! com>
Date:       1999-12-30 15:10:43
[Download RAW message or body]

David Faure wrote:
> 
> [snip]
> 
> >> Hmm... can't the filter simply access methods in the dialog class,
> >> to get the settings ? This would require, though, to do it before
> >> destroying the file dialog (which I suppose, destroys the preview dialog).
> >
> >Therefore I wanted to separate this. -> See below :)
> 
> There is something I missed here.
> I thought the filters instances _were_ created even before the
> dialog showed up (sounds wrong, but got that from some debug output).
> That's why I thought about simply adding a method to KOFilter.
> But ok : it the filters are created before hand for no reason, we
> should fix that instead of using it. I can't check the code, please confirm
> that the filters are not created before the file dialog - or if they are, why.

First the part/shell(?) queries KoFilterManager which filters are available.
The KoFilterManager queries the trader. All the matching filters (i.e.
correct mimetypes) are returned. The KoFilterManager creates a QString which
lists all the filters (e.g. *.csv CSV filter). This QString is used to tell
the KFD which extensions it should add to the Filter ComboBox. The user
selects the extension in the KFD and a file. The filename is returned. The
KoFilterManager queries the mimetype of the file and loads the appropriate
filter lib. The filenames are passed on to the lib and the filtering process
starts...

> 
> >> Why not simply add this method to KoFilter ?
> >> Default implementation could even return 0L, so that only those filters
> >> who need it would overload it.
> >
> >That's what I've thought first, but then you'll have to load the whole filter
> >just to show the dialog.
> ... which I thought was already the case.

No.
 
> Anyway creating filters before hand is (would be) wrong, so I let's see about
> your proposal.
> 
> >----------------------------------------------------------------------------
> >dialog stuff - v0.0.1 :)
> >
> >1) The Dialog:
> >   ...has to inherit QWidget.
> >   ...must not have a menubar, toolbar, 'Ok' or 'Cancel' button,...
> okay up to here
> >   ...is able to save its state (e.g. a XML document). This may look like
> >      that:
> >         <?xml....?><!DOCTYPE dialog><dialog state="1">
> >         <delimiter char=";" />
> >         <comma char="," />
> >         </dialog>
> >
> >      (state => are the contents valid?)
> And I suppose it would save its state when the dialog is destroyed.

Yes.

> But as I suggested earlier on, instead of saving into a temp XML file,
> why not simply :
>    - create a file dialog, keeping a reference to it
>    - show it
>    - when closed, access its filter-conf dialog, and get the params
>    - destroy it
> Since there is only ONE relevant dialog (the one that matches
> the chosen extension), this would work (we don't need to save values
> from all possible dialogs, each one matching a different extension).

This should work, too. But you have to keep the KFD 'alive' quite long.

> >   ..."knows" its part's native mimetype/extension (e.g. the CSV filter
> >      belongs to KSpread)
> >   ...offers its service to the trader (Either we add some lines to
> >      the KOfficeFilter ServiceType (IMHO better) or we create a new one
> >      for the dialogs)
> Not sure what you mean. The dialog is associated with the filter, even in
> the same lib.

No. The filter is a lib and the dialog is a lib.

> All that's required is an entry point (a c method) for it
> (just like in kcontrol you can have two entry points in the same lib).

This would work, too, but it's not necessary to load the whole filter
lib just to show the dlg.

> This means adding one or two lines to the filter .desktop file, which
> is probably what you meant by "the servicetype" - but it's a service,
> not a servicetype :)

Hmmm... I don't quite understand all the trader & Co. stuff :)

> >2) The Part:
> >   ...simply calls the KoMainWindow methods (Is there any case where
> >      this isn't possible?). What about the menu merging of the new
> >      parts? Will this stuff work?
> Hmm, the title is wrong. Parts don't do "load" currently, do they ?
> Only main windows do. There is no additionnal method call to make -
> I'd remove this section.
> 
> >3) The KoMainWindow:
> >   ...asks for the mimetype of the part
> (already does)
> (in fact it's not KoMainWindow but KoFilterManager)

Yeah, but the KoFilterManager is not able to add the dialogs to the
KFD because it belongs to the KoMainWindow object.

> >   ...queries the trader for appropriate dialogs (first it queries all
> >      the available filters as it does now, and then is searches if there
> >      are any dialogs available)
> >   ...adds the dialogs to the KFD
> >   ...stores the returned filename (as it does now) AND the dialog's
> >      XML file (e.g. as QString)
> >   ...calls the filter and passes the dialog's config
> I'd say : passes the XML filename or (in my idea) the pointer to the dialog.
> In any case it's the filter that iterates through the params

Anyway, I like the XML-via-QString because it's easy and clean.

> >4) The KFD:
> >   ...shows the correct dialog (e.g. I select '*.csv' and the correct
> >      dialog is shown)
> >5) The Filter:
> >   ...receives the dlg config string in its CTOR
> >   ...has to "understand" it - should be no problem as
> >      filter : dialog ==  1 : 1
> Sure.
> 
> So. What about all this but with a pointer to the dialog instead of a
> temp XML file, for the params ?

Would work, too, of course :)

Werner

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