Re: [Kidbasic-devel] ideas

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

Tony,

It looks like your e-mails to the mailing list are finally going through. :-)

-Ian

On 11/11/06, Ian Larsen <dr...@gm...> wrote:
> >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
> >
> >
>