Arnold Krille wrote:
So I think we should distinguish between locked gui and a non-locked gui representing the real state as soon as the state is reached. Which might be a time after the user clicked the button.
We once encountered such things in the aRts-GUI: One of our tries we did set the volume from the mouseclick in the volumebar but did the repainting of the volumebar after the rest of aRts informed us about the volumechange. Which led to some slow responses of the fader...
Maybe with such big changes as deleting channels/track/whatsoever you should recreate/update the gui after the changes are made in the engine (so after they have an hearable effect). But to not confuse the user because nothing changes, perhaps you could gray-out the relevant parts in the time between starting the action and changing the gui.
Which would mean that you have a non-locked gui representing the real state of the engine...
Did I make may thoughts clear? Its before my first coffee/tea...
That is very clear to me, indeed. What's your coffee brand ? ;-)
Your thoughts are interesting because I was hesitating about this. I began to code some "blind non-locking gui", that is : it does not wait for the RT thread to sync, but it doesn't ensure if the changes really took place or not.
My method is not supposed to confuse the user. But there is, and there will bugs in the underlying data processing, and for sure my blindish method will make debugging harder, since the gui will look just fine, while the sound is getting broken. My previous locking method really helped me in debugging, since the gui always showed what's under and what's not.
You meet Paul Davis about his RT-thread-to-gui notification method, using a fifo or similar. I thought this was a bit of a complicate thing, and graying some tracks out while they get processed will increase the work needed. But, I believe you're right, about "representing the real state of the engine".
If I understand you correctly, some part of the GUI could act "blindly", but big changes should require an acknoledgement from the RT thread. Actually this is exactly what Jackbeat 0.4.0 does, except that it does lock on big changes.
I'm wondering if I shouldn't stay with my current locking implementation until I get myself clearer about all of that. Is there any good C sources (I'm not really into C++) you'd advise me to look at ?
-- og
