Fiber based UI-Toolkit

[Christian Köstlin via Digitalmars-d-learn]

On 10.07.17 00:23, Christian Köstlin wrote:
To elaborate on the previous post, I uploaded a small example, that
tries naively to mix dlangui with fibers. Please have a look at:
https://github.com/gizmomogwai/fibered-ui.git
For sure it does not work. The fiber in the callback is started,
but after the first yield, dlangui never returns to the fiber.
Does anybody know what needs to be done for that?

thanks a lot,
Christian

> On 09.07.17 23:12, bauss wrote:
>> On Sunday, 9 July 2017 at 19:43:14 UTC, Christian Köstlin wrote:
>>> I wonder if there is any fiber based / fiber compatible UI-Toolkit out
>>> for dlang. The second question is, if it would make sense at all to
>>> have such a thing?
>>>
>>> christian
>>
>> It doesn't really make sense to have that, because most (if not all)
>> operating systems only allow rendering from a single thread and I
>> believe OSX (possibly macOS too.) only allows it from the main thread.
>> Which means the only thing you can really operate on other threads are
>> events, but you'll always have to do callbacks to your UI thread in
>> order to render.
> Thanks for answering! you are touching exactly my question:
> Lets say, that all the event handling is done by fiber-aware code (means
> all io gives the thread free, when it would block, and perhaps
> a yield function for calculation heavy operations). It would then
> I think reduce the "risk" of a ANR (Application not responding (from
> android) or the famous beachball) without sacrificing the clarity of the
> code.
> 
> e.g. you want to download something from a webpage and process the data,
> if you click a button. you cannot do this in the buttons-onclick
> callback (because this is usually a long running operation and the
> callback is called from the main thread). with fibers, the main thread
> could continue running (and update the screen) as soon as the io thread
> is blocking or the process thread calls yield (which he should on a
> regular basis). after the processing as soon as the fiber gets back the
> control, the result can easily be integrated back into the ui, because
> its already in the right thread.
> compare this with the traditionally apporach of spawning a new thread,
> passing over the arguments, processing it, passing back the result and
> integrating this into the ui, it could perhaps be "simpler".
> 
> on the other hand, the process code would get a little bit messy because
> of the manually inserted yields (as far as i know, the erlang vm for
> example inserts such instructions automatically every n instructions).
> 
> what do you think?
>