Re: [Kidbasic-devel] ideas

[Ian L. <dr...@gm...>]

>Why don't I just have a play with it and if it's not worth using then
no harm done?

Sounds good, it's always worth having extra flexibility as long as the
functionality is the same.

On 11/11/06, tony007 <sup...@go...> wrote:
> Hello Ian,
>
> I sent this email to the mailing list yesterday and it still hasn't shown up
> ( maybe I'm being impatient? ) so I thought I'd forward it to you...
>
> ---------- Forwarded message ----------
>  From: tony d <sup...@go...>
> Date: 10-Nov-2006 14:55
> Subject: Re: ideas
> To: kid...@li...
>
> 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
>
>