[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 4:30:19
[Download RAW message or body]

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...

> No need to create a super class, because current progress dialogs have a very
> different functionality ( just compare LIst, Little and Simple progress dialogs
> and you'll see ) and merging of common features would result in something only
> a bit smarter then a simple QDialog.

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 ...

Regards,
Dawit A.

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