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

List:       koffice-devel
Subject:    Re: design discussion: progress classes in KOffice
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2010-08-10 14:41:17
Message-ID: 201008101641.17543.boud () valdyas ! org
[Download RAW message or body]

On Tuesday 10 August 2010, Jos van den Oever wrote:
> Hi all,
> 
> I've been using the progress classes quite a bit the last week and come to the 
> conclusion that I do not like them. Mainly I think the api of the classes 
> KoUpdater, KoUpdaterPrivate, KoProgressUpdater is confusing and overly heavy.
> 
> So I've come up with a new design in the form of a header file and I would like 
> people to have a look at it and see if they like it.
> 
> Progress reporting should be able to deal with
> - named tasks
> - splitting tasks up in subtasks
> - weighted tasks, the weight is an estimate of how much time a task takes 
> relative to other tasks on the same level
> - tasks running in threads; for each task progress reporting is allowed to be 
> done in one arbitrary thread
> - support having a main progress bar and progress bar for subtasks
> - support logging of progress with timestamps by simply implementing another 
> proxy
> 
> Advantages over current approach
> - less public classes, less functions, less confusion
> - more robust API due to automatic unwinding of the stack
> - only one range: 0-100
> - no mixing in of unassociated function (interrupt, abort)
> - no use of QObject for more lightweight reporting
> - more foolproof
> 
> This design is simply a suggestion which could be implemented if people like 
> it better than the current API.

I'm not really attached to the old API -- I only maintained it when I fixed the \
implementation because porting all of Krita over to a new progress api is way more \
work than I ever want to do without a solid advantage.

However, the most important thing the old code implements, and which is the reason \
for using QObjects, is that progress is often reported from multiple threads at the \
same time. The current code uses queued signal slot connections for that (the \
original code had some weird background thread that collected things -- it didn't \
work), and I don't see how you can have your updaters running in a thread and the \
reporter collecting the data in another thread with this implementation.

My opinion is: don't touch it. It works fine, also when recursion is needed, even \
when various parts of the recursed activity run in different threads. 

If you have a problem getting recursion to work, ping me and I'll see whether it's a \
bug, or whether we can make the api incrementally more robust.

-- 
Boudewijn Rempt | http://www.valdyas.org
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


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