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

List:       kde-core-devel
Subject:    RFC: Progress dialogs ( quite long )
From:       Matt Koss <koss () miesto ! sk>
Date:       2000-03-18 14:22:31
[Download RAW message or body]


Ok, here's what I propose for the new kio dialogs ( a little summary of the
former discussions ) :

A.  progress handling
-----------------
There will be two ways how the application can display progress :

1. regular apps will use NetAccess for all kio operations and will not  care
   about progress handling :
   - NetAccess creates Job
   - NetAccess creates JobObserver that will connect to the Job's signals and
      pass them via dcop to the running GUI Progress Server

2.  apps that want to do some handling with progress dialogs like Caitoo or
     KMail  :
  - app creates Job
  - app creates a progress dialog : this should be a ProgressBase descendant
      e.g. StatusProgress or custom progress dialog
  - app calls progress->setJob( job ) in order to connect job's signals with
      progress dialog slots

B.  customized progress dialogs
-----------------------
This will be similar to what we had before.

- ProgressBase class that all other dialogs will inherit.
   will contain an initialization method setJob( KIO::Job*) for apps of the
   second class (see A.2 above), that will connect job's signals to dialog's
   slots

- DefaultProgress ( former KIOSimpleProgressDialog ) that will be used for    
   regular progress dialogs created by GUI Progress Server

- StatusProgress ( former KIOLittleProgressDialog ) that can be used for      
    embedding in status bar

C. GUI Progress Server
-----------------
This is a special progress server.
- createProgress() will either create a DefaultProgress dialog or add new entry
    in a ListProgress ( an all-jobs-in-one progress dialog )
- after receiving signals from the JobObserver via DCOP it will call
    appropriate method of progress dialog ( either in DefaultProgress or ListProgress )
- ListProgres can be a Caitoo style dialog, kicker applet or both in one.

D. Some notes
-----------
1.  most of the apps will not care at all about the progress display
2.  user will be able to choose whether he wants to see separate progress
    dialogs or all-in-one ListProgress dialog
3.  developers can create their custom progress dialogs that inherit
    ProgressBase and do any manipulation with a dialog if they use a second
    approach ( see A.2 above )


I hope that I didn't forget about anything.

			Regards

							Matt

-- 
Matej Koss	e-mail: koss@miesto.sk
Kosice		 ICQ# : 19344305
Slovakia

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