[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-24 9:16:06
[Download RAW message or body]

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

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

>I remember David saying that he has problems to determine the
>correct delimiter for his CSV files and therefore added a dialog
>which pops up after selecting a CSV file.
>
>IMHO this "floating" top-level dialogs are very ugly and quite
>irritating for the *user* . Due to that I suggested to "rape"
>the preview mode of our new file dlg for that purpose. Imagine
>a pseudo-preview-widget which is a normal QWidget containing a
>simple dialog (LineEdits, ComboBoxes, CheckBoxes,...). If the
>user selects '*.csv' the dialog is shown and he is able to
>specify the delimiter char (e.g. "," , ";" , ...) and the comma
>char (e.g. "," , "." , ...).
>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 ?

>1a) -> It's impossible to use the static convenience methods.
Sure, but for those special purposes it's ok, I'd say.

>2)  How do they "communicate"?
>3)  Where are the implementations of these dialogs?
>
>I searched for solutions for that problems, but they all sound
>a little bit awkward:
>
>To 1) This can be done in KoMainWindow (see 3 for details). Next
>      question: Is there any case where these methods aren't
>      called for our KOffice parts? What about the new parts?
>To 2) IMO the dialog should create a simple XML file which
>      represents its state. This file should be passed to the
>      filter as a kind of "commandline arg" (an additional QString
>      as argument). As the filter only has to understand its
>      dialog this should be no problem.
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).

>To 3) I suggest adding a new class named KoFilterConf (or something
>      more beautiful :) and a new service (e.g. KOfficeFilterConf).
>      The resulting shared lib stuff can be loaded on demand. The
>      KoMainWindow queries for KOfficeFilterConf and looks whether
>      it should add the dialog to the KFDlg or not (via the
>      extension or the mimetype). This class may look like that:
>
>      class KoFilterConf : public QWidget {
Why a widget ?

>          Q_OBJECT
> 
>          KoFilterConf();   // create the dialog
>          ~KoFilterConf();  // guess :)
>
>           const QWidget * const confDlg() const;  // get the dlg.
>           // I'm not quite sure about all the consts, though :)
Yeah, remove the second one :-)
          
>           // plus mimetype and/or extension via QStrings
>      };
>      
>      The confDlg method returns either '0L' (i.e. no configuration
>      dialog) or a pointer to the dialog.

Having to create an instance of this for all filters (most of which don't need
such a dialog, right ?) seems overkill.
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.

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 !

David Faure <faure@kde.org>

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