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

List:       koffice
Subject:    Re: A kind of preview... (brainstroming)
From:       David Faure <faure () kde ! org>
Date:       1999-12-25 10:17:19
[Download RAW message or body]

[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.

>> 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.

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.
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).

>   ..."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. 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 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 :)

>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)
>   ...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

>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 ?

David Faure <faure@kde.org>

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