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

List:       kde-core-devel
Subject:    Re: Progress dialogs
From:       Matt Koss <koss () miesto ! sk>
Date:       1999-11-27 10:27:56
[Download RAW message or body]

On Pi, 26 nov 1999, Dawit Alemayehu wrote:
>> 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 :(

Even if we pass KIOJob as an argument, this would not allow KIOBaseProgressUI
class to access KIOJob's private variables.
And KIOJob stores everything in these variables ( totalsize, processedsize,
etc. ).
That's why we have to create some getter methods in KIOJob.

Before, when the progress dialog was opened in the middle of IO operation,
KIOJob explicitly called dialog's slots to set some values.
Now it will be not possible, instead a dialog will get these values from
KIOJob and set them back.
These values would be normally set through signals, but at the beginning of IO,
while in the middle of it, KIOJob would not emit them again.

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

I agree.

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

Ok. Let me first create something, I will then check that everything compiles
and only after then I will propose a commit.

	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]