On Tue, 2012-04-03 at 09:26 -0400, Mike C. Fletcher wrote: > We need more concrete details for the proposal. Looking through the > code on Launchpad: > > * you don't seem to have a setup.py or similar "traditional" > installer; that would be a requirement for broad acceptance > o even those who are going to copy your code into their trees > likely want to experiment with it first To be honest, I'm not entirely sure what a setup.py installer should do. The only thing you need to use the code is to make sure it's importable, either by putting it in the top-level of your project or putting it somewhere PYTHONPATH can find it. I'll be happy to create some kind of installer if it's needed. I would be interested in creating deb and rpm packages to install it globally, if someone can give me tips on how to do this. > * the selection of widgets is fairly sparse > o I don't know that that is really a *bad* thing, games do tend to > use a fairly sparse set of widgets With the core of the toolkit stabilising, it is fairly easy to add additional widgets. The radio button and toggle button were created by a friend last week with only a little help from me. It was about a day's worth of work for each widget. With the developer documentation completed I'm convinced that any developer could create new widgets. I still need more widgets for my own games, so I will be adding more sooner or later either way. > * there doesn't *seem* to be a theme/skinning mechanism > o that is, how would I go about making my buttons look like > flaming ovals instead of rectangles in order to match my > flaming-eggs game? That is a feature that is not fully documented or tested, and a little buggy. This is one of the things I will be completing early on for GSoC. If you'd like to know how it works (or almost works), then the first argument you pass to a widget can be a tuple containing the size, but you can instead pass in a pygame.Surface object, and it will use that surface to draw the widget. There is a slightly more complex option using a dictionary to specify images for different states, such as the up, over and down images of a button. > o how would I control menu layouts (position, adding preview > windows to the right side, etc) > * menus don't *seem* to have any keyboard control (at least, none I > was able to trigger in the test app) Menu layouts need some more work to be more customisable. At the moment you can only add widgets in a vertical manner (and the format for it is not documented yet). Keyboard support works with TAB, one of the minor features not yet implemented from the list on my spec is to add up/down key support. > > Issues to address in the proposal (note: these are at least things you > need to address, I'm not saying "do or do not", but "provide your > rationale"): > > * Reaching a 1.0 release is not a sufficiently well specified goal > (after all, you could increment the version number and upload to > complete) > o What will be accomplished (specifics, what $5000 worth of work > needs to be accomplished, on what approximate time schedule)? > + What metrics will be used to judge the attainment of the goals? > + What level of documentation is required? > + Are you going to produce tutorials or just references? > + What level of testing is required? Right, I've added a rough timeline to the GSoC proposal, I will expand on it with more details of what the end result should be for each task. Documentation for individual widgets is done. I will add more tutorials to cover some other aspects as mentioned at the end the .odt file. I will then try to get some feedback from people trying to use it. If they have difficulty or need to ask questions, then I need to expand on the documentation or make it clearer. I currently have an API reference, and will be adding tutorials toward the end of GSoC. > o Are you going to speculatively convert some open source games to > use the library to test it's ability to integrate into other > projects? That's a great idea. I'm confident that my toolkit could be easily dropped into a traditionally developed game (that is, a game with a global game loop updating everything and an event loop). > * I would like to see some real adoption/interest numbers. GSOC > implies creating something that a significant collection of people > are going to want to be using the project's results. > o Is there a strong interest from third-party developers in the > project [You say the library is ready to replace the other > toolkits, but don't mention how many people are planning to > switch from other libraries to yours as soon as it is stable] > o Are other people using the widgets already, if not, what is > stopping them? Do you have user feedback on this? If not, it > might be useful to ask the Pygame community to weigh in on it > over the next day or two. When I released a version some time ago, I got some good feedback. The problem of people not using it, is that at that time it was a little more fiddly to set up and had no documentation. The release I made yesterday is a lot cleaner and has the first step towards good documentation. There was some positive feedback from several users expressing the same concerns as myself. One such user mentioned 3 things, and that none of the toolkits did all 3. He basically expressed that his concern that none of them did things "the pygame way". They were: Not taking over the event loop, such as PGU, this is something my toolkit has never done. Subclassing from pygame sprites. I added this about the time this was mentioned to me. Using regular pygame events for widget events. This is something I have begun to put in, but needs documentation and a little more work, another task I have listed for GSoC. You can see some of this feedback on the archives: http://www.mail-archive.com/pygame-users@xxxxxxxx/msg14880.html I think that is the correct link, but the site has gone down as I was viewing it. :S > * What is the rationale for a new library over refining an > existing/in-production library? That likely needs to be addressed > explicitly and in detail. > o Why not enhance PGU or the like with better keyboard support? > What are the *specific* failings that make it's approach > unworkable? Adding tab support or selection-in-text-boxes to an > existing library sounds fairly workable, if that is their only > failing. > o Why not branch/fork an existing library to bootstrap development? > o Why not borrow code from appropriately-licensed libraries? The reason I was vague in the proposal, is that I looked at all these toolkits nearly two years ago, before I decided that I would need to create my own. Looking back at PGU, the problem I see with this toolkit is that it appears to be a GUI toolkit on top of Pygame. It appears you can create a full application that is built on Pygame, but I can't work out how you would integrate it with an actual game. My toolkit integrates with Pygame. This means that you can write a full game in the usual manner, then with a couple of extra lines of code, you can add widgets, add a game menu etc. To see how simple this is, just take a look at the quick-start tutorial I've written, which demonstrates the bare minimum to get a widget on-screen. http://program.sambull.org/sgc/tutorial.html#first-example The breakdown below shows the individual lines that actually matter to the toolkit. > * If I understand correctly there have been at least half a dozen > Pygame GUI libraries over the years. Devil's advocate says the > problem isn't so much getting a GUI library written as keeping it > maintained. > o How does this project avoid "tossing it over the wall" (that is, > finishing and abandoning the project)? I have been working on this project where I can spare the time for nearly two years now. I am using the toolkit with two game projects I am currently working on, my own game in OpenGL and a plain Pygame game I'm working on with a couple of other people. I have been motivated to keep working on this when it was just me and one game. I'm only more motivated now I am working on a second game with other people. I also believe that after GSoC, the code will be in a state that it would be easy for somebody else to take over maintaining if it ever came to that.
Attachment:
signature.asc
Description: This is a digitally signed message part