Re: [Kidbasic-devel] ideas

[tony d <sup...@go...>]

Hi Ian,

>> Some events are occurring via signal/slot connections such as
>> Interpreter::inputNeeded() -> BasicOutput::getInput() which makes it
>> difficult to know ( and indeed guarantee ) the order in which things
>> happen.
> I'm not sure this is a problem. The inputNeeded signal is emitted
> after the Interpreter thread grabs a mutex and waits on a wait
> condition, so there's no risk of running things out of order, if I'm
> not mistaken.

> However, what you're describing is similar to the way the graphics and
> text outputs are updated, with the xxxxFilter slots, so it's
> reasonable to do it that way.

I'm not sure if the mutex guarantees the order - I just know from experience
that there is no guarantee the order in which signal/slot connections will
occur, but if your happy then I'm happy :-)
I think routing all the signals via the RunController will mean these
'similiar' events are handled in the same way.
.
>> I'd suggest we use toolbuttons
> That's a great idea.

I've got a few friends who are pretty handy with photoshop so I can see if
one of them would like to make some nice icons for the buttons...


> I checked out QEvent as opposed to using signals for communication
> between the interpreter thread and the main thread, and I'm not so
> sure it's worth the effort to change it, and I'm also not sure it's
> going to be significantly faster, if at all. I think the bottleneck
> with the graphical functions is always going to be the
> drawing/updating portion anyway.

Agreed.

> Not only that, but it's important for this project to maintain the
> appearance of running in a single thread, even though we're not. If a
> kid writes a pong program, he's going to get confused if the graphical
> output lags behind the program execution even a little bit.

Agreed even more.

> So the only real question is where the drawing code should be -- in
> the interpreter or outside of it. I don't think it matters a whole
> lot, unless of course you want to be able to switch out the graphics
> output window easily (i.e. use opengl when it's installed.) And for
> our purposes, I'm not sure that flexibility is worth the effort, so
> I'm going to concentrate on other things.

My main reason for suggesting this comes from an information/implementation
hiding perspective with a bit of OOD thrown in - ( the Interpreter is
responsible for interpreting the BASIC calls and turning them into data that
the rest of the application can understand - the graphics view is
responsible for displaying graphics and the text view(s) are responsible for
recieving/displaying text ). The ability to swap in and out is really just a
side issue that would become easier. You should take a look at the
QGraphicsScene which is designed for drawing 2D graphics and has calls to
create elipses, lines etc.
Why don't I just have a play with it and if it's not worth using then no
harm done?

I'm happy to do this stuff in another branch and merge in if/when your happy
with it. I know I haven't really contributed much so far since volunteering
but it's the weekend tommorrow and I've got a few days off late next week so
I should be able to throw a decent amount of time at it. I'm really excited
to be involved in this project and am keen to make as big a contribution to
its success as I can ( without my wife killing me, and my son forgetting who
I am :-) )...

I've got a gmail account thanks, which I'm sending this from so hopefully it
will work.

Cheers,
tony