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

List:       kde-kimageshop
Subject:    Re: CSV format import-export
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2016-03-04 20:32:34
Message-ID: alpine.LNX.2.00.1603042131090.15200 () calcifer ! valdyas ! org
[Download RAW message or body]

On Fri, 4 Mar 2016, Fazekas László wrote:

> Sorry for the late answer, I was away from the computer.
> 
> There must be something already with the progressbar, because when I call the image \
> import for the png files, the progressbar at the bottom flashes. Only it always \
> shows 0%.

Yeah. I started digging into that today... And somehow, over the past ten years, it \
got broken in weird and wonderful ways! I know what's up, though, and I'll try to fix \
it tomorrow, but I've got a funeral to serve at first... But as long as you can emit \
a signal with percentage progress, I'll make sure the user is informed of it :-)

> 
> I don't know how it works now, I'm going to check the code tomorrow. We should be \
> able to handle the race condition if one function using the progressbar calls \
> another, and the called part also wants to set one for itself. 
> Let's say there is function Alice() and she sends progressbar updates while \
> working. During this, it calls function Bob() and he also reports its readiness. \
> It's wrong to send all these values directly to the widget, the progressbar would \
> flash like crazy. The good value for the widget is lerp( current(Alice), \
> next(Alice), current(Bob) ). But the progressbar doesn't know the next(Alice) value \
> - probably even Alice() can't calculate it before it really happens. And there can \
> be a third Carole() function called by Bob() too... 
> One solution could be to somehow separate the signals by their source and keep all \
> these values in a list. I think the percentage report should contain an optional \
> next value for the correct calculations. Without the provided next value, the lower \
> levels should be ignored. 
> But perhaps this is too complicated so it's easier to entirely disable the embedded \
> reporting. In this case the initial setUpdater() call for Bob() should return an \
> error code and tell Bob() that he must be silent. 
> Fazek
> 
> 2016-03-04 15:04 keltezéssel, Dmitry Kazakov írta:
> 
> As far as I know, in the import/export plugins we don't have any progress
> 
> reporting framework (Boud will correct me if I'm wrong), though it might be
> a good idea to have one.
> 
> There actually is one, you can set an updater using
> KisImportExportFilter::setUpdater and report progress with the
> sigProgress(int percent); whether that actually works is another thing.
> Adding progress reporting to our import/export plugins has been a todo
> since we moved away from the built-in ImageMagick filters, I think!
> 
> But the proper thing to do is emit that signal from the filter and then
> let me worry about how whether the progress bar is shown.
> 
> Yes, that would be an ideal solution :)
> 
> 
> 
> _______________________________________________
> Krita mailing list
> kimageshop@kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
> 
> 
> 
> 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org


[Attachment #3 (text/plain)]

_______________________________________________
Krita mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop


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