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

List:       kde-core-devel
Subject:    Re: Progress dialogs
From:       Dawit Alemayehu <adawit () earthlink ! net>
Date:       1999-11-26 22:45:59
[Download RAW message or body]

On Fri, 26 Nov 1999, Matt Koss wrote:
> On Pi, 26 nov 1999, Dawit Alemayehu wrote:
> >On Thu, 25 Nov 1999, Matt Koss wrote:
> >> On Št, 25 nov 1999, Dawit Alemayehu wrote:
> >> >Here is what I am proposing.  Create a base abstarct progress feedback UI class,
> >> >let say it is called KIOBaseProgressUI from which all kio user feedback boxes
> >> >would need to inherit from.  Then all the reference KIOJob would have to a
> >> >progress indicator UI class would be a KIOBaseProgressUI* baseUI.  All the
> >> >changes and updating of the UI part is then performed by these GUI classes
> >> >themselves through the signal/slot mechnism.  I think this abstraction is simple
> >> >to do since KIOJob emits signals about everything ( okay almost everything) it
> >> >does.  Also it is much needed because anyone can then extend and/or create
> >> >their own progress feedback dialogs without impacting KIOJob.  What do you all
> >> >think ?  Is this something worth doing ?
> >> 
> >> This is not needed at all.
> >> Much easier way of doing this is to :
> >> 1. call setGUIMode( KIOJob::None ).
> >> 2. create your own dialog class, and simply connect KIOJob's signals to
> >>     dialog's slots.
> >> 
> >> Actually, this is what the current progress dialogs are doing ( simply connect
> >> to KIOJob's slots.
> >Yes and No.  KIOJob has intimate knowledge of each kind of progress dialog box.
> >What I am saying is that this is not really necessary.  The basic idea of
> >signals/slot is to get rid of this type of coupling.  That was where I was
> >going with the abstract class.  But it is really hard to convey an idea without
> >a sample implementation ; so I will do that and post back on this topic...
> 
> Oh, I forgot to fix some things in KIOJob.
> Little progress has nothing to do in KIOJob class.
> It's fixed now, go and take a look.
> 
> All that is in KIOJob now is simple and list progress dialogs.
> This means that there are three modes : None, Simple and List.
> KIOJob knows about Simple and List progress dialogs.
> 
> So far any stype of progress dialog can be created and used, by calling
> setGUIMode( KIOJob::None ) and connecting appropriate job signals to job slots.
> 
> There are two things why KIOJob need to know about Simple dialog:
> 
> 1. it's possible to open a Simple dialog in the middle of IO operation (
>     programatically ). Then KIOJob has to refill the fields with correct values,
>     otherwise they would stay empty ( and only progress and speed would get
>     updated ).
> 2. it's possible to open / hide / (de)iconify this dialog on the fly, through
>     KIOJob methods.
>
> If you want, we could do something like this :
> Create a base class, KIOBaseProgressUI, which would have a default methods for
> opening / closing / iconifying.
> We would need to implement some getter methods in KIOJob, so that after
> opening KIOBaseProgressUI could get back values from KIOJob. This way the
> KIOJob would not need to set them explicitly.

How about making the job itself register with the KIOBaseProgressUI class.
This way it can have access to any public member variables/functions.  Here is
an example. Ex the constructor can take "KIOBaseProgressUI( KIOJob* job )" and
a member function "setJob ( KIOJob* job )".  I did this before and were almost
done with the API of the abstract class before I made a mistake and did a "make
cvs-clean" on kdelibs :(

> Then we could set progress explicitly through 
>     KIOJob::setProgress( KIOBaseProgressUI * ).
> 
> KIOJob would of course know about Simple progress, because it will be a
> default.
> Calling setGUIMode( SIMPLE ) would explicitly call :
>         setProgress( new KIOSimpleProgressDlg() );
> This will give developers possibility to create their own fancy progress
> dialogs, without problem.
> 
> About the List progress :
> List progress is something different. KIOJob has a static instance of it and
> this dialog know about all KIOJobs and displays them. That's why the KIOJob
> knows about it, because KIOJob contains an instance of it. I guess that we
> could leave this in without change.

Exactly!!!! Now we are on the same page.  We should always avoid coupling as it
leads to a much better design down the road.  And my intent have always been to
allow people to design their own progress dialogs if they are not happy with
the three standard ones they get.

> >No no.  I am not creating a super class for that purpose but rather an
abstract > >class that has nothing to do with Widgets and features at all. 
This abstract > >class is a simple means of connecting KIOJob with any type of
progress box > >without the coupling effect that is there now.  I think this
will all become clearer  > >once I have a sample implementation soon ...
> 
> No need, now I know what you mean.
> I can rewrite it, no problem.

Great. Looking forward to it. 

> Actually, with a current implementation it's a one-liner.
> Before, KIOJob explicitly called progress dialog methods for every change.
> I have rewritten everything to use signals / slots.

Excellent.

> I guess that we could do it even if we are frozen, because almost nothing will
> change in KIOJob and for the apps. Merely a new class will be added.

Better ask Waldo before commiting.  He is the release dude and might come after
you :).  No seriously since as you said this change does not impact how other
developers use the class and does not break the API, I think he will allow it.
Either way I am very much interested in these changes.  If you cannot commit
until after KRASH, I would appreciate a patch if you have time.

Cheers,
Dawit A.

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