Some porting from KIO::Jobs to KJobs

Ricard Marxer Piñón rmarxer at iua.upf.edu
Wed Jan 17 14:04:16 GMT 2007


Rafael Fernández López wrote:
> 2007/1/17, Ricard Marxer Piñón <rmarxer at iua.upf.edu>:
>> David Faure wrote:
>> > On Wednesday 17 January 2007 10:39, Kevin Ottens wrote:
>> >
>> >>> There's a meaning attached to it too.
>> >>> totalSize could be about any kind of data. totalFiles is more 
>> specifically
>> >>> about files. Maybe we need an API for telling uiserver what kind 
>> of objects
>> >>> it's about, so that loaidng 2000 contacts shows "1 / 2000 
>> contacts" instead
>> >>> of "1 / 2000 files".
>> >>>
>> >> That was exactly my point. totalSize() is enough, you just need a 
>> way to
>> >> specify the unit.
>> >>
>> >
>> > This works for the case of loading contacts, but not when it's 
>> indeed about files.
>> > totalSize(2000) means 2000 bytes, not 2000 files, and you need 
>> totalFiles/totalDirs in addition.
>> >
>> > So generalizing this leads to totalSize / totalItems / 
>> totalOtherItems ? ;)
>> >
>> This should not replace the slotPercent methods, right?
>
> Well it depends. Maybe yes and the percent could be computed on the
> kuiserver, or maybe we could let the progress slot, and let the job
> decide what it want to do. For example: If an app created a job that
> inherited KJob is copying 1000 contacts and then it has to do
> something with them (some heavy calculations), the progress could be
> the overall progress (copying + computing), and the message could
> change in running time with the infomessage slot, instead of getting
> at 100% when finished copying, and then delete the job, so we can make
> it more versatile.
So if I understand correctly there will be a progress slot (which will 
indicate the percentage) and an info slot (which will contain messages 
such as "Copying 12 / 1000 contacs..." or "Doing heavy calculations...").
>
>> Generalizing even more it could lead to progressDescription(QString) and
>> it's to the application to build the strings which I don't think is that
>> hard.
>
> Applications don't have to know what the kuiserver does on the
> implementation. So I don't think is a good idea an app sending
> something like progressDescription("%1 of %1 contacts added");, since
> the app shouldn't know that on the kuiserver we are doing something
> like i18n(internationalizedText, howMany, howLeft);
What I meant with progressDescription is the same as your info slot.  So 
the kuiserver would only show the string without doing nothing with it.  
It's the application that would do something like this pseudo code:

myJob->progress(howMany/howManyTotal);
myJob->progressInfo(i18n("%1 of %2 contacts added", howManyDone, 
howManyTotal));

Would this make sense?
>
>> Some jobs might not even be made of subitems or they can be of different
>> nature.
>>
>> I agree these methods could be in KJob as helper functions, but should
>> the Observer know about them?  or should the Observer receive them as a
>> simple progress description string.
>
> As we talked before, probably the Observer will be removed. The
> jobuidelegate or kjobuidelegate at kdeui can ask kuiserver.
ok. sounds good!!
but then the kuiserver would have nothing of UI (user interface), no? Is 
kuiserver still a good name? maybe better kjobserver.
>
> Bye,
> Rafael Fernández López.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.





More information about the kde-core-devel mailing list