kidbasic-devel — Mailing list for developers of KidBASIC

Re: [Kidbasic-devel] Fwd: File access?

[Ferry H. <fer...@gm...>]

All done and committed to the repository (rev 134). We now have 4 file
operations:

- int open(string name, string mode)
  - mode can be one of "read" or "write", defaulting to "read".

- string read()
  - read one token from the file

- int write(string token)
  - write one token to the file

- int close()
  - close the file

Cheers

/Ferry


On 11/17/06, Ian Larsen <dr...@gm...> wrote:
> Let's start with those four, and see if we get requests for others.
>
> We can probably just use open, read, write, and close, instead of
> prepending an "f," since I don't forsee implementing READ and DATA in
> basic256.
>
> -Ian
>
>
>
> On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> > I agree, keeping it simple is best.
> >
> > We therefore have at least 4 new functions:
> >
> >   error = fopen( filename )
> >   - open the file (for read and write? or separate them out?)
> >   - return simple true or false
> >
> >   token = fread()
> >   - return the next token in the file
> >   - ignore line breaks?
> >
> >   fwrite( token )
> >   - write the token to the end of the file
> >
> >   fclose()
> >   - close the file
> >
> > Are these 4 enough or do we need any further functions?
> >
> > For example:
> >
> >   feof  ??
> >   - way to tell when we've reached the end of the file
> >
> >   fseek  ??
> >   - seek into the file
> >
> > Cheers
> >
> > /Ferry
> >
> >
> > On 11/17/06, Ian Larsen <dr...@gm...> wrote:
> >
> > > I think supporting one open file (at a time) would be plenty for our
> > > purposes, and would make implementation a bit easier.
> > >
> > > Instead of reading characters though, I think the default function of
> > > a file read command should be to emulate the input statement, and read
> > > entire tokens.  That way a kid could type in a file:
> > >
> > > 1  aString  2.23  -3  10
> > > 11  24  Ian  34
> > >
> > > and calling read would return 1, then "aString", and so forth.
> > > We could have the data type default to string for simplicity, counting
> > > on the programmer to change it to the type he wants with int(), for
> > > example, or we could attempt to decide what the type is based on the
> > > token.
> > >
> > > My inclination is to return strings only, to keep things simple and predictable.
> > >
> > > -Ian
> > >
> > >
> > >
> > > On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> > > > I definitely agree that we want to avoid the classic basic approach.
> > > >
> > > > The FOPEN (and others) approach is reasonable and we should probably
> > > > be working at the character level, as dealing with UTF-8 etc would be
> > > > a real pain...
> > > >
> > > > We could take a C-like approach and have a gets(number) function? e.g.
> > > > returns <number> characters in a string from the currently open file
> > > > (until end of line?)
> > > >
> > > > Hmm.. also, do we want to support one open file or more than one?
> > > >
> > > > Cheers
> > > >
> > > > /Ferry
> > > >
> > > >
> > > > On 11/17/06, Ian Larsen <dr...@gm...> wrote:
> > > > > Actually, I haven't given it much thought, but you're right, it would
> > > > > be good to have that.
> > > > >
> > > > > We could have an FOPEN, FREAD, and FWRITE command.  I'm just unsure of
> > > > > whether they should work at the byte or character level.
> > > > >
> > > > > What I usually do is write an example program or tutorial first, and
> > > > > then code the commands.  It helps to focus on what is actually
> > > > > necessary to teach kids.
> > > > >
> > > > > Traditionally BASIC used READ and DATA statements for data input, but
> > > > > personally I was never crazy about that approach, most importantly
> > > > > because I think data should be a separate entity from the program that
> > > > > reads/alters it.
> > > > >
> > > > > The approach that LISP takes for file input is nice.  You can use the
> > > > > lisp read command on an open file to read a token, or read-line to
> > > > > read a line.  There's also read-char and read-byte.  This might be the
> > > > > best way to handle it, so kids can have a text file of data separated
> > > > > by white space and just read each token in one at a time.
> > > > >
> > > > > -Ian
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> > > > > > Has anyone given any thought to file access? It would be useful to be
> > > > > > able to open, read and write text files...
> > > > > >
> > > > > > Cheers
> > > > > >
> > > > > > /Ferry
> > > > > >
> > > >
> >
>

Re: [Kidbasic-devel] Fwd: File access?

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

Let's start with those four, and see if we get requests for others.

We can probably just use open, read, write, and close, instead of
prepending an "f," since I don't forsee implementing READ and DATA in
basic256.

-Ian



On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> I agree, keeping it simple is best.
>
> We therefore have at least 4 new functions:
>
>   error = fopen( filename )
>   - open the file (for read and write? or separate them out?)
>   - return simple true or false
>
>   token = fread()
>   - return the next token in the file
>   - ignore line breaks?
>
>   fwrite( token )
>   - write the token to the end of the file
>
>   fclose()
>   - close the file
>
> Are these 4 enough or do we need any further functions?
>
> For example:
>
>   feof  ??
>   - way to tell when we've reached the end of the file
>
>   fseek  ??
>   - seek into the file
>
> Cheers
>
> /Ferry
>
>
> On 11/17/06, Ian Larsen <dr...@gm...> wrote:
>
> > I think supporting one open file (at a time) would be plenty for our
> > purposes, and would make implementation a bit easier.
> >
> > Instead of reading characters though, I think the default function of
> > a file read command should be to emulate the input statement, and read
> > entire tokens.  That way a kid could type in a file:
> >
> > 1  aString  2.23  -3  10
> > 11  24  Ian  34
> >
> > and calling read would return 1, then "aString", and so forth.
> > We could have the data type default to string for simplicity, counting
> > on the programmer to change it to the type he wants with int(), for
> > example, or we could attempt to decide what the type is based on the
> > token.
> >
> > My inclination is to return strings only, to keep things simple and predictable.
> >
> > -Ian
> >
> >
> >
> > On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> > > I definitely agree that we want to avoid the classic basic approach.
> > >
> > > The FOPEN (and others) approach is reasonable and we should probably
> > > be working at the character level, as dealing with UTF-8 etc would be
> > > a real pain...
> > >
> > > We could take a C-like approach and have a gets(number) function? e.g.
> > > returns <number> characters in a string from the currently open file
> > > (until end of line?)
> > >
> > > Hmm.. also, do we want to support one open file or more than one?
> > >
> > > Cheers
> > >
> > > /Ferry
> > >
> > >
> > > On 11/17/06, Ian Larsen <dr...@gm...> wrote:
> > > > Actually, I haven't given it much thought, but you're right, it would
> > > > be good to have that.
> > > >
> > > > We could have an FOPEN, FREAD, and FWRITE command.  I'm just unsure of
> > > > whether they should work at the byte or character level.
> > > >
> > > > What I usually do is write an example program or tutorial first, and
> > > > then code the commands.  It helps to focus on what is actually
> > > > necessary to teach kids.
> > > >
> > > > Traditionally BASIC used READ and DATA statements for data input, but
> > > > personally I was never crazy about that approach, most importantly
> > > > because I think data should be a separate entity from the program that
> > > > reads/alters it.
> > > >
> > > > The approach that LISP takes for file input is nice.  You can use the
> > > > lisp read command on an open file to read a token, or read-line to
> > > > read a line.  There's also read-char and read-byte.  This might be the
> > > > best way to handle it, so kids can have a text file of data separated
> > > > by white space and just read each token in one at a time.
> > > >
> > > > -Ian
> > > >
> > > >
> > > >
> > > >
> > > > On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> > > > > Has anyone given any thought to file access? It would be useful to be
> > > > > able to open, read and write text files...
> > > > >
> > > > > Cheers
> > > > >
> > > > > /Ferry
> > > > >
> > >
>

Re: [Kidbasic-devel] Fwd: File access?

[Ferry H. <fer...@gm...>]

I agree, keeping it simple is best.

We therefore have at least 4 new functions:

  error = fopen( filename )
  - open the file (for read and write? or separate them out?)
  - return simple true or false

  token = fread()
  - return the next token in the file
  - ignore line breaks?

  fwrite( token )
  - write the token to the end of the file

  fclose()
  - close the file

Are these 4 enough or do we need any further functions?

For example:

  feof  ??
  - way to tell when we've reached the end of the file

  fseek  ??
  - seek into the file

Cheers

/Ferry


On 11/17/06, Ian Larsen <dr...@gm...> wrote:

> I think supporting one open file (at a time) would be plenty for our
> purposes, and would make implementation a bit easier.
>
> Instead of reading characters though, I think the default function of
> a file read command should be to emulate the input statement, and read
> entire tokens.  That way a kid could type in a file:
>
> 1  aString  2.23  -3  10
> 11  24  Ian  34
>
> and calling read would return 1, then "aString", and so forth.
> We could have the data type default to string for simplicity, counting
> on the programmer to change it to the type he wants with int(), for
> example, or we could attempt to decide what the type is based on the
> token.
>
> My inclination is to return strings only, to keep things simple and predictable.
>
> -Ian
>
>
>
> On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> > I definitely agree that we want to avoid the classic basic approach.
> >
> > The FOPEN (and others) approach is reasonable and we should probably
> > be working at the character level, as dealing with UTF-8 etc would be
> > a real pain...
> >
> > We could take a C-like approach and have a gets(number) function? e.g.
> > returns <number> characters in a string from the currently open file
> > (until end of line?)
> >
> > Hmm.. also, do we want to support one open file or more than one?
> >
> > Cheers
> >
> > /Ferry
> >
> >
> > On 11/17/06, Ian Larsen <dr...@gm...> wrote:
> > > Actually, I haven't given it much thought, but you're right, it would
> > > be good to have that.
> > >
> > > We could have an FOPEN, FREAD, and FWRITE command.  I'm just unsure of
> > > whether they should work at the byte or character level.
> > >
> > > What I usually do is write an example program or tutorial first, and
> > > then code the commands.  It helps to focus on what is actually
> > > necessary to teach kids.
> > >
> > > Traditionally BASIC used READ and DATA statements for data input, but
> > > personally I was never crazy about that approach, most importantly
> > > because I think data should be a separate entity from the program that
> > > reads/alters it.
> > >
> > > The approach that LISP takes for file input is nice.  You can use the
> > > lisp read command on an open file to read a token, or read-line to
> > > read a line.  There's also read-char and read-byte.  This might be the
> > > best way to handle it, so kids can have a text file of data separated
> > > by white space and just read each token in one at a time.
> > >
> > > -Ian
> > >
> > >
> > >
> > >
> > > On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> > > > Has anyone given any thought to file access? It would be useful to be
> > > > able to open, read and write text files...
> > > >
> > > > Cheers
> > > >
> > > > /Ferry
> > > >
> >

[Kidbasic-devel] Fwd: File access?

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

---------- Forwarded message ----------
From: Ian Larsen <dr...@gm...>
Date: Nov 16, 2006 4:20 PM
Subject: Re: [Kidbasic-devel] File access?
To: Ferry Hendrikx <fer...@gm...>


I think supporting one open file (at a time) would be plenty for our
purposes, and would make implementation a bit easier.

Instead of reading characters though, I think the default function of
a file read command should be to emulate the input statement, and read
entire tokens.  That way a kid could type in a file:

1  aString  2.23  -3  10
11  24  Ian  34

and calling read would return 1, then "aString", and so forth.
We could have the data type default to string for simplicity, counting
on the programmer to change it to the type he wants with int(), for
example, or we could attempt to decide what the type is based on the
token.

My inclination is to return strings only, to keep things simple and predictable.

-Ian






On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> I definitely agree that we want to avoid the classic basic approach.
>
> The FOPEN (and others) approach is reasonable and we should probably
> be working at the character level, as dealing with UTF-8 etc would be
> a real pain...
>
> We could take a C-like approach and have a gets(number) function? e.g.
> returns <number> characters in a string from the currently open file
> (until end of line?)
>
> Hmm.. also, do we want to support one open file or more than one?
>
> Cheers
>
> /Ferry
>
>
> On 11/17/06, Ian Larsen <dr...@gm...> wrote:
> > Actually, I haven't given it much thought, but you're right, it would
> > be good to have that.
> >
> > We could have an FOPEN, FREAD, and FWRITE command.  I'm just unsure of
> > whether they should work at the byte or character level.
> >
> > What I usually do is write an example program or tutorial first, and
> > then code the commands.  It helps to focus on what is actually
> > necessary to teach kids.
> >
> > Traditionally BASIC used READ and DATA statements for data input, but
> > personally I was never crazy about that approach, most importantly
> > because I think data should be a separate entity from the program that
> > reads/alters it.
> >
> > The approach that LISP takes for file input is nice.  You can use the
> > lisp read command on an open file to read a token, or read-line to
> > read a line.  There's also read-char and read-byte.  This might be the
> > best way to handle it, so kids can have a text file of data separated
> > by white space and just read each token in one at a time.
> >
> > -Ian
> >
> >
> >
> >
> > On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> > > Has anyone given any thought to file access? It would be useful to be
> > > able to open, read and write text files...
> > >
> > > Cheers
> > >
> > > /Ferry
> > >
>

Re: [Kidbasic-devel] File access?

[Ferry H. <fer...@gm...>]

I definitely agree that we want to avoid the classic basic approach.

The FOPEN (and others) approach is reasonable and we should probably
be working at the character level, as dealing with UTF-8 etc would be
a real pain...

We could take a C-like approach and have a gets(number) function? e.g.
returns <number> characters in a string from the currently open file
(until end of line?)

Hmm.. also, do we want to support one open file or more than one?

Cheers

/Ferry

On 11/17/06, Ian Larsen <dr...@gm...> wrote:
> Actually, I haven't given it much thought, but you're right, it would
> be good to have that.
>
> We could have an FOPEN, FREAD, and FWRITE command.  I'm just unsure of
> whether they should work at the byte or character level.
>
> What I usually do is write an example program or tutorial first, and
> then code the commands.  It helps to focus on what is actually
> necessary to teach kids.
>
> Traditionally BASIC used READ and DATA statements for data input, but
> personally I was never crazy about that approach, most importantly
> because I think data should be a separate entity from the program that
> reads/alters it.
>
> The approach that LISP takes for file input is nice.  You can use the
> lisp read command on an open file to read a token, or read-line to
> read a line.  There's also read-char and read-byte.  This might be the
> best way to handle it, so kids can have a text file of data separated
> by white space and just read each token in one at a time.
>
> -Ian
>
>
>
>
> On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> > Has anyone given any thought to file access? It would be useful to be
> > able to open, read and write text files...
> >
> > Cheers
> >
> > /Ferry
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Kidbasic-devel mailing list
> > Kid...@li...
> > https://lists.sourceforge.net/lists/listinfo/kidbasic-devel
> >
>

Re: [Kidbasic-devel] Polygon function

[Ferry H. <fer...@gm...>]

Ah good...  I'd forgotten about that 'c' value.   :)

On 11/17/06, Ian Larsen <dr...@gm...> wrote:
> The POLY command looks great, I just merged it in, along with colour.
>
> I added a line to delete the "c" value that gets popped off the stack,
> otherwise this would leak memory, and it wouldn't be noticeable until
> the POLY command was used in a loop.  I've gotten bitten by this bug a
> few times now. :-)
>
> -Ian
>
>
>
> On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> > Ian asked me to look into writing a polygon function. This is now
> > finished and is in my SVN branch.
> >
> > To use the new function, simply define a number of points in an array,
> > and then pass this plus the number of pairs you want to plot to the
> > polygon function. For example, the following code will plot a
> > triangle:
> >
> > clg
> > dim test(6)
> > test[0] = 10
> > test[1] = 80
> > test[2] = 20
> > test[3] = 10
> > test[4] = 80
> > test[5] = 30
> > colour blue
> > poly test, 3
> >
> > Cheers
> >
> > /Ferry
> >

Re: [Kidbasic-devel] Polygon function

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

The POLY command looks great, I just merged it in, along with colour.

I added a line to delete the "c" value that gets popped off the stack,
otherwise this would leak memory, and it wouldn't be noticeable until
the POLY command was used in a loop.  I've gotten bitten by this bug a
few times now. :-)

-Ian



On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> Ian asked me to look into writing a polygon function. This is now
> finished and is in my SVN branch.
>
> To use the new function, simply define a number of points in an array,
> and then pass this plus the number of pairs you want to plot to the
> polygon function. For example, the following code will plot a
> triangle:
>
> clg
> dim test(6)
> test[0] = 10
> test[1] = 80
> test[2] = 20
> test[3] = 10
> test[4] = 80
> test[5] = 30
> colour blue
> poly test, 3
>
> Cheers
>
> /Ferry
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Kidbasic-devel mailing list
> Kid...@li...
> https://lists.sourceforge.net/lists/listinfo/kidbasic-devel
>

Re: [Kidbasic-devel] File access?

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

Actually, I haven't given it much thought, but you're right, it would
be good to have that.

We could have an FOPEN, FREAD, and FWRITE command.  I'm just unsure of
whether they should work at the byte or character level.

What I usually do is write an example program or tutorial first, and
then code the commands.  It helps to focus on what is actually
necessary to teach kids.

Traditionally BASIC used READ and DATA statements for data input, but
personally I was never crazy about that approach, most importantly
because I think data should be a separate entity from the program that
reads/alters it.

The approach that LISP takes for file input is nice.  You can use the
lisp read command on an open file to read a token, or read-line to
read a line.  There's also read-char and read-byte.  This might be the
best way to handle it, so kids can have a text file of data separated
by white space and just read each token in one at a time.

-Ian




On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> Has anyone given any thought to file access? It would be useful to be
> able to open, read and write text files...
>
> Cheers
>
> /Ferry
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Kidbasic-devel mailing list
> Kid...@li...
> https://lists.sourceforge.net/lists/listinfo/kidbasic-devel
>

[Kidbasic-devel] File access?

[Ferry H. <fer...@gm...>]

Has anyone given any thought to file access? It would be useful to be
able to open, read and write text files...

Cheers

/Ferry

[Kidbasic-devel] Polygon function

[Ferry H. <fer...@gm...>]

Ian asked me to look into writing a polygon function. This is now
finished and is in my SVN branch.

To use the new function, simply define a number of points in an array,
and then pass this plus the number of pairs you want to plot to the
polygon function. For example, the following code will plot a
triangle:

clg
dim test(6)
test[0] = 10
test[1] = 80
test[2] = 20
test[3] = 10
test[4] = 80
test[5] = 30
colour blue
poly test, 3

Cheers

/Ferry

Re: [Kidbasic-devel] Icons

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

Oh, as far as the tutorial goes, here is a list of topics yet to be covered:

- goto/gosub/labels
- for/next loops
- arrays
- In depth tutorial about the difference between strings and numbers
- Discussion of why and how FASTGRAPHICS works
- Intermediate math functions (floor, ceil, rand)
- How to debug programs by stepping through

and anything else I haven't thought of :-)

-Ian


On 11/16/06, tony007 <sup...@go...> wrote:
>
>
> On 16/11/06, Ian Larsen <dr...@gm...> wrote:
> > I've just uncommented the line that disables the toolbars because it
> > was quick and easy, I'll add the menu options to turn them back on
> > later.
> >
> > It would be great to have someone do the icons.  I don't care if they
> > match the ones I have already, unless he'd like to use that as a
> > starting point.  It seems that shiny buttons are all the rage these
> > days, which is why those look like they do.  My only requirement is
> > that they be sort of universal, so that non-English speakers can
> > understand them.  (For example, I'm not sure an icon of an insect for
> > "debug" would translate well)
>
> :-) I'd never have thought of using an insect for debug - it's quite good
> really!
>  Having said that, debug is kind of tricky really...
>
> > I'm going to copy in some standard icons for new, open, save, etc. as
> > placeholders for better looking icons.
>
> I'll get him to do it and pass on your concerns about them being universal.
> I used to work with him a couple of years ago and I know that he is aware of
> these issues so hopefully they turn out right pretty much straight away.
> If you had to pick an age group to target what would it be, just to give him
> a rough idea?
>
> I've got some time to spend on the app in the next few days. I'll merge from
> trunk/ into /branches/tony and do the work in the branch. Then I'll try and
> put together an interesting tutorial - do you have anything in particular
> that you'd like to see covered? If not I'll do a simple game of some
> description.
>
> Just to confirm, are you using Qt 4.2 as there have been some changes from
> 4.1.
>
> tony
>
> > -Ian
> >
> >
> > On 11/16/06, tony007 <sup...@go...> wrote:
> > >
> > >
> > > On 15/11/06, Ian Larsen <dr...@gm... > wrote:
> > > > I've fixed a few things in the trunk of the svn repository.
> > > >
> > > > Compilation no longer requires different commands in the LEX directory
> > > > for unix and windows, a simple "make" will do for both.  (Does anyone
> > > > know how to automate this with qmake?)
> > >
> > >  You can probably do this from the BASIC256.pro file using the 'system'
> > > function.
> > >  i.e.
> > >  MADE_LEX = TRUE
> > >  exists( ./LEX/Makefile ) {
> > >      system( make -C ./LEX ):MADE_LEX=FALSE
> > >  }
> > >  eval( MADE_LEX = FALSE ) {
> > >      error( Couldn't make LEX project - aborting... )
> > >  }
> > >
> > >  I've haven't tested this cause I'm at work and have an urgent 'crisis'
> to
> > > deal with...
> > >  Take a look at
> > >
> http://doc.trolltech.com/4.2/qmake-function-reference.html
> > > for more information.
> > >
> > >
> > > > Also, I've added a resources directory, where icons are stored.  These
> > > > are then compiled into the executable using qt's handy resource
> > > > compiler, so there's no need to distribute .png's with the
> > > > application.
> > > >
> > > > As far as icons go, I'm looking for ideas for good symbols that are
> > > > universal for New Program, Debug, etc.  I think a green triangle and
> > > > red square are fairly standard for Run and Stop.
> > >
> > >  I've got a graphic designer friend who has said he will make some
> button
> > > icons. He has vast amounts of experience creating graphics for
> educational
> > > software aimed at children, but said it might take him a week or so to
> get
> > > it done as he's really busy at the moment I can give him the ones you've
> > > done so far to give him an idea of the 'theme' if you like. Let me know
> if
> > > you want to take advantage of the offer or not Ian?
> > >
> > >  btw. Ian, are you sure about disabling the dock window toolbars in the
> > > code? I thought you meant you'd set them to be not-visible by default so
> > > that they don't clutter up the app when it's loaded. What about the
> person
> > > who a) doesn't compile from source but downloads the binaries and b) has
> a
> > > large resolution screen. I've always thought it's better to offer
> > > functionality but give users to option to use or not use it as they
> choose.
> > > Just my two cents worth...
> > >
> > >  tony
> > >
> > > > -Ian
> > > >
> > > >
> > >
> -------------------------------------------------------------------------
> > > > Take Surveys. Earn Cash. Influence the Future of IT
> > > > Join SourceForge.net's Techsay panel and you'll get the chance to
> share
> > > your
> > > > opinions on IT & business topics through brief surveys - and earn cash
> > > >
> > >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > > _______________________________________________
> > > > Kidbasic-devel mailing list
> > > > Kid...@li...
> > > >
> > >
> https://lists.sourceforge.net/lists/listinfo/kidbasic-devel
> > > >
> > >
> > >
> > >
> -------------------------------------------------------------------------
> > > Take Surveys. Earn Cash. Influence the Future of IT
> > > Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> > > opinions on IT & business topics through brief surveys - and earn cash
> > >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > >
> > > _______________________________________________
> > > Kidbasic-devel mailing list
> > > Kid...@li...
> > >
> https://lists.sourceforge.net/lists/listinfo/kidbasic-devel
> > >
> > >
> > >
> >
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> Kidbasic-devel mailing list
> Kid...@li...
> https://lists.sourceforge.net/lists/listinfo/kidbasic-devel
>
>
>

Re: [Kidbasic-devel] Icons

[tony007 <sup...@go...>]

On 16/11/06, Ian Larsen <dr...@gm...> wrote:
>
> I've just uncommented the line that disables the toolbars because it
> was quick and easy, I'll add the menu options to turn them back on
> later.
>
> It would be great to have someone do the icons.  I don't care if they
> match the ones I have already, unless he'd like to use that as a
> starting point.  It seems that shiny buttons are all the rage these
> days, which is why those look like they do.  My only requirement is
> that they be sort of universal, so that non-English speakers can
> understand them.  (For example, I'm not sure an icon of an insect for
> "debug" would translate well)


:-) I'd never have thought of using an insect for debug - it's quite good
really!
Having said that, debug is kind of tricky really...

I'm going to copy in some standard icons for new, open, save, etc. as
> placeholders for better looking icons.


I'll get him to do it and pass on your concerns about them being universal.
I used to work with him a couple of years ago and I know that he is aware of
these issues so hopefully they turn out right pretty much straight away.
If you had to pick an age group to target what would it be, just to give him
a rough idea?

I've got some time to spend on the app in the next few days. I'll merge from
trunk/ into /branches/tony and do the work in the branch. Then I'll try and
put together an interesting tutorial - do you have anything in particular
that you'd like to see covered? If not I'll do a simple game of some
description.

Just to confirm, are you using Qt 4.2 as there have been some changes from
4.1.

tony

-Ian
>
>
> On 11/16/06, tony007 <sup...@go...> wrote:
> >
> >
> > On 15/11/06, Ian Larsen <dr...@gm...> wrote:
> > > I've fixed a few things in the trunk of the svn repository.
> > >
> > > Compilation no longer requires different commands in the LEX directory
> > > for unix and windows, a simple "make" will do for both.  (Does anyone
> > > know how to automate this with qmake?)
> >
> >  You can probably do this from the BASIC256.pro file using the 'system'
> > function.
> >  i.e.
> >  MADE_LEX = TRUE
> >  exists( ./LEX/Makefile ) {
> >      system( make -C ./LEX ):MADE_LEX=FALSE
> >  }
> >  eval( MADE_LEX = FALSE ) {
> >      error( Couldn't make LEX project - aborting... )
> >  }
> >
> >  I've haven't tested this cause I'm at work and have an urgent 'crisis'
> to
> > deal with...
> >  Take a look at
> > http://doc.trolltech.com/4.2/qmake-function-reference.html
> > for more information.
> >
> >
> > > Also, I've added a resources directory, where icons are stored.  These
> > > are then compiled into the executable using qt's handy resource
> > > compiler, so there's no need to distribute .png's with the
> > > application.
> > >
> > > As far as icons go, I'm looking for ideas for good symbols that are
> > > universal for New Program, Debug, etc.  I think a green triangle and
> > > red square are fairly standard for Run and Stop.
> >
> >  I've got a graphic designer friend who has said he will make some
> button
> > icons. He has vast amounts of experience creating graphics for
> educational
> > software aimed at children, but said it might take him a week or so to
> get
> > it done as he's really busy at the moment I can give him the ones you've
> > done so far to give him an idea of the 'theme' if you like. Let me know
> if
> > you want to take advantage of the offer or not Ian?
> >
> >  btw. Ian, are you sure about disabling the dock window toolbars in the
> > code? I thought you meant you'd set them to be not-visible by default so
> > that they don't clutter up the app when it's loaded. What about the
> person
> > who a) doesn't compile from source but downloads the binaries and b) has
> a
> > large resolution screen. I've always thought it's better to offer
> > functionality but give users to option to use or not use it as they
> choose.
> > Just my two cents worth...
> >
> >  tony
> >
> > > -Ian
> > >
> > >
> >
> -------------------------------------------------------------------------
> > > Take Surveys. Earn Cash. Influence the Future of IT
> > > Join SourceForge.net's Techsay panel and you'll get the chance to
> share
> > your
> > > opinions on IT & business topics through brief surveys - and earn cash
> > >
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > _______________________________________________
> > > Kidbasic-devel mailing list
> > > Kid...@li...
> > >
> > https://lists.sourceforge.net/lists/listinfo/kidbasic-devel
> > >
> >
> >
> >
> -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> > opinions on IT & business topics through brief surveys - and earn cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >
> > _______________________________________________
> > Kidbasic-devel mailing list
> > Kid...@li...
> > https://lists.sourceforge.net/lists/listinfo/kidbasic-devel
> >
> >
> >
>

Re: [Kidbasic-devel] Icons

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

I've just uncommented the line that disables the toolbars because it
was quick and easy, I'll add the menu options to turn them back on
later.

It would be great to have someone do the icons.  I don't care if they
match the ones I have already, unless he'd like to use that as a
starting point.  It seems that shiny buttons are all the rage these
days, which is why those look like they do.  My only requirement is
that they be sort of universal, so that non-English speakers can
understand them.  (For example, I'm not sure an icon of an insect for
"debug" would translate well)

I'm going to copy in some standard icons for new, open, save, etc. as
placeholders for better looking icons.

-Ian


On 11/16/06, tony007 <sup...@go...> wrote:
>
>
> On 15/11/06, Ian Larsen <dr...@gm...> wrote:
> > I've fixed a few things in the trunk of the svn repository.
> >
> > Compilation no longer requires different commands in the LEX directory
> > for unix and windows, a simple "make" will do for both.  (Does anyone
> > know how to automate this with qmake?)
>
>  You can probably do this from the BASIC256.pro file using the 'system'
> function.
>  i.e.
>  MADE_LEX = TRUE
>  exists( ./LEX/Makefile ) {
>      system( make -C ./LEX ):MADE_LEX=FALSE
>  }
>  eval( MADE_LEX = FALSE ) {
>      error( Couldn't make LEX project - aborting... )
>  }
>
>  I've haven't tested this cause I'm at work and have an urgent 'crisis' to
> deal with...
>  Take a look at
> http://doc.trolltech.com/4.2/qmake-function-reference.html
> for more information.
>
>
> > Also, I've added a resources directory, where icons are stored.  These
> > are then compiled into the executable using qt's handy resource
> > compiler, so there's no need to distribute .png's with the
> > application.
> >
> > As far as icons go, I'm looking for ideas for good symbols that are
> > universal for New Program, Debug, etc.  I think a green triangle and
> > red square are fairly standard for Run and Stop.
>
>  I've got a graphic designer friend who has said he will make some button
> icons. He has vast amounts of experience creating graphics for educational
> software aimed at children, but said it might take him a week or so to get
> it done as he's really busy at the moment I can give him the ones you've
> done so far to give him an idea of the 'theme' if you like. Let me know if
> you want to take advantage of the offer or not Ian?
>
>  btw. Ian, are you sure about disabling the dock window toolbars in the
> code? I thought you meant you'd set them to be not-visible by default so
> that they don't clutter up the app when it's loaded. What about the person
> who a) doesn't compile from source but downloads the binaries and b) has a
> large resolution screen. I've always thought it's better to offer
> functionality but give users to option to use or not use it as they choose.
> Just my two cents worth...
>
>  tony
>
> > -Ian
> >
> >
> -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> > opinions on IT & business topics through brief surveys - and earn cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Kidbasic-devel mailing list
> > Kid...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/kidbasic-devel
> >
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> Kidbasic-devel mailing list
> Kid...@li...
> https://lists.sourceforge.net/lists/listinfo/kidbasic-devel
>
>
>

Re: [Kidbasic-devel] Icons

[tony007 <sup...@go...>]

On 15/11/06, Ian Larsen <dr...@gm...> wrote:
>
> I've fixed a few things in the trunk of the svn repository.
>
> Compilation no longer requires different commands in the LEX directory
> for unix and windows, a simple "make" will do for both.  (Does anyone
> know how to automate this with qmake?)


You can probably do this from the BASIC256.pro file using the 'system'
function.
i.e.
MADE_LEX = TRUE
exists( ./LEX/Makefile ) {
    system( make -C ./LEX ):MADE_LEX=FALSE
}
eval( MADE_LEX = FALSE ) {
    error( Couldn't make LEX project - aborting... )
}

I've haven't tested this cause I'm at work and have an urgent 'crisis' to
deal with...
Take a look at http://doc.trolltech.com/4.2/qmake-function-reference.htmlfor
more information.

Also, I've added a resources directory, where icons are stored.  These
> are then compiled into the executable using qt's handy resource
> compiler, so there's no need to distribute .png's with the
> application.
>
> As far as icons go, I'm looking for ideas for good symbols that are
> universal for New Program, Debug, etc.  I think a green triangle and
> red square are fairly standard for Run and Stop.


I've got a graphic designer friend who has said he will make some button
icons. He has vast amounts of experience creating graphics for educational
software aimed at children, but said it might take him a week or so to get
it done as he's really busy at the moment I can give him the ones you've
done so far to give him an idea of the 'theme' if you like. Let me know if
you want to take advantage of the offer or not Ian?

btw. Ian, are you sure about disabling the dock window toolbars in the code?
I thought you meant you'd set them to be not-visible by default so that they
don't clutter up the app when it's loaded. What about the person who a)
doesn't compile from source but downloads the binaries and b) has a large
resolution screen. I've always thought it's better to offer functionality
but give users to option to use or not use it as they choose. Just my two
cents worth...

tony

-Ian
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Kidbasic-devel mailing list
> Kid...@li...
> https://lists.sourceforge.net/lists/listinfo/kidbasic-devel
>

[Kidbasic-devel] Icons

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

I've fixed a few things in the trunk of the svn repository.

Compilation no longer requires different commands in the LEX directory
for unix and windows, a simple "make" will do for both.  (Does anyone
know how to automate this with qmake?)

Also, I've added a resources directory, where icons are stored.  These
are then compiled into the executable using qt's handy resource
compiler, so there's no need to distribute .png's with the
application.

As far as icons go, I'm looking for ideas for good symbols that are
universal for New Program, Debug, etc.  I think a green triangle and
red square are fairly standard for Run and Stop.

-Ian

Re: [Kidbasic-devel] new branch

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

Cheers Tony,

I like that menu as you have it laid out, with the submenus for
printing, etc.  While these are requested features, I just don't see
them being used that frequently where hiding them in a menu would be a
usability problem.

> I just find that whenever you say something won't happen it usually
> does happen :-)

This has happened to me several times on this project already :-)

-Ian


On 11/14/06, tony007 <sup...@go...> wrote:
> Cheers Ian.
>
>  I agree that the toolbars make the window look cluttered and think your
> right to disable them by default. I think the challenge is to make the
> functionality easily available and to make the association with the relevant
> view clear whilst not cluttering up the interface and/or deviating too far
> from standard UI practises.
>  The one idea I had about putting them in menus but still making the
> association clear was to create a menu for each view and putting the items
> under that. The only problem with that is what do you do if/when you end up
> with a lot of views which will mean a lot of toplevel menu items. So I
> didn't initially do this not because I think it's a bad idea, just because I
> thought there might be a better solution ( which hadn't been thought of yet
> ). Perhaps an alternative would be that under the View menu we have an item
> for each view which could then have subitems for each function. i.e.
>
>  View
>     |_ Toolbars
>     |_ Text Output
>     |     |_ Copy
>     |     |_ Paste
>     |     |_ etc...
>     |_ Graphics Output
>           |_ Copy
>           |_ etc...
>
>  That way there is no risk of having too many menu items in the menu bar. Of
> course it is probably unlikely there will be so many views that this would
> happen, I just find that whenever you say something won't happen it usually
> does happen :-)
>
>  tony
>
>
>
> On 13/11/06, Ian Larsen <dr...@gm...> wrote:
> > Tony,
> >
> > What you've done is great and I've merged it in to the main trunk.
> >
> > I do think the toolbars on the output windows make things a bit
> > cluttered, especially for people using lower resolution screens.  I've
> > disabled them by default.  I think that maybe those functions would be
> > better included in their own menu, since I don't think that printing,
> > etc. if going to be as common a function as "Run," for example.
> >
> > I'm thinking about eliminating the pushbuttons at the bottom of the
> > window and adding them as toolbar options, instead.  That will leave a
> > bit of extra space for the editor text.
> >
> > -Ian
> >
> > On 11/12/06, tony007 < sup...@go...> wrote:
> > > I've created a 'tony' branch and committed revision 115. The comment for
> the
> > > commit lists most of what has been done but I wanted to list some other
> > > relevant details.
> > >
> > > Commit comment-
> > > * Added new files to allow toolbars to be used in dock windows.
> > > * Moved initialisation code from main() to MainWindow()
> > > * Added toolbars to main window, text output and graphics output windows
> > > * Added support for copy, paste and printing to each widget
> > >
> > > Plus-
> > >  1. Toolbar buttons just use text at the moment until there are some
> nice
> > > graphics to use as the icons.
> > >     - I've sent an email to some friends of mine who have experience
> with
> > > this type of thing to see if any of them would like to help.
> > > 2. Only built and tested on Debian - 2.6.17
> > >
> > > tony
> > >
> > >
> -------------------------------------------------------------------------
> > > Using Tomcat but need to do more? Need to support web services,
> security?
> > > Get stuff done quickly with pre-integrated technology to make your job
> > > easier
> > > Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> > >
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > >
> > > _______________________________________________
> > > Kidbasic-devel mailing list
> > > Kid...@li...
> > >
> https://lists.sourceforge.net/lists/listinfo/kidbasic-devel
> > >
> > >
> > >
> >
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> _______________________________________________
> Kidbasic-devel mailing list
> Kid...@li...
> https://lists.sourceforge.net/lists/listinfo/kidbasic-devel
>
>
>

Re: [Kidbasic-devel] new branch

[tony007 <sup...@go...>]

Cheers Ian.

I agree that the toolbars make the window look cluttered and think your
right to disable them by default. I think the challenge is to make the
functionality easily available and to make the association with the relevant
view clear whilst not cluttering up the interface and/or deviating too far
from standard UI practises.
The one idea I had about putting them in menus but still making the
association clear was to create a menu for each view and putting the items
under that. The only problem with that is what do you do if/when you end up
with a lot of views which will mean a lot of toplevel menu items. So I
didn't initially do this not because I think it's a bad idea, just because I
thought there might be a better solution ( which hadn't been thought of yet
). Perhaps an alternative would be that under the View menu we have an item
for each view which could then have subitems for each function. i.e.

View
   |_ Toolbars
   |_ Text Output
   |     |_ Copy
   |     |_ Paste
   |     |_ etc...
   |_ Graphics Output
         |_ Copy
         |_ etc...

That way there is no risk of having too many menu items in the menu bar. Of
course it is probably unlikely there will be so many views that this would
happen, I just find that whenever you say something won't happen it usually
does happen :-)

tony


On 13/11/06, Ian Larsen <dr...@gm...> wrote:
>
> Tony,
>
> What you've done is great and I've merged it in to the main trunk.
>
> I do think the toolbars on the output windows make things a bit
> cluttered, especially for people using lower resolution screens.  I've
> disabled them by default.  I think that maybe those functions would be
> better included in their own menu, since I don't think that printing,
> etc. if going to be as common a function as "Run," for example.
>
> I'm thinking about eliminating the pushbuttons at the bottom of the
> window and adding them as toolbar options, instead.  That will leave a
> bit of extra space for the editor text.
>
> -Ian
>
> On 11/12/06, tony007 <sup...@go...> wrote:
> > I've created a 'tony' branch and committed revision 115. The comment for
> the
> > commit lists most of what has been done but I wanted to list some other
> > relevant details.
> >
> > Commit comment-
> > * Added new files to allow toolbars to be used in dock windows.
> > * Moved initialisation code from main() to MainWindow()
> > * Added toolbars to main window, text output and graphics output windows
> > * Added support for copy, paste and printing to each widget
> >
> > Plus-
> >  1. Toolbar buttons just use text at the moment until there are some
> nice
> > graphics to use as the icons.
> >     - I've sent an email to some friends of mine who have experience
> with
> > this type of thing to see if any of them would like to help.
> > 2. Only built and tested on Debian - 2.6.17
> >
> > tony
> >
> >
> -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services,
> security?
> > Get stuff done quickly with pre-integrated technology to make your job
> > easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >
> > _______________________________________________
> > Kidbasic-devel mailing list
> > Kid...@li...
> > https://lists.sourceforge.net/lists/listinfo/kidbasic-devel
> >
> >
> >
>

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
> >
> >
>

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

Re: [Kidbasic-devel] new branch

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

Tony,

What you've done is great and I've merged it in to the main trunk.

I do think the toolbars on the output windows make things a bit
cluttered, especially for people using lower resolution screens.  I've
disabled them by default.  I think that maybe those functions would be
better included in their own menu, since I don't think that printing,
etc. if going to be as common a function as "Run," for example.

I'm thinking about eliminating the pushbuttons at the bottom of the
window and adding them as toolbar options, instead.  That will leave a
bit of extra space for the editor text.

-Ian

On 11/12/06, tony007 <sup...@go...> wrote:
> I've created a 'tony' branch and committed revision 115. The comment for the
> commit lists most of what has been done but I wanted to list some other
> relevant details.
>
> Commit comment-
> * Added new files to allow toolbars to be used in dock windows.
> * Moved initialisation code from main() to MainWindow()
> * Added toolbars to main window, text output and graphics output windows
> * Added support for copy, paste and printing to each widget
>
> Plus-
>  1. Toolbar buttons just use text at the moment until there are some nice
> graphics to use as the icons.
>     - I've sent an email to some friends of mine who have experience with
> this type of thing to see if any of them would like to help.
> 2. Only built and tested on Debian - 2.6.17
>
> tony
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> _______________________________________________
> Kidbasic-devel mailing list
> Kid...@li...
> https://lists.sourceforge.net/lists/listinfo/kidbasic-devel
>
>
>

[Kidbasic-devel] new branch

[tony007 <sup...@go...>]

I've created a 'tony' branch and committed revision 115. The comment for the
commit lists most of what has been done but I wanted to list some other
relevant details.

Commit comment-
* Added new files to allow toolbars to be used in dock windows.
* Moved initialisation code from main() to MainWindow()
* Added toolbars to main window, text output and graphics output windows
* Added support for copy, paste and printing to each widget

Plus-
1. Toolbar buttons just use text at the moment until there are some nice
graphics to use as the icons.
    - I've sent an email to some friends of mine who have experience with
this type of thing to see if any of them would like to help.
2. Only built and tested on Debian - 2.6.17

tony

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
>
>

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
> >
> >
> >
>

Re: [Kidbasic-devel] ideas

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

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
>
>
>

Re: [Kidbasic-devel] bug fix

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

Tony,

First of all, thanks for looking at this.

Traditionally I like to use the mailing lists so future developers
have a trail to refer to if they get stuck on a problem we've already
worked on.

So let's start using the kidbasic-devel mailing list.  I'm copying the
list on this email.

In other news, I'm about to release version 0.8.  It has a large
number of fixes and feature enhancements, including a step-through
debugger.  With this release I'm changing the category of the project
to Production/Stable, because I don't think there will be any major
changes to the BASIC language portion after this release, and instead
the focus will be on interface enhancements and translations.

-Ian

On 11/8/06, tony007 <to...@us...> wrote:
>
> Message body follows:
>
> Hi Ian,
>
> I spent some time looking at the undocked window focus bug
> last night and unfortunately it's not as straight forward as
> just calling setFocus(). QDockWidgets or ( QDockWindows as
> they were called in Qt3 ) are strange animals - when you
> dock/undock them they change the actual widget type and
> there is a bunch of reparenting going on ( at least this is
> how they work in Qt3 ) so I suspect this is causing problems
> with the focus being taken away at some stage... Anyway,
> I'll sort it out, and am mainly writing this to let you know
> that I am on the case and am doing something :-)
>
> Also, would you prefer to talk via one of the forums or
> mailing lists for the project or continue as we are via email?
>
> Cheers,
>
> tony
>
> --
> This message has been sent to you, a registered SourceForge.net user,
> by another site user, through the SourceForge.net site.  This message
> has been delivered to your SourceForge.net mail alias.  You may reply
> to this message using the "Reply" feature of your email client, or
> using the messaging facility of SourceForge.net at:
> https://sourceforge.net/sendmessage.php?touser=1431069
>
>