Well I'm still experimenting both with pygtk as well as with wxpython.
The following question I have about programming with a gui toolkit
however is independant of the toolkit used, so I put it to both
lists.
The next thing I would like to try is a program like life, mine sweeper,
or griddler (aka nonogramm or paint by number). Basically this kind
of program requires a table all with similar data. However this table
could become quite large so I am a bit hesistant in implementing this
as a gtk_table/GridSizer, filled with thousands of widgets.
An alternative would be to have just one widget in which I draw al
elements as they should be, but this would be a little harder to
code.
So what are your ideas? Shouldn't I worry about having thousand
of widgets? Is there some kind of limit I should stay under?
Is there an other approach I didn''t think of.
I've coded Life in Java. I used a canvas and drew a bunch of images
on that canvas. I also had a version that just drew squares on that
canvas. Then I captured mouse events to permit the user to make the
cells alive or dead. I can't say if my way is any better than any
other way, but it worked for me.
Best Regards,
-jj
···
On Thu, Jun 05, 2003 at 10:35:00AM +0200, Antoon Pardon wrote:
Well I'm still experimenting both with pygtk as well as with wxpython.
The following question I have about programming with a gui toolkit
however is independant of the toolkit used, so I put it to both
lists.
The next thing I would like to try is a program like life, mine sweeper,
or griddler (aka nonogramm or paint by number). Basically this kind
of program requires a table all with similar data. However this table
could become quite large so I am a bit hesistant in implementing this
as a gtk_table/GridSizer, filled with thousands of widgets.
An alternative would be to have just one widget in which I draw al
elements as they should be, but this would be a little harder to
code.
So what are your ideas? Shouldn't I worry about having thousand
of widgets? Is there some kind of limit I should stay under?
Is there an other approach I didn''t think of.
--
Hacker is to software engineer as
Climbing Mt. Everest is to building a Denny's there.
In general, you'll want to handle the drawing yourself.
Minesweeper might make sense using a bunch of widgets and just changing the
graphic of the wxBitmapButton or wxStaticBitmap as the user clicks on the
widgets, but that is because the play field is small. You'll probably want
to maintain the underlying data of in a list of lists or dictionary.
Using individual widgets for each cell won't scale for something like life
and it restricts the scaling options. There you need to manage the drawing
yourself. Again, you need to maintain the underlying data in a separate data
structure. It turns out that using a dictionary is an elegant way to handle
an unlimited life universe size and the overhead of calculating each new
generation is dependent on the total number of live cells rather than the
universe size.
The calculations necessary to translate between mouse coordinates and your
screen grid so the user can easily toggle a cell are pretty simple. Just
take the x and y position and divide by the scale you're using for drawing;
you obviously don't need the scale if it is 1 to 1.
Anyway, if you want to see one way of doing all this, just look at the
PythonCard life sample.
-----Original Message-----
From: Antoon Pardon [mailto:Antoon.Pardon@rece.vub.ac.be]
Sent: Thursday, June 05, 2003 1:35 AM
To: python gtk rondzendlijst; python wx rondzendlijst
Subject: [wxPython-users] A lot of widgets or only one
Well I'm still experimenting both with pygtk as well as with wxpython.
The following question I have about programming with a gui toolkit
however is independant of the toolkit used, so I put it to both
lists.
The next thing I would like to try is a program like life, mine sweeper,
or griddler (aka nonogramm or paint by number). Basically this kind
of program requires a table all with similar data. However this table
could become quite large so I am a bit hesistant in implementing this
as a gtk_table/GridSizer, filled with thousands of widgets.
An alternative would be to have just one widget in which I draw al
elements as they should be, but this would be a little harder to
code.
So what are your ideas? Shouldn't I worry about having thousand
of widgets? Is there some kind of limit I should stay under?
Is there an other approach I didn''t think of.
--
Antoon Pardon
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org
Well I'm still experimenting both with pygtk as well as with wxpython.
The following question I have about programming with a gui toolkit
however is independant of the toolkit used, so I put it to both
lists.
The next thing I would like to try is a program like life, mine sweeper,
or griddler (aka nonogramm or paint by number). Basically this kind
of program requires a table all with similar data. However this table
could become quite large so I am a bit hesistant in implementing this
as a gtk_table/GridSizer, filled with thousands of widgets.
Avoiding the use of thousands of widgets is always a good thing. They each have lots of overhead that you definitly don't need in this case.
An alternative would be to have just one widget in which I draw al
elements as they should be, but this would be a little harder to
code.
is a PythonCard demo of using an off-screen/invisible bitmap to define
areas on a corresponding visible bitmap. When a click on the visible
bitmap occurs, the colour of the corresponding off-screem pixel is used
to determine what action to take. The technique can be used with any
toolkit which allows you to get the colour of a pixel at given
co-ordinates (e.g. under a click).
···
On Thu, Jun 05, 2003 at 10:35:00AM +0200, Antoon Pardon wrote:
--
John Hall <wexsessa@telusplanet.net>
Calgary, Alberta, Canada.
"Helping People Prosper in the Information Age".
is a PythonCard demo of using an off-screen/invisible bitmap to define
areas on a corresponding visible bitmap. When a click on the visible
bitmap occurs, the colour of the corresponding off-screem pixel is used
to determine what action to take. The technique can be used with any
toolkit which allows you to get the colour of a pixel at given
co-ordinates (e.g. under a click).
This is a nifty scheme that I use myself for doing hit tests on complex
objects. However, if you are dealing with a rectangular grid, it's
easier, faster, and uses less memory to jsut compute which grid
box was clicked on.
However, there does seem to be a consensus that you should be drawing
your grid yourself, rather than trying to use a bunch of widgets.
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception