15 Mar
2005
15 Mar
'05
11:45 a.m.
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