[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-28 22:05:14
[Download RAW message or body]

David Faure wrote:
> 
> At 16:46 24/12/99 +0100, you wrote:
> >Hi!
> Hi !
> Sorry for not replying earlier, I'm away...
> 

Yeah...I thought you might be away and - that you are unsubscribed.
Due to that I've sent this via private mail, too ;(

> >Now that I'm back home I have some time for programming again and
> >I wanted to do something for David because he's sooo kind to help
> >me all the time :)
> :-)
> 
[snip]
> >This kind of dialog should be used for all non-trivial filters
> >instead of a popup dlg.
> This sounds nice, although I have some trouble picturing
> how it would look like exactly (given that I haven't seen the new
> preview widget).
> 
> >Due to Reggies design (inherit the preview stuff from QWidget) the
> >dialog itself is no problem. BUTH(tm) several problems remain:
> >1)  Who "adds" the dialogs (aka "raped previews") to the KFileDlg
> >    before it is shown?
> Hmmm, the application, no ?

Duplicated code...? AFAIK all the parts use the koMainWindow stuff
for loading/saving. See below for further information.

[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 :)

[snip]

> >      class KoFilterConf : public QWidget {
> Why a widget ?

A QWidget is needed because the preview widget in the QFD (and also
in the new KFD) are inherited from a QWidget. Therefore you can "embed"
(don't hit me for using this word :) ) dialogs/previews/stuff as
long as it is derived from QWidget. You may want to have a look at
the (very straightforward) "QDir" Qt-example (launch it with
'qdir -preview'!)

[snip]
 
> Having to create an instance of this for all filters (most of which don't need
> such a dialog, right ?) seems overkill.

No - only for the ones which really need that stuff! The '0L' was ... hmmm
a simple mistake. If there is no dlg then there is no Object :)

> 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. What do you think about that:

----------------------------------------------------------------------------
dialog stuff - v0.0.1 :)

1) The Dialog:
   ...has to inherit QWidget.
   ...must not have a menubar, toolbar, 'Ok' or 'Cancel' button,...
   ...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?)
   ..."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)
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?
3) The KoMainWindow:
   ...asks for the mimetype of the part
   ...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
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 

----------------------------------------------------------------------------

> Very nice idea on the whole, BTW !
> I like it when KDE isn't only copying ideas around, but actually inventing
> new and better ways !

:)

Werner

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