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

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

Hi!

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.

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?
1a) -> It's impossible to use the static convenience methods.
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.  
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 {
      
          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 :)
          
           // plus mimetype and/or extension via QStrings
      };
      
      The confDlg method returns either '0L' (i.e. no configuration
      dialog) or a pointer to the dialog.

Don't flame me - I'm going slightly mad... :)

Werner

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