[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Student summer(or winter) of code projects, $5000 from google.

On 12-04-02 02:08 PM, Sam Bull wrote:

On Fri, 2012-03-30 at 22:51 +0200, Renà Dudfield wrote:

If anyone needs help with a proposal, let us know.

I'd like to do some more work on my GUI toolkit. I know it's not
directly working on Pygame, but I think it will greatly benefit the
community.

I'm going to write a proposal with a brief overview of the project, and
then link to my project specification. If anybody would like to review
the specification, you can find it at
http://sambull.org/downloads/spec.odt

The spec was initially written a couple of years ago, and much of the
stuff on there has already been implemented. I've added an expansion
point to the end to list additional things for GSoC 2012.

As soon as I send this email, I'll be making another beta release of the
project. So, if you would like to see the current state of the project,
then please wait for my next email.
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
 * 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
 * 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?
     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)
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?
     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?
 * 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.
 * 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?
 * 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)?
     o GSOC AFAIK prioritizes getting new developers into *existing*
       projects, building the community of developers.  How does this
       project integrate into the larger community of Pygame developers?

HTH,
Mike

--
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com