[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-03 11:01 AM, Sam Bull wrote:
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 setup.py basically allows someone to do:
$ pip install sgc
and have the package show up on their machine (likely in a virtualenv)
so that they can start following along with the tutorial. It also
allows you to do:
$ python setup.py sdist register upload
to release a new package automatically on PyPI. For a package such as
yours it should be approximately 20-30 lines of (largely boilerplate).
RPM and DEB packaging likely isn't as critical, as most people seeking
to make the package part of their game are likely to copy the tree into
the game before distribution. That said, both of those packaging tools
work best when there's a setup.py available, so that you can use all of
the standard, automatic mechanisms specifically set up for Python
distutils/setuptools packages.
* 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.
Other developers working on the library is good to know, that should be
mentioned *in the proposal* (you are now covering the idea of others
developing for it, but I don't see any mention that others have worked
on the project in the proposal).
* 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.
I see the section in the new proposal.
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.
Ah, okay, had not thought to use tab there.
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.
Much better now, though I'd still like to see a few more specifics
(you'll never satisfy me, of course, I *always* want more specifics :) ).
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.
I realize this may seem strange, but I would suggest putting
documentation further forward in the task-list, because...
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 also like to see you push the "get others to test out the
library" *much* earlier (in the community engagement period, i.e. the
first few weeks). That's so you can parallelise the feedback with the
work. I want you to use the feedback from both you and others trying
out the library to refine and control what you are working on. With the
attempts to have others work on it at the end, you are likely not to get
much feedback on what is working or not.
I'd want to see bug reports coming in *early* so that a 1.0 release can
be truly understood to be stable, with no blocking bugs, preferably
integrated into at least a couple "real" projects (not your own) and a
half a dozen "demonstration" projects (to ensure that it is really
flexible and widely applicable).
* 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.
That's good.
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.
Lay this out in the "My Project" section. Use point form. Explain this
stuff to the reviewers. Give your *rationale* for the library. You say
the only maintained library is PGU, address the question of whether SGC
should become "part" of Pygame eventually, or whether it will always be
an external library (hint: it likely should always remain an external
library, but there are states between "external" and "internal" which
might drive new users toward a library). Address the integration with
the community explicitly. Address *why* this project should be funded
above all the others, what value does it provide to the community (a
stable, maintained, well integrated GUI library that has been tested,
documented and integrated into multiple projects, proving its adaptability).
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.
Okay, I see better addressing of this issue in the proposal. You still
haven't addressed "learning from others". Have you reviewed other GUI
libraries to see what they produce, how they lay out their architecture,
etc? Not Pygame guis, but "real" GUIs, preferably game-oriented ones.
None of that shows up in the proposal.
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.
Technical note: one thing that happens in the tutorial there is that it
*looks* like you've replaced Pygame's set_mode()? If you are going to
set yourself out as following the Pygame way, you may want to introspect
current screen dimensions and layout from a passed-in screen object
that's the result of set_mode() That is, instead of doing the
set_mode() call yourself, you should be passed a screen on which to draw
and look at it to determine what size, mode, etc to use. Having a
*convenience* mechanism where you create the screen is nice for new
users, but people like their control in Pygame.
* 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.
Again, the point here is to get you to cover these issues *in the
proposal*. A reviewer needs to see that this project is not going to
die when the funds run out, that it will be accepted and embraced by the
community, that it will bring a tangible and non-trivial benefit to the
world. You are competing with proposals that have "slam dunk" stories
for integration and acceptance (they are fixing/changing part of an
existing app/library that is widely used to implement features that are
widely requested), you need to address the issue of integration
explicitly as you are proposing an "external" project.
HTH,
Mike
--
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com