Re: [Kidbasic-devel] ideas

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

Tony,

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.

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.

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.

-Ian


On 11/9/06, Ian Larsen <dr...@gm...> wrote:
> Hello Tony,
>
> >What I was also thinking was to subclass QMainWindow and move most of
> >the initialisation code from main() into there.
>
> This would make the code a lot cleaner.
>
> > 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'd suggest we use toolbuttons
>
> That's a great idea.
>
> >Some options here might be
> > QGraphicsScene or QGLWidget.
>
> I considered using OpenGL from the beginning but decided against it,
> first because I didn't want to have opengl as a dependency (I'm not
> sure all Linux distro's bundle the mesa libraries) and because doing
> 2D graphics with OpenGL can have mixed results.  I've never heard of
> QGraphicsScene, I'll have to check that out.
>
> If openGL ends up being a really good idea though, I have another
> similar project that I could just copy the code from.  I might do that
> in a separate branch to see how it works.
>
> I'm intrigued by the QCustomEvents.  I checked it out, and apparently
> in QT4 you can just subclass QEvent.  That might be a good idea for
> the graphics functions, and it might speed things up significantly.
>
> You're definitely right about the graphics functions though.  Most of
> the requests I've gotten have been for more of those.
>
> -Ian
>
>
> On 11/9/06, Tony Dann <to...@mu...> wrote:
> > Ian,
> >
> > I've tried to send this to kidbasic-devel ( and have Cc'd that address
> > on this email ) but it keeps bouncing back at me so I'm sending to you
> > directly. So, had it worked my email would be as follows...
> >
> >
> > I've not had any luck with fixing the focus bug yet ( but don't worry,
> > I'm not giving up ) but have some ideas on how we can deal with some of
> > the feature requests and hopefully make it easier to track what's going
> > on at runtime ( including focus issues :-) ).
> >
> > Currently the RunController has pointers to the 3 windows ( edit,
> > goutput and output ) and is already doing some of what I'm about to
> > suggest...
> >
> > 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.  Rather than connecting signals from the Interpreter directly to
> > the view widgets, I'd thought we could route these calls via the
> > RunController which can then ( knowing it's current state and who should
> > be doing what ) take appropriate action if needed ( like decide who
> > should have the focus ) or simply pass the message on.
> >
> > What I was also thinking was to subclass QMainWindow and move most of
> > the initialisation code from main() into there. The new MainWindow can
> > store pointers to all the sub-windows and persistent dialogs (
> > Preferences etc..? ) giving us a persistent object which knows about all
> > the views and can take care of application wide stuff.
> >
> > Some ideas to address some of the feature requests as well, such as...
> >
> > 1. From the user forum: "The problem with this is that a number of
> > people have requested a context sensitive menu for the output windows
> > with options for taking screen shots and clearing the screen, and a
> > MOUSE command would conflict with that." ->
> >
> > You could also include printing and copying-to-clipboard in the list of
> > things you might want to do with one or more of the views. I'd suggest
> > we use toolbuttons for these actions rather than context menus and have
> > the events sent back to the MainWindow class for processing, passing a
> > view id or something so that the main window knows which view it's
> > dealing with. Some of the commands may be applicable at an application
> > level as well, in which case the main window would have corresponding
> > toolbuttons and menu items as well as the typical "New", "Open" etc..
> > This would leave the way open for view mouse events to be solely code (
> > BASIC ) oriented ( if that makes sense ). Also, I think children are
> > going to find it easier to use software which has buttons available for
> > common actions as well as menu items.
> >
> > Another advantage of this approach is the centralisation of generic code
> > to do things like printing and view-clearing and allow individual views
> > to only need to worry about their specifics for the requested task.
> >
> > 2. There are requests for more sophisticated graphics functionality and
> > IMHO these will only grow in number as the tool grows in popularity (
> > everyone loves graphics  :-)   ). Some options here might be
> > QGraphicsScene or QGLWidget. By using polymorphism we could easily swap
> > these in and out as they are developed and even do it at run-time if we
> > liked  ;-) . This leads to taking the drawing control away from the
> > Interpreter instance and handing it over the view - there aren't that
> > many graphics functions so each of them could easily be provided via the
> > graphic view interface class and implemented by the derived class(es).
> > Another option to using signals/slots from the interpreter thread is to
> > use QCustomEvents which can contain the data about what needs to be
> > drawn and will still be handled by the main event loop so the system
> > doesn't get choked with lots of draw type calls. Signal/slot connections
> > across threads use this type of method anyway and we'd just be throwing
> > away some of the overhead that signals/slots carry with them.
> >
> > Anyway, what do you think? If you agree with some/all of this stuff then
> > great, obviously until the architecture has been sorted it would need to
> > be done in a separate branch in order to maintain a working copy in the
> > trunk...
> >
> > tony
> >
> >
> >
>