GNOME Bugzilla – Bug 80240
games should be resizeable [smaller and larger]
Last modified: 2009-12-16 04:38:16 UTC
Games like GLines are quite hard to use if you only have a 480 pixel high screen. One has to undock the menu to fit it on screen. Gataxx/iagno has to be moved so the top is slightly off the screen to see the bottom. It'd be nice to have a zoom button to increase/decrease the size of the game.
This is a big problem in AisleRiot to. Some of the minimum screen sizes are bigger than 800x600 which is madness. Any of these games should be able to be played on a 640 x 480 screen. Two things that would help AisleRoit would be to have the cards squash when the piles get too long. This used to happen in the old version of freecell (I beleive) and it was a great feature. Good enough that the current version of WinXP does it. Also, smaller cards would make things more useable. Infact, instead of having about a gazillion different options on what size font, and how the suits look, (even though you can't see them - gratuitous plug for bug 80167), maybe you could replace all this with the ability to change the size of the cards, which would allow the window to be smaller. Default to the smallest size (which would look big enough on an 640x480 screen) and people can make the cards bigger on larger screen sizes if they choose.
The cards should be done in a scalable format (e.g. svg) and resize to suit the window size (preferably expanding the window until it runs out of screen space and then start shrinking the cards). Now you don't have to worry about manually setting the card size at all.
SVG cards.... we could....
Could also do SVG tiles for mahjongg. I noticed that some of the current tiles are hard to read on even my fairly low-res laptop screen- I can only imagine they'd be a real pain in the neck on 1600x1200. So... retitling this a bit to recognize that the bug should ideally be a little more general.
Resizeability of all games is one of the stated goals of the 2.5 series (of course we won't get them all done, but aisleriot, mahjongg and gnobots are all in need, gnomines and gnotravex are already done.) Mahjongg is currently undergoing a major rewrite of some large chunks of it's code. The drawing code is one part of this (it currently uses a hacked version of gnome-canvas and is awfully slow). The plan is not to do resizing immediately, but to have it in mind when the drawing code is rewritten and once it is working properly the resizing (with either pixmap or svg based tiles) should come easily. The hard bit is making a set of svg tiles, but I've been meaning to learn how to draw svg stuff for a while now :).
Mahjongg is now resizeable. Gnomine and Gnotravex were also resizeable fin GNOME 2.4. The next two that really need work are aisleriot (for the already mentioned reasons) and gnobots (because the graphics are too small on high-res screens). Others will follow as I get around to it (it is a goal for 2.6, but I know what my free time looks like :).
glines is now resizeable. Aisleriot still hasn't been done yet :(.
> Resizeability of all games is one of the stated goals of the 2.5 Do you think it will be possible to make the games scalable enought that the GPE (Gnome Palmtop Enviroment) would be able to use these games without minimal changes? > SVG Cards If someone were to develop SVG cards they would make wonderful clipart for reuse with Inkscape (or Sodipodi or whatever Vector graphics software you prefer) and improve the whole Desktop even beyond Gnome games.
The palm-top question: In general I doubt it. While all the games I've made scalable will work at low res none of them work well. Gnomine and glines would probably work, but it'd probably be better to have fixed-size graphics optimised for the target screen size. Gnotravex and mahjongg would be complete disasters since the fiddly detail of the numbers and the tiles doesn't work well with automatic scaling. In general for really low resolutions graphics hand-designed specifically for the target resolution are the way to go.
*** Bug 105536 has been marked as a duplicate of this bug. ***
Aisleriot is now resizable. It's in CVS now. This leaves: gnobots gnibbles (there is a patch for this in bugzilla) gnotski gtali (mostly done already) iagno/gataxx (will do as part of the merger) same-gnome gnome-stones blackjack gnometris gnect
Gnibbles is resizeable, this leaves: gnobots gnotski gtali (mostly done already) iagno/gataxx (will do as part of the merger) same-gnome gnome-stones blackjack gnometris gnect
Blackjack is now resizeable.
There are SVG playing cards there: http://david.bellot.free.fr/
here is a patch that makes gnect resizable.
Created attachment 31470 [details] [review] gnect_resizable.patch here are some explanations to make reviewing easier: main.c: - the drawarea is packed into a gridframe - connect to the configure event - split the button_press and expose callbacks (not strictly related to resizing, but while I was at it...) - delete set_resizable(FALSE) and set_wmclass which is obsolete - set a default size for the app (350x370, ok?) and a min size to avoid gtk problems when scaling down a lot gfx.[ch]: - use tilesize and boardsize instead of width, height, tileh, tilew since our board is square and it fits better with games-gridframe - add pixbufs to hold the scaled versions - remove always true arg from draw_all - add gfx_resize & gfx_update_pixmaps: these funcs take care of the real resizing - fiddle a bit with gfx_load (not strictly related to resizing, but I ended up with those changes as well... basically it now takes care of retrying with the default theme instead of retrying in main.c) - add a set_grid_style() so that gc doesn't need to be extern and a change_theme() to use in prefs.c prefs.c: - explicetly set p.theme_id = val - use the change_theme func - include the micro cleanup reported in #152275
Only two problems Paolo: No ChangeLog entry, and you don't use gconf to save the window size. I'll fix these two up. Also, blackjack is resizeable so this leaves the list at: gnobots gnotski gtali (mostly done already) iagno/gataxx (will do as part of the merger) same-gnome (underway) gnome-stones gnometris
gosh, I always forget the changelog entry when submitting patches to gnome games... sorry about that. About the gconf stuff, yes it's missing. Note that on the long run storing the size in gconf is not right (gconf may be readonly)... however many other apps (including the other resizable games) do the same, so I guess it is ok, until a proper session management solution is provided by gtk/gnome.
Yeah, I know about the "who should keep track of window size" problems. As far as I can tell conventional wisdom varies every few months. I keep it in gconf because, despite the possiblity of failure, it works without having to deal with any extra infrastructure. This is the sort of program where people want the window to open at the last size they used it (because the information inside it is essentially the same each time, as opposed to, say, an image viewer where it depends on the size of the image).
Now that Richard has done Klotski the list is: gnobots gtali (mostly done already) iagno/gataxx (will do as part of the merger) same-gnome (underway) gnome-stones gnometris
Same GNOME has now been converted (actually completely rewritten). The remainder: gnobots gtali (mostly done already) iagno/gataxx (will do as part of the merger) gnome-stones gnometris
Ataxx has now been made resizeable. The code can be found in the preview-2-13 branch in CVS. Remaining: gnobots gtali (mostly done already) iagno gnome-stones gnometris
gnometris too now. Remaining: gnobots gtali (mostly done already) iagno gnome-stones
gnome-stones now drops off because we removed it from gnome-games. The list is now: gnobots gtali (mostly just widgets, so it mostly works already) iagno
Created attachment 63868 [details] test case for scalable graphics in gnobots An exploration on how gnobots can look with scalable graphics: larger and nicer sprites. An exercise: isometric grid and grid size different than the sprites sizes (those have the disadvantage of requiring a specific z-order). (.svgz due to file size contraints on attachments)
I am currently working on the gnobots scaling code. The first cut (due in a day or so) will look pretty much like it does now. After that I'll play with it a little (it is almost essential to get some kind of grid drawn).
Robots now has primitive support for resizing. It all works, but still only supports PNG files and doesn't have any of the desperately needed improvements to the drawing engine (like a grid, and pango-rendered, translatable, text for the speech bubbles) let alone any of Nicu's suggestions.
*** Bug 391022 has been marked as a duplicate of this bug. ***
*** Bug 414566 has been marked as a duplicate of this bug. ***
Anyone is very welcome to submit patches to make gnobots, gtali and iagno scalable.
Re-assigning to new default owner.
Closing this as gnobots, gtali and iagno all fit into 480 resolution. Well gtali fits into 600 pixels and I'll encourage anyone who needs it to be shorter to open a bug against it directly.