confirming request, when/if I get time:)

This is probably going to be done for 2.5. The drawing code was
recently revised and allowance was made for implementing this. However
it's too late for it to be done in time for 2.4.

Created attachment 34685 [details] [review]
Remove some hardcoded constants allowing rectangular fields.

I have tested this patch in the last few days, and it works fine with
rectangular fields. 

I had to add the following change because there where some painting problems
when HFIELDSIZE>VFIELDSIZE. For example, if HF=15 and VF=9 some vertical lines
of squares would not be painted correctly when boxsize would be 38, 39, 41 or
some other dimensions.
Well, with this the problem does not occur anymore... (why?)

@@ -1690,8 +1691,8 @@ main (int argc, char *argv [])
			  G_CALLBACK (configure_event_callback), NULL);
	g_signal_connect (G_OBJECT (draw_area), "expose_event",
			  G_CALLBACK (field_expose_event), NULL);
-	gridframe = games_grid_frame_new (FIELDSIZE, FIELDSIZE);
-	games_grid_frame_set_padding (GAMES_GRID_FRAME(gridframe), 1, 1);
+	gridframe = games_grid_frame_new (HFIELDSIZE, VFIELDSIZE);
+	games_grid_frame_set_padding (GAMES_GRID_FRAME(gridframe), 1, 0);
	gtk_container_add (GTK_CONTAINER (gridframe), draw_area);
	gtk_table_attach_defaults (GTK_TABLE (table), gridframe, 0, 1, 1, 10);

Created attachment 34704 [details] [review]
B/W keyboard cursor coloring, protection against corrupt image files.

(The patch above shouldn't conflict with Marco's, stuffing it here since I'm
typing anyway... Ultimately, of course, both don't fix Bug #83532.)

Marco:
I'm not seeing the behavior you describe, and it's definitely the wrong thing
to do... the bottom of the grid draws over the bottom part of the keyboard
cursor (when it's at the bottom) because the padding is lost. Screenshots may
help.

Created attachment 34718 [details]
Screenshot of glines showing garble

That's the problem I was mentioning above. It happens only at particular sizes.

Just a quick note that I will be applying the patch tonight (didn't do anything
on gnome-games over the weekend because I needed to get my new laptop working
for work, I hate kernel bugs).

Both patches have now been applied, with the extra change from Marco's one
backed out.

I wasn't able to reproduce the corruption bug either. It looks like a rounding
error creeping in. I have fixed an obviously bad bit of arithmetic in the
drawing code which looked likely to cause problems. Marco, could you test the
latest CVS (once it updates in an hour or so) and tell me if it is fixed? If not
could you tell me exactly what processor you are using.

 

Created attachment 34999 [details] [review]
Remove some more hardcoded constants

This patch uses NPIECES to define how many new pieces are added after any move.


It also uses in a couple of places the already existing NCOLORS, so that it's
possible to define how many colors are used in the game (up to 7).

Patch applied in CVS. Thanks a lot.

Created attachment 38895 [details] [review]
Different sizes (field, colours, pieces added)

Ok, it's an working patch to fix part of this enhancement request.

What the patch does:
- Gives the user the choice between 3 different game sizes
- Each game size has its own field size (can be rectangular), number of
colours, and number of pieces added after each move

What it doesn't do:
- The preview is still limited to 3 pieces, while it should show all pieces
that will be added
- The scoretable doesn't take into account the game size

Created attachment 38909 [details] [review]
Marco's patch against CVS HEAD

Marco: I made a few changes in CVS concerning image warnings and UI API prior
to your patch, and this update to your patch reflects it... only one chunk was
affected, which is a good sign.
---
The big level with 7 balls is a nice challenge, and definitely has the
"managing complexity" feel to it the longer you go. Since glines, same-gnome,
and gnomine uses "Small", "Medium", "Large" without an explicit reference to
difficulty, I don't see any problems there. 

Personally, I don't see a need for the command line option. I'll look at the
missing features this weekend.

Created attachment 39106 [details] [review]
Patch v2 (also scores dialog)

This adds the scores dialog. For the rest, there is no other change (a part
from one obsolete comment removed).

We have several patches bearing on the same piece of code right now. Richard and
I discussed it this afternoon and there shouldn't be any real problems. I about
to apply some other HIG improvement patches. After that we can apply this patch.
Am I correct in thinking that patch 39106 is just 38909 with the scoring stuff
and the comment removed? (It is hard reading diffs of diffs.) If so, Richard do
you feel like applying it since you have most of it under control already? If my
assumption is wrong, then Richard, if you apply what you have in your
repository, I will fix up the scoring stuff from Marcos patch by hand.

I should also say that I think the scoring code is fine. There are a few things
that can go wrong, but they are easy enough to fix once we have synchronised the
code.
 

Yes, attachment 39106 [details] [review] is the same as 38909 plus scores and comment.

Created attachment 39127 [details] [review]
Updated to HEAD

This takes into account the HIG changes landed in CVS and adds mnemonics to the
size radiobuttons.

Created attachment 39130 [details] [review]
Fixes a missing comma.

Thanks... The patches have now been applied to CVS. Aside from the features 
already mentioned, games-grid-frame now supports alignment, glines now shows 
preview for more than 3 balls, and glines Makefile.am now supports 3 high score 
files.