Re: [pygame] Redesigning the pygame.org website
I can only talk about our project, so here is a very short summary: The (hopefully) full feature list can be found here: http://groups.google.com/group/pygame-mirror-on-google-groups/browse_thread/thread/ad40b90abae80375 We actually did migrate the data from pygame.org already (in 2009) and it was quite easy with some small scripts. The preview instance is online (again) at http://pygameweb.no-ip.org. Its status was (and still is) release candidate, ie. it may have some minor bugs etc. but may not require too much work for an initial deployment. @Katie: As I said in my last mail, we mainly finished development but no one wanted to use/run/launch it. As Ian and I said, have a look at the archives for all the details. Julian Original-Nachricht Datum: Mon, 17 Sep 2012 20:01:41 -0400 Von: Katie Cunningham katie.ful...@gmail.com An: pygame-users@seul.org Betreff: Re: [pygame] Redesigning the pygame.org website On Mon, Sep 17, 2012 at 6:17 PM, Ian Mallett geometr...@gmail.com wrote: Hi all, If you look through the mailing list archives, there are a number of references to such attempts in the past, and every so often it comes up again (as now). There have been a few efforts too. I personally would like to see one of them adopted and used. The old site is now desperately showing its age. I like (or maybe am used to) the overall look of the website, but it really needs to be polished up a lot. This suggests an improvement rather than scrap-and-restart method. I also lend my support to this project. Thanks, Ian How far did these other efforts get, and do we know why they were never pushed forward? That might be the most valuable bit of knowledge we can gain from past endeavors. Katie
Re: [pygame] Redesigning the pygame.org website
There is no wiki? Sure there is: http://pygameweb.no-ip.org/dev/wiki We just did not want to reinvent the wheel and write our own wiki system. Maybe one could add an extra tab to the main navigation to directly link to the wiki.
Re: [pygame] Redesigning the pygame.org website
As far as I know there was an effort to do that, but it never got live. Yep, Devon, Orcun and I worked on a new site back in 2009 for nearly one year. It had some quite nice features (imo) and Devon designed a stylish ui. It never got live cause the pygame core team did not want to use it and we did not have the time (and motivation) to launch it as stand alone site. However, its still there in the repos. The backend is made with Django and it has build-in support for embedded sphinx documentation as well as a trac instance integrated (for wiki, tickets and repo viewer). If anyone wants to launch it or take it as source of inspiration or use it in any other way, feel free to do so. For the full story have a look at the mailing list archives.
Re: [pygame] Antialiased circle
Here is a small module that works on top of pygame.gfxdraw to draw some nice (filled) aacircles, lines and rounded rects (have a look at the examples): https://bitbucket.org/schlangen/pexdra this was mainly a test to see whats possible and also to compare different methods. Of course its damn slow :) I also started to port the pygamedraw module from pygame2 to pygame, but it has no (good-working) anti-aliasing yet.
Re: [pygame] Difference Between pygame.draw and pygame.gfxdraw
Hey Carl, I'm the author of pygamedraw and unfortunately it was not yet merged into either pygame2 (this was the initial aim) or pygame. Since the end of GSoC 2010 I had a very limited amount of free time. In my last blog post I gave a little overview how one could continue with the project (see http://pygamedraw.wordpress.com/). So if you have some time it would be really cool if you'd bring it forward a bit. Just check out the repo, install pygame2, get it running start and playing with the code. If you have some experience with C extensions you could port it to C and speed it up a bit. If you really start with it and have any questions or issues feel free to contact me and I'll be happy to help you with this. Maybe I'll also write some more code there if I get round to it. Best Regards Julian Original-Nachricht Datum: Mon, 28 Nov 2011 22:09:35 +0100 Von: Carl Holmberg carlsholmb...@gmail.com An: pygame-users@seul.org Betreff: Re: [pygame] Difference Between pygame.draw and pygame.gfxdraw Did the GSOC-project in 2010 ever make it in to pygame? Found the repository a while ago: https://bitbucket.org/schlangen/pygamedraw/ I was wondering if it would be possible to create a Easy hacks-list (like The Document Foundation does for LibreOffice) to ease in to helping out in developing pygame. If I have some time over it would be interesting to help out, but I wouldn't know where to start! /Carl 28 nov 2011 kl. 21.18 skrev Lenard Lindstrom: Hi, There is not a lot of difference. If I understand correctly, the draw module is based on the gfxdraw library. The gfxdraw module was backported into Pygame from Pygame Reloaded. It has a few antialiased draw functions missing in the Pygame draw module. But all gfxdraw functions produces 1 pixel width lines only. The draw module uses crude methods to also produce wider lines. In general, the gfxdraw module is more low level, but also implements more basic draw operations. Lenard Lindstrom On Nov 28, 2011, ANKUR AGGARWAL coolankur2...@gmail.com wrote: Hey I was goofing around the web and found out the gfx draw API of the python module. Through search and all found out that it is used to draw shapes . pygame.draw also do the same work. So I want to know what exactly is the difference between them??? I searched on the web a lot but unable to find out an appropriate answers. Please help!!! Thanks In Advance Regards Ankur Aggarwal -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone
Re: [pygame] Using reStructuredText for document sources
Hi Lenard, when I wrote my convert script [1] I reached a point when I found it easier to edit the output (rst files) manually instead of implementing proper handling for all the special cases etc. So maybe it would be better to take my rst-files and continue to improve them (fix last markup fix and improve content) as the convert script would be only used this single time. Then you can replace the .doc files in the source with the rst-files and some sphinx project files for building etc. in a doc or ref folder. To the structure: I think the basic structure (module - classes - methods) is standard. But the way of documenting stuff could be really improved with the features of rst markup (and maybe sphinx plug-ins/extensions or however they call it). For example, hugoruscitti added images to the docs of the transform module. I like it a lot as it shows instantly what each single method does and also makes the page easier to read as it breaks this big text-only block. The template/style for the html-generator could be edited to fit into the pygame.org webpage (if not the other way round :-) ). The comments feature of the current solution is quite useful, but the result is that the comments are not merged into the main documentation and so an offline version of the docs is more or less useless (at least for some modules or functions). So removing the comment feature would remove spam, very long and hence wrong placed example programs and stupid hello world/this is cool/... dummy comments from the docs. If someone has a serious interest to improve the docs somewhere it should not be too hard to post a new version (or just a note that a certain part should be improved) on the mailing list. In general, I'm absolutely convinced that a migragion of the pygame documentation to a rst/sphinx based system would be an huge improvement for pygame. It would be a lot easier for more people to participate in writing and improving documentation. The markup would be standardized (well, kind of) and the output would be flexible (you can generate documentation as webpage, pdf, etc.) To use a wiki could be better than the current solution, but you'd need to moderate it, remove spam/stupid and/or wrong content/etc. - work, no one has time for. Regards, Julian [1] https://bitbucket.org/schlangen/pygame-docs/src/00217ff414bb/scripts/make_new_ref.py Am 04.03.2011 00:09, schrieb Lenard Lindstrom: Hi everyone, It seems that as useful as it has been makeref,py, the custom Pygame document generator, is showing its age. It makes little sense to continue maintaining makeref.py when other, more powerful, document generators are available off-the-shelf. So I am proposing to convert Pygame's custom .doc files to reSTructuredText, and have docutils and Sphinx generate the documents. As well as being the tool chain used to produce the Python documents, Marcus uses reST for pgreloaded. Also, Julian (jug) has translated the Pygame doc source to reST once already. But I admit I did not fully appreciated his efforts at the time. I am already improving the makeref.py tokenizer for use in a Pygame DOC to reST translator. Julian already wrote a makeref.py based translator. I hope to using his reST version of the Pygame doc sources as a guide for a translator that produces reST files closer to the final product. If nothing else, makeref.py will generate somewhat cleaner web pages. Before going any further I need to know what to keep from the current Pygame document layout, what should change, and what can be added. I suppose this has been discussed before, but I kind of missed it. Also, if there are objections to moving to reST now is the time to raise them. Lenard Lindstrom
Re: [pygame] Inconsistency in online docs
Hi, Am 01.03.2011 18:44, schrieb Lenard Lindstrom: Personally, I am considering translating them to reStructuredText or something. That's exactly what I did quite a while ago: https://bitbucket.org/schlangen/pygame-docs/ The aim was to include it here: http://pygameweb.no-ip.org/docs/ (Of course there are no comments either, etc.) I had no time (and motivation) to update and improve the rst docs, but if you like it feel free to use it as starting point. Am 01.03.2011 19:30, schrieb David Burton: What's the download location for the .doc files, from which the .html is compiled, and to which mailing list should improvements be submitted? The .doc files come with python source code (see pygame website - download), the mailing list is this one. Also, what is used to compile those .doc files? I _like_ it! I've never seen such nice, simple, clean HTML come from a Microsoft Word document!! When Word, itself, generates the html from a .doc file (or when OpenOffice Writer or Wordpad does), the result is an ugly mess. It's no Microsoft Word at all. The .doc files are simple text files with some own very simple markup format. You can open and edit them with an text editor (unfortunately there is no documentation about the format, imo). There is a convertscript (makeref.py, basic html skeleton, style and everything is hardcoded there) to gererate .html from .doc files. (I once rewrote that to generate rst from the .doc files). Regards, Julian
Re: [pygame] Mask problem
mask.outline(): Returns a list of points of the outline of the first object it comes across in a Mask (docs) - this method gives you all points that build the outline of an object on the mask. Thus, all these points are set on the mask. If you want to print all pixels of the mask, you need to loop over the size: w, h = mask.get_size() for x in xrange(w): for y in xrange(h): print mask.get_at(x,y), print #(optional) Julian Hi all: I have missunderstand something from masks, this is my problem: I have a program that rounds frames in a minimum rects and saves the coordinates of them in a file, that way I know where, in a picture, are the frames of a animation and can get them easily. I took all the frames of an animation in this way (been an animation the secuence of images of p.e. a spaceship images turning in Y-axis to go left or rigth in X-axis) # Gets all the frames of a animation from the image def __getFrameImages__(self, image, imagesIndexInY, coords): indexes = coords.getCoordsInY(imagesIndexInY) # This works fine, the images are getted and drawed well for index in indexes: # Only to show that I get many subsurfaces from a big surface (a .bmp file) self.images += [image.subsurface(index)] After take all images I make masks for each image that way: # Makes masks for all the frames def __makeMasks__(self): for image in self.images: mask = pygame.mask.from_surface(image, consts.MAGENTA) temp = # LOG for x in mask.outline(): # LOG temp += `mask.get_at(x)` # LOG print `temp` #LOG self.masks += [mask] been consts.MAGENTA = 0xFF00FF the key color of the image. Well, when running it, the output are allways that way: '' So I undestand that, been no 0's, the mask is all the rect... so I'm doing something wrong, any ideas? -- Nota: Tildes omitidas para evitar incompatibilidades. :wq
Re: [pygame] gsoc: pygamedraw - status update
Lorenz Quack wrote: Hey, I have to agree with the other comments. it's really looking good so far! Thanks. On 06/17/2010 06:05 PM, jug wrote: Hello, I'd like to give you a short status report of the pygamedraw gsoc project. I've implemented the main class structure and basic drawing methods, so its already usable: [...] If you have any ideas for further Pen classes please tell me. [...] Regards, Julian I just thought that it *might* be useful to have an attribute style or something like that which can be set to SOLID, DOTTED or DASHED in analogy to the css attribute border-style [1]. I don't think this is a top priority item but might be nice to have. keep up the good work //Lorenz [1] http://www.tizag.com/cssT/border.php Yes, I also had this idea of line styles or some kind of orientation that could be passed to the drawing algorithm but this is not that easy due to the generic implementation via masks. However its on my ideas that would be cool to have and may be implemented later if I have some time left-list :) Luke Paireepinart wrote: Hey, I'm in need of some fast drawing functions that can correctly paint brush strokes... eg. if I draw a series of points 1px apart,with alpha, is it going to look like a bunch of overlapping circles, or is it going to look like a thick line of the correct alpha value? By default it will look like a bunch of overlapping circles as this is the normally expected behavior. However you could prevent this by activating multi-part drawing. This means, that the (mask of the) last drawn shape is removed from the (mask of the) next shape. (note that this is not completely implemented yet.) Also, these are implemented in pure Python? How fast are they? do they do a lot of work in Python or is most of it done in existing SDL code or something? Currently its all done in pure Python. Since this is a rewrite of the current modules that are only wrappers around the SDL functions I do not use any SDL drawing routines. This is why it is not fast at all now, but its just a prototyping and we plan to port the critical parts to C at the end. And how can I test this out? Do I just install Pygame Reloaded and then add this to my project folder and import it? Yes. You need pygame2 installed and the lib folder in the pygamedraw project dir on your python part. Then you can do from lib.solidpen import SolidPen and so on. Have a look at the example at ./examples/allinone.py. Regards, Julian
[pygame] gsoc: pygamedraw - status update
Hello, I'd like to give you a short status report of the pygamedraw gsoc project. I've implemented the main class structure and basic drawing methods, so its already usable: # ... red = pygame2.Color(200, 0, 0) blue = pygame2.Color(0, 0, 200) my_pen = SolidPen(color=red) my_pen.width = 6 rect1 = pygame2.Rect(20, 60, 200, 150) my_pen.width = 1 my_pen.ellipse(screen, rect1) rect2 = pygame2.Rect(30, 20, 50, 80) my_pen.ellipse(screen, rect2, start=30, stop=250) my_pen.color = blue my_pen.fill = True my_pen.cirlce(screen, (150, 170), 60, stop=90) my_pen.fill = False points = [(20, 50), (60, 10), (70, 80)] my_pen.line(screen, points, closed=True) # ... This should be mostly self-explanatory. In comparison to the current draw module(s) you will notice that it is object oriented! Draw functions on module level are replaced by draw methods on class level. This is the main change that brings along some advantages and changes: 1.) possibility of inheritance This is a great new feature that allows it to manipulate the way of drawing without touching any shape algorithms. These are implemented in the Pen base class and work on a mask as intermediate. This mask is then passed to the Pen.render() method that does some preparation and then calls the Pen.draw() method that implements the actual drawing. So you just need to subclass Pen and overwrite one method (namely Pen.draw()) and have a completely new drawing behavior for all shapes. Of course there will be some default Pens that already implement the most common drawing methods. There are some screen shots of already implemented Pens at my blog: http://pygamedraw.wordpress.com/2010/06/02/from-mask-to-surface/ If you have any ideas for further Pen classes please tell me. 2.) shorter parameter lists Having a Pen object allows it to store general parameters as class attributes, so drawing methods take only a minimum of parameters. However, I plan to add a way to set these class attributes on method class, so if you don't like to write my_pen.width=1/2/... all the time, you could set it directly on method call (like with the current pygame.draw module): my_pen.rect(surf, rect, width=2). 3.) cleaner code I think this makes the code cleaner, more structured and more pythonic. A more complex example is included with the sourcecode: http://bitbucket.org/schlangen/pygamedraw/get/2c2c8b815137.zip or hg clone http://bitbucket.org/schlangen/pygamedraw Regards, Julian
Re: [pygame] poll: GUI library advice / current GUI info ( for wiki )
Hi jake, 1] What libraries do you use most? The first pygame gui I used was gooepy but I think it was a bit buggy and inflexible. Then I tried spg (the first version) which was quite cool but the code was very unpythonic and thus very hard to hack and extend eg. to write new widgets. After some time of not using pygame guis I needed one again and thought to write my own small and easy-to-use gui. As nearly always if you plan to write your own small and easy version of a complicated and complex module X I wrote my own quite complex pygame gui. But I hope that it is less complicated than others. However, it's still in (more or less) active development and not yet released (there is just a public svn repo at http://tinyurl.com/33oe6xu ) so I'm currently the only user and haven't got any feedback from normal users yet. 2] Advantages to that library, over others? ( Special notes, ie: good with X. GooeyPy uses CSS, etc...) The 4 most important aspects: - flexible measurements: Any positions and sizes can be absolute or relative or mixed (eg. 20%+30px). This allows more flexible layouts since resizing the pygame window won't crash your gui. - flexible styling: Styling can (but don't have to) be done completely distinct from the widgets and changed all the time (i.e. you can change the entire appearance of your gui on runtime). Since styles are cached only widgets with a changed style will be redrawn. The use of pre- and suffixes makes it easy to define different styles for different states (like mouse-over, ...). - flexible event system: All kinds of callbacks, notifications, etc. are done via events (of an own event system, no pygame user-events are needed). Its easy to send and listen to events and implement any communication this way. - flexible widget system: Since game UIs may be very individual and game specific its very important to provide an easy way to write new widgets. Thanks to the first three features own widget classes often consist of just a few lines. 3] Disadvantages of those libraries? ( Special notes, ie: hard with X) The pygame guis I have used were mostly widget sets but no guis. They provide a set of widgets with styling options (using a (kinda inflexible) predefined image set) but no (or a very limited) geometry manager and no easy way to extend them and write own widgets. 4] Recommended games to view for examples? I've used it for two of my projects recently: http://tinyurl.com/3ycqe6z 5] Any changes to be aware of in pygreloaded , or already exist that is relevant for GUIs? Hu? pygame2 != pygame. pygame2 has another api and thus guis (and programs/libs in general) for pygame won't run with pygame2. 7] Anything else? Pygame (g)uis is a difficult topic. I think lots of people here have their own (mostly private) pygame-utils package and use it to build a new gui for every game. I know of at least two other guys who started working on their own (generic) gui or ui-helper lib. So, the ultimate pygame gui is yet to be written. Regards, Julian
[pygame] GSoC 2010: A New Draw Module
Hello! I'm going to write a new draw module for pygame and pygame2 as part of GSoC this year. The aim is to have one draw module for pygame that implements not only the very basic drawing of a few plain color shapes but also drawing of more advanced shapes and whith more advanced attributes (ie. curves, rounded corners, aa, etc.) as well as alternative filling methods (ie. procedural or image based textures, filling from another surface/image (cloning), etc.). Unlike now the code will be object oriented thus you'll need to create a (pen) object before using it to draw stuff. That is to to keep code clean and structured and avoid functions with (terribly) long parameter lists. However, I plan to add some shortcuts for basic functionality (and maybe compatibility). I'm still thinking about concepts and have some more vague ideas in mind so if you have any ideas or suggestions please tell me :) While development I'll blog about any progress at http://pygamedraw.wordpress.com/ Even though I've got svn access to the pygame repo (thank you, rene) I also have a (currently still empty) hg repo with wiki and issue tracker at http://bitbucket.org/schlangen/pygamedraw Regards, Julian
Re: [pygame] GSoC project proposal: A new draw module
Marcus von Appen wrote: What would be interesting here is, what the Pen class would offer except from the drawing functions wrapped up in a class and som additional shapes. What about e.g. an aa-property to keep the argument amount low, transformation and rotation angles for the x- and y-axis (implicit transformation done upon drawing) or even vector support (e.g. for faster 2d, 2.5d, 3d operations on the shapes) using the math module? What do you think about working out some basic Pen (and utility) class(es) as an example (no need to implement any function or property, just a stub of the class, we can examine and design)? Regards Marcus I've created a page with all ideas and concepts that everyone can (and should) edit or comment on: http://pexdra.wikidot.com/ Regards Julian
[pygame] GSoC project proposal: A new draw module
Hello, I'd like to rewrite/improve the pygame draw module(s) as a GSoC project. Currently, there are pygame.draw and pygame.gfxdraw, but both are not very usable. There is just a small set of basic shapes to draw. Another important point is the missing anti-aliasing. Well, the new gfxdraw has some aa-functions, but they are too inflexible. Lets say you need to draw a filled, anti-aliased circle. There is no function to do that, even though there are four (!) functions to draw some kind of circle. These functions can draw a circle either filled or anti-aliased (or not anti-aliased and not filled) but not both. The same applies to the other shapes. I made some small tests[1] and it was really easy to get some nice shapes[2]. Of course, the code is dirty and slow, but its just a test to get an idea of an usable draw module. To handle all these options and parameters, the code could be organized more object oriented. One idea was to handle it like PIL: mypen = pygame.draw.Pen(surface, ...) mypen.circle(pos, rad, ...) Then, shapes could not only be filled with plain color, but also pixel data from another surface or maybe some kind of texture or so. Just some first thoughts and rough ideas. Regards, Julian [1] http://bitbucket.org/schlangen/pexdra/ [2] http://bitbucket.org/schlangen/pexdra/src/tip/doc/source/images/simple_example.png#
Re: [pygame] Improving documentation
Yeah, nice, could be really helpful. Can we use these images or would you like to add them and help us? If you have a bitbucket account I'll give you write perms. -- Julian Horst JENS wrote: i love the graphic examples ! -Horst I like this idea, maybe we can put some visual examples like this page too: http://www.losersjuegos.com.ar/traducciones/pygame/transform
Re: [pygame] Pygame community platform?
Hi Olof, Olof Bjarnason wrote: I have this crazy idea of making a pygame community platform to make distributing/finding/testing/installing pygames simpler. Interesting idea. For end users, it would be a program to install, maybe called something like PygamePlatform. It would provide a graphical user interface, for the ubuntu platform to begin with, since that is what I'm using. It would feature search/install/uninstall/run interaction. What do you do with dependencies? Include them to your game source? Or add some often used 3rd party packages as extra projects? Installing would mean downloading .py+bin files and placing them in a PygamePlatform local games pool. Thus uninstalling is as easy as installing. Rene is working on something like this, but I think its more for bin files including python and all dependencies. So for people who do not know python etc. but want to play your games. Is that what you want to do or just making it easier for people with python to find and install pygame games? GUI: Much like Ubuntus add programs, combined with the start menu. A GUI wouldn't be a problem I think. The database of pygames would reside on some wiki-like web page, so pygame-developers could easily add their creations without any updates to the PygamePlatform-installations out there. Of course this is a great deal of work, but provided it does PygamePlatform could be ported to Windows, Mac etc. without any changes to the wiki-database or the games themselves. Depends on what existing tools and libs you use/ what you want to do You could also just write a wrapper for easy_install with a project filter/ own db with project names, a nice GUI and some additional game informations. Feedback? Is there earlier projects that has tried (and failed) doing this kind of thing? Well, there is a pygame community platform/website with project listing: http://pygameweb.no-ip.org/ Its still a beta/rc version, but it has an api (actually two: XMLRPC and REST, see the more-tab) that allows you to get some (maybe more soon) data about the projects. Currently you could use it for a check for updates/newer version inside your games/programs. It also gives you the download urls for bin and source files (if available). So if people would add their games to pypi and insert a game description and pypi-url/-name on the website, only the GUI would be left to do. Regards, Julian
[pygame] Improving documentation
Hello! Some months ago, there was a discussion about the documentation system of pygame (and it's output), but without any results. Some say its ugly (like the website), some say its a bit unclear, some may like it. Some parts could definitively be improved. Then, there is this comment system inside the documentation with some very useful comments that are essential for understanding (ie. the docs are incomplete there) but also lots of comments with spam, useless content or really large examples that may be useful but should not belong to documentation (better in the wiki or pcr or snippets section or so). Another point is, that the documentation is not portable. You can only build the docs as html pages in this ... green(?) style and without comments. In the earlier discussion, Marcus made a case for Sphinx, a tool also used for the python documentation. It has several advantages: - Its a standardized tool that uses reStructuredText, an easy but powerful markup language known by many python'ists (- easier for contributors) - It generates several formats like html or pdf from plain text files. That also makes it easy to mix api documentation with with deeper explanations. - It supports some kind of theming, ie. you can use one of a few default styles or even write your own one and/or edit/extend the templates. - It has a plugin system with some useful extensions That's why I (and some others) think that porting pygame documentation to Sphinx would be a good start to improve it. And thats what I did. http://bitbucket.org/schlangen/pygame-docs I've created a project on bitbucket, so everyone who'd like to participate can do that easily. I've already converted the docs to a Sphinx project, but it needs some manual control and cleanup and then content improvements. A small preview how it *could* look can be found here (using a default style - as I said, you can change this style nearly completely): http://pygameweb.no-ip.org/media2/newdoc/api/rect.html (This page is manually converted, the other pages are build with a modified version of makeref.py) Regards, Julian
Re: [pygame] Re: Announce: PygWeb2.0rc
B W wrote: I like the aesthetics of your redesign, and the layout is very friendly. Thanks. I'm curious to see if your conversion will fix HTML-wrapping issues like this: http://www.pygame.org/wiki/2DVectorClass. And whether project screenshots will be ported and the default N/A images will be replaced. I don't see any errors there. Since the pygame developers who run pygame.org are not interested in the website, it will (probably) run as a individual website, independent of pygame.org (if anyone is interested, email me). In this case, it will not migrate any data from pygame.org. We did not migrate screenshots for the demo cause its just a lot of data (of course it would be possible). One content-related feedback. This occurs on the following converted snippet from the Pygame Code Repository. http://pygameweb.no-ip.org/snippets/28/ The original distribution bundles files critical to the code's function. While your converstion exposes the code for convenient viewing--a very nice touch--it seems to have lost the other components: an image file, and POV files if anyone should want to dig into the 3D image with POV. I predict this would be a frustrating discovery for anyone wishing to see the code in action. I do not know how many are like this, but I'm sure you would want to follow up on it, in the spirit of insuring converted content is either unchanged or improved. :) There are a few snippets that have additional data like images or extra files with it. Normally, Snippets (on pygWeb) are just code and maybe some explanatory text. Thus, migrating additional files it not possible (when using a converter script). Of course these extra data may be important. Not for the demo, but for a productive usage. The problem is, that there is no option for normal users to attach any files to snippets (which is, I think, basically appropriate). So these snippets either have to work without additional data or host this data somewhere else and link to it or use the wiki that allows attachments (but is not meant for code hosting). Devon Scott-Tunkin wrote: I can't remember right now if the code was using different templates than the rest of the site. Yes, the code tab is the one handled by Trac (with its own templates and style sheets). -- Julian
Re: [pygame] Re: Announce: PygWeb2.0rc
Hey, Thanks for the feedback. I have a suggestion: If you download a code snippet, it gets named like '49.py' or '55.py'. But a filename would be more useful, like 'ZoomScreen.py' instead of '55.py Good idea, I've changed that. if clicking on the code tab, the whol website recenter and has smaller width (1024) than before. you may have to test with high browser resolution I know that. Not yet sure whats better. The smaller, fixed width was the original style, but sometimes its not enough space for the entire content (logged in as admin or with very long user name). I only have one question; how is updating the new site different from the old? Is the Django site still serving most things from static pages and just using the database to store comments and such, or did they use one of the little CMS doo-dads available for use with Django? The site runs with an own database. Currently its sqlite, but since its done with Django, most other db backends should work as well. All content except the documentation is stored in the database. It's possible to convert data from the current pygame.org db, but you cannot use the same data or database without converting. The issue is some people felt Jug and the others went ahead without proper discussion before-hand. Some people wanted to rewrite the website as well, but not with Django. The discussion got nowhere fast, so we just started (otherwise, I think we would be still discussing). Also, those who wanted to write a website with other tools, did not do that (afaik). The same applies to the details. You cannot discuss every single detail on such a mailing list. Everyone has his own opinion, but you can only implement it one way. So we did it how we deemed it right and then showed it to the list so that everyone could have a look at it, test it, and tell us whether it is ok or he found any no-go's. -- Julian
[pygame] Announce: PygWeb2.0rc
Hello! We would like to announce we have finished working on the PygWeb website that was originally intended to replace the current site on pygame.org http://pygame.org. Although this caused some controversy and the maintainer(s) of pygame.org http://pygame.org did not seem interested, we kept working. We now have a fully functional website with the same basic functions provided by the current pygame.org http://pygame.org website, but also many new features: - a *real* user system with small profile pages, statistics, privacy settings and more - improved project management with intelligent tagging, uploading multiple screen shots, integrating youtube videos and a project of the month poll (as replacement for spotlight) - a snippets section that allows users to post small, useful snippets of source code that others may learn from or reuse. Its quite the same idea like the pygame code repository (pcr), but easier to manage and to use. It also supports tagging and bookmarking. - comments on nearly every content on the website, except for documentation and a few other pages - lots of feeds (Atom RSS), eg. for all new projects, new releases of either one special project or all projects, news, project of the month, ... - subscriptions for most content with feeds, ie. you could get a mail on every new release of your favorite game or on pygame news - full text search: Search in some subsections or the whole site - consistent markup support including most common markup languages like reStructuredText, Markdown, Textile, Creole, bbCode (its very easy to add one) for all formatted text. All text edit fields have an preview option. - timezone localization, even for anonymous users (the latter needs js) - a shiny, modern style and an option to add more styles and every user can use the style he likes best (more styles are yet to be written) - apis to access data programmatically: XML-RPC, for simple read requests, and REST, for enlarged read and write requests. A small example of use could be a check for newer version option in your game or even a possibility to directly download the new version - enclosed irc bot with some useful commands (some use the website database) and an optional announcer feature (eg. announce news or even new releases) - integrated Trac that provides a wiki, bug tracer, svn browser, plugin system (with lots of plugins out there) and more - full admin interface with some nice and useful features to administer the site easily - lots of configuration settings to change specific behavior (but with good default values) Our site is open source and if someone would like to host it we will support it and help in getting it setup. We would, of course, like to see it on pygame.org http://pygame.org, but that's up to the owner of pygame.org http://pygame.org or the community. The demo site sill runs at http://pygameweb.no-ip.org/ . There is already some data from pygame.org http://pygame.org for seriously testing content and also to show that we could successfully migrate data. The irc bot can be tested in #pygame on freenode. Just write b0t help to get a list of available commands. Besides looking for a host for the site, we would like to get some more testers and feedback. There may still be some bugs or details that could be improved. If you want a shiny, modern, new website representing your favorite python game library, get in touch! It's up to you! Regards, Julian and Devon
[pygame] Rect.contains - bug or feature?
import pygame r1 = pygame.Rect(0, 0, 100, 100) r2 = pygame.Rect(50, 50, 0, 0) r1.contains(r2) 1 r3 = pygame.Rect(50, 50, 50, 50) r1.contains(r3) 1 r4 = pygame.Rect(100, 100, 0, 0) r1.contains(r4) 0 I would expect a 1 in the last line as well. Julian
Re: [pygame] Rect.contains - bug or feature?
Hm, but than, r1.bottomright should be (99, 99) and not (100, 100)!? Or is topleft inside and bottomright outside the rect? Julian Lorenz Quack wrote: Hi Julian jug wrote: import pygame r1 = pygame.Rect(0, 0, 100, 100) r2 = pygame.Rect(50, 50, 0, 0) r1.contains(r2) 1 r3 = pygame.Rect(50, 50, 50, 50) r1.contains(r3) 1 r4 = pygame.Rect(100, 100, 0, 0) r1.contains(r4) 0 I would expect a 1 in the last line as well. I wouldn't. r1 starts at position (0,0) and has a width and height of 100 each meaning is goes from 0,0 to 99, 99 which amounts to 100 pixels in each direction. r4 lies just outside of that. Note that the arguments to Rect aren't start and end position but rather x,y,w,h yours //Lorenz
Re: [pygame] Rect.contains - bug or feature?
Luke Paireepinart wrote: On Thu, Oct 22, 2009 at 4:44 PM, jug j...@fantasymail.de mailto:j...@fantasymail.de wrote: Hm, but than, r1.bottomright should be (99, 99) and not (100, 100)!? Or is topleft inside and bottomright outside the rect? Yep, I think it says this in the docs. Agreed. Thanks for the resolution. Julian
Re: [pygame] how to remove spam comments in pygame wiki
Lorenz Quack wrote: But I do think captchas are fine if they help reduce the spam. I'm not sure about this. Some of the spam comments seem to be from bots, but there are (were?) a lot of comments like hgjnyhh. I don't think they are from bots. Then, there are comments posting complete example programs then a few criticizing that program or asking for help for their programming problems. (eg. comments of Font.render). So, thats not spam, but I think they should go elsewhere. It's interesting how to get 'truly' transparent text, but that should be posted in a wiki or snippets or cookbook or howewer you call it. Maybe you could add a comment with a link to that snippet post (if links would work). If you allow comments for anonymous on docs or elsewhere, you have to care for it. So, remove spam directly, add comments that should be included to the docs directly (or mark them, so its easier to find them later). Maybe find someone who could help there and give him restricted rights for these jobs. Another way would be to call it not add comment but suggest improvement, and to add some functions to easily manage it. A suggested improvement would be checked by some admin or moderator and then either marked as accepted (- will be displayed like a comment until included to the docs) or not accepted (- could stay for a while on an extra side so users could write it to the wiki or so). Spam would be directly deleted. I think there aren't so many new comments per month and if people know what happens with their suggestions, they'd post example programs directly elsewhere. That would keep the docs clean, but is a bit more work and won't be to everyone's liking. And if using captchas, don't take those with images noone can read. Take something like what is 2+5? or so. As long as the bots don't know this format, it will be fine. The questions are: - Should all comments be deleted or included to the docs some day? - Should the docs just be an api reference or more? Julian
Re: [pygame] how to remove spam comments in pygame wiki
Hi Brian, Brian Fisher wrote: On Wed, Jul 29, 2009 at 11:55 AM, jug j...@fantasymail.de mailto:j...@fantasymail.de wrote: Yeah, sorry. It uses simple text files with an own simple structure and markup. So, it's not as bad as I thought. But still bad. IMHO, bad enough to be replaced. It *is* something self-made, the html and css is *hardcoded* into the generator script and therefore it *is* impossible to change easily. Finally, the output *is* ugly and *invalid* (http://validator.w3.org/check?uri=http%3A%2F%2Fwww.pygame.org%2Fdocs%2Fref%2Fsurface.html). However, after some trial and error and some changes on the generator code, I got the docs integrated into the website (used code from svn, so docs are for pygame 1.9.0): http://pygameweb.no-ip.org/docs/ So, if no one is interested in a more professional documentation system, we should at least update the generator script to produce some more valid code, use a simple template for html and css and become a bit more configurable. Julian, good job on working with current documentation content to get a page working. However I have to say that I do not find this page: http://pygameweb.no-ip.org/docs/ to be any improvement at all over this page: http://www.pygame.org/docs/ I don't think the aesthetics or usability have been improved. But my real critique of it is that you dropped what I considered to be a highly effective and useful format for documentation - to have single page docs for a module, where the top half of the page is functions for the module that links down to the dull description later on the same page. The problem is that with your main page being a list of all modules and their functions together, it's hard to get a good overview of the modules compared to a list of each module with short descriptions. Likewise, once I've decided a module is for me, and choose to go to it's page to drill into it, I don't get a clear and simple overview of that module. I hope the doc pages are something you continue to improve from the perspective of easily getting overviews of things and getting a high level picture of what the library has to offer. And lest you think I'm biased, I didn't do a single thing to work on the current pygame website or doc system, and have no particular love of the current website. I just happen to have had a really great experience working with pygame's website doc pages over the years - it's always been a lovely experience to browse them for me because it's so easy to get a high level picture and find what I want. I find them to be far more usable and effective than python's own doc web pages, which are at times overwhelming and impossible to get a good high level view from (like say the urllib firends docs for instance - where you don't even know what classes or modules you want to use, and once you do have a guess at that, it's hard to find a useful function). Indeed, the docs at pygameweb are not better than the ones on pygame.org. I just had a look into the generator script and modified it to produce templates I can use with the rest of the website (so that the recent-releases and the menubar are still there). Then, its valid XHTML 1.0 Strict. Surely it needs more improvements. I'll try to get the index page clearer, for the rest, I don't know yet. Eg. http://pygameweb.no-ip.org/docs/surface.html ist not really easy to read, but I don't know exactly why. Feel free to help improving it.
Re: [pygame] how to remove spam comments in pygame wiki
Hello, René Dudfield wrote: On Tue, Jul 28, 2009 at 8:39 PM, jug j...@fantasymail.de mailto:j...@fantasymail.de wrote: Hello, We are still working on the pygame website rewrite. I'm currently implementing a snippets app that should replace the cookbook section in the wiki. The code is handled as code, apart from the description. Thus, you can download the snippets directly as .py file. Then, its easier for everyone (who has an account) to add new snippets, to find useful snippets and to remember them. There's a cook book and code search for this now. This searches the 1000s of projects on the internet for each use. It's much better than a snippet section you decided on. Well, I can add a google search, too, but seaching is not the main point here. A wiki is not designed to manage code snippets. Surely its possible, you could even manage projects in a wiki, just give each an own page. In my opinion, a snippets app is more user-friendly. You have one snippet, one description text and one author. If someone has a good tip, he should be mentioned when sharing it with the community. Users can review the code and tell in a comment if it helped them or not, if there is something to improve etc. I know, it may be new to you and not convince you directly, but while development, I got a lot of useful tips and snippets from http://www.djangosnippets.org/. General tips, tutorials or other stuff can still be handled in the wiki. Since comments will be reserved for registered users, number of spam comments and other waste content should decrease a lot. For the rest, we may have something like mark as spam buttons, so you can tell the site admins directly if you notice any spam. why do you get to decide this? Many of the valid comments are made without login, those would not exist if it required a login. Well, I discussed that with Marcus. I think that there will be more users with an account (or more users, that actually already have an account, will login) if there is more than just projects. Currently, you just login if you want to edit a project, a wiki page or comment on a project. And you get automatically logged-out. On the new site, its more worthwhile to log in, and you can stay logged-in longer, if you don't log out. So most active pygame users should have and account and it's really easy, you just need a valid email address. But besides that, to open comments for anonymous wouldn't be difficult either. Documentation is another problem. I think, with the website rewrite, also the docs should modernized. AFAIK, The current system is something self-made that uses documentation thats already written in html. It blends htms and stlyle to one html file, so it is quite impossible to change the style or to include it to the rest of the site. I don't know how the comments work, but it looks not good. As well, it would be better to have some kind of api access or at least methodical urls to access documentation programmatically form the rest of the site, the apis or even the attached irc bot. You're completely wrong about the documentation system. I suggest you actually read it before commenting on it. Yeah, sorry. It uses simple text files with an own simple structure and markup. So, it's not as bad as I thought. But still bad. IMHO, bad enough to be replaced. It *is* something self-made, the html and css is *hardcoded* into the generator script and therefore it *is* impossible to change easily. Finally, the output *is* ugly and *invalid* (http://validator.w3.org/check?uri=http%3A%2F%2Fwww.pygame.org%2Fdocs%2Fref%2Fsurface.html). However, after some trial and error and some changes on the generator code, I got the docs integrated into the website (used code from svn, so docs are for pygame 1.9.0): http://pygameweb.no-ip.org/docs/ So, if no one is interested in a more professional documentation system, we should at least update the generator script to produce some more valid code, use a simple template for html and css and become a bit more configurable. I don't know about all the possible documentation systems and generators, but sphinx[1] may be adequate. Further on, I'm not sure if documentation should include comments. I think it would be better to use the snippets section to show really useful code snippets (we could link against them from the online docs) and for other stuff the wiki. If there is really sth. missing in the docs, it should be added to them, so also users who download the docs an read it offline should see these additions. Next (maybe pre-final) testing phase will come soon, including the new snippets app and much more. The comments section is staying. Why do you get to decide this (alone and without argumentation)? I admit, some comments in the docs are really helpful
Re: [pygame] how to remove spam comments in pygame wiki
Hello, We are still working on the pygame website rewrite. I'm currently implementing a snippets app that should replace the cookbook section in the wiki. The code is handled as code, apart from the description. Thus, you can download the snippets directly as .py file. Then, its easier for everyone (who has an account) to add new snippets, to find useful snippets and to remember them. Since comments will be reserved for registered users, number of spam comments and other waste content should decrease a lot. For the rest, we may have something like mark as spam buttons, so you can tell the site admins directly if you notice any spam. Documentation is another problem. I think, with the website rewrite, also the docs should modernized. AFAIK, The current system is something self-made that uses documentation thats already written in html. It blends htms and stlyle to one html file, so it is quite impossible to change the style or to include it to the rest of the site. I don't know how the comments work, but it looks not good. As well, it would be better to have some kind of api access or at least methodical urls to access documentation programmatically form the rest of the site, the apis or even the attached irc bot. I don't know about all the possible documentation systems and generators, but sphinx[1] may be adequate. Further on, I'm not sure if documentation should include comments. I think it would be better to use the snippets section to show really useful code snippets (we could link against them from the online docs) and for other stuff the wiki. If there is really sth. missing in the docs, it should be added to them, so also users who download the docs an read it offline should see these additions. Next (maybe pre-final) testing phase will come soon, including the new snippets app and much more. Regards Julian [1] http://sphinx.pocoo.org/ Paulo Silva wrote: otherwise, it's extremelly important Pygame being plenty of small snippets, and having them on places like wiki or www.pygame.org/docs/ is extremelly important, specially for newbies like me On 7/27/09, Paulo Silva nitrofur...@gmail.com wrote: i don't know... maybe Pete Shinners? On 7/27/09, Horst JENS horst.j...@chello.at wrote: Am Sonntag, den 26.07.2009, 22:06 +0100 schrieb Paulo Silva: would be great if we can notify them for the administrator removing them - if we allow anyone to remove everything, the same spammers may wish to remove very useful information we waste our precious time on posting them... who is the official wiki admin to notify ? -Horst -- Horst JENS horst.j...@chello.at http://members.chello.at/horst.jens
Re: [pygame] Extending Surface Class
You have to call pygame.Surface.__init__ with your surface object first (self), then pass further arguments like size: class ExtendedSurface(pygame.Surface): def __init__(self, string): pygame.Surface.__init__(self, (100, 100)) self.fill((220,22,22)) # ... ERName wrote: Is it possible to extend the surface class? Every time I do the surface ends up dieing somehow right after it is created... I may just be doing it in the wrong way, though. The main point is to override the __str__() method, so if you know another way besides extending pygame.Surface, I'd be happy to hear it. class ExtendedSurface(pygame.Surface): def __init__(self, surface, string): pygame.Surface.__init__(surface, surface.get_size()) #The docs say to include a size, etc. but that just gives me too many values to unpack errors. self.string = string def __str__(self): return self.string Thanks!
Re: [pygame] status report
el lauwer wrote: Hoi, I like the new logo, and it seems to work ok. I would however try to use a lot less green, I think you should try something like the archlinux site http://www.archlinux.org/ Well, it's a matter of taste. Our target is to get different styles for the site. Than, we could vote a default style and registered users can change that in their profile settings. The current design came up from the first version, that was more a retro style with even more green. Then, Devon improved it a lot and got the current, thats more a modern theme. A more simple style thats works also fine on older and/or slower browsers/computers/connections is planned.
[pygame] status report
Hello, Time marches on, so some words about the current state of affairs. First, I've to say that Orcun unfortunately is not any longer in our team. Then, a slightly more delightful point, we are near at the finish! Only some minor points and improvements are left, then we can start a final testing period. Points left to do: Devon: * Complete the modern design before starting with a new one * finish form design * design administrative links like buttons (edit project, release.., ...) * ticket #5 * ... * update the trac theme to fit the current design (maybe ask coderanger at #pygame to help you, he did the current desgin plugin) Marcus: * get the current db and help to write convert scripts * convince the rest of the pygame core team * review templates * test the website, its features, admin functionality, etc. * help me with ordering/collecting ToDos and design decisions Julian: * well, I've to do everything else :-) I'll collect the hangover from my various ToDo lists and bring it to the wiki page. I also made a features list: http://pygameweb.no-ip.org/trac/wiki/Features In case I've forgotten anything please add it to this list. I hope to complete this project soon and see it running on pygame.org Regards, Julian
Re: [pygame] pygweb milestone 1 released
Hi Nirav One thing I would suggest is having some kind of navigation from the Trac parts of the site back into the Django parts of the site. A header bar perhaps, or even integrating the trac part into the rest of the site like http://edgewall.org or http://djangoproject.com do. Sure. Trac is not yet really integrated. Its just running at /dev/ and uses same user accounts. We concentrated on main website first, to get the projects system running etc. Also, we are more or less inexperienced with customizing Trac. So if someone here knows Trac a bit better, please answer! The registration confirmation email that gets sent has a broken url. It is missing the / after the domain. Oh, that's right. I'll fix it with next commit.
Re: [pygame] pygweb milestone 1 released
Hi Noah, Noah Kantrowitz wrote: I would say I fit that bill. Let me know if there is something you need poked with a stick. We need a custom template and style to fit Trac into the rest of the page. Then we have to care about configuration, plugins, etc. Do you know if it is possible to use Trac WikiFormatting outside Trac? It would be cool to have that also on the Django site so we had one markup on the whole site with all the Trac specific markup like wiki and ticket links. Julian
Re: [pygame] pygweb milestone 1 released
Noah Kantrowitz wrote: Look at http://trac.edgewall.org/wiki/TracInterfaceCustomization for information on basic customization. If you end up needing more than that I can explain how to write a full theme replacement. I thought you wanted to do that because you already know how it works. After reading the docs, some /trial and error we may manage that, but we have enough to do before. / As for plugins, check out trac-hacks.org. Sure, I already had a look at it and bookmarked some plugins that may be useful for us. Making a Django filter for Trac markup probably wouldn't be too too hard. Are you running both in the same interpreter? The same interpreter? On the testing installation both run over (their own) cgi. I think we can use formatter.format_to_html (http://trac.edgewall.org/browser/tags/trac-0.11.4/trac/wiki/formatter.py#L1109) but I don't know what the arguments are (context, wikidom). Julian
Re: [pygame] pygame website - the non-Django team.
Hi, The coding on the django based website started without discussion finishing. There was a discussion with some different view points, and you just didn't seem to care and began the website, ignoring them anyway. Then I didn't have any option but to start a website myself. Well, there was no progress in discussion any more. And why do you have to start an own project when we start? Do you think Django is rubbish or why can't you just let us (keen students) do our project even if its not part of GSoC? Do you have to give proof of sth.? Do you have nothing better to do (like me :))? I think, we've got to a pretty nice intermediate, so why do you have to start a competitive project instead of helping us with testing, design, Trac etc. so we get one perfect website that all back and not 2 good ones and so. has to decide who's work will be appreciated and who's not. I told you in other threads I was making one, and that there had been a plan to make one since January. Again, neither you or jug responded. http://groups.google.com/group/pygame-mirror-on-google-groups/browse_thread/thread/fedcce866a7725fc/e4dfb2854a5013a1?lnk=gstq=website#e4dfb2854a5013a1 http://groups.google.com/group/pygame-mirror-on-google-groups/browse_thread/thread/fedcce866a7725fc/e4dfb2854a5013a1?lnk=gstq=website#e4dfb2854a5013a1 If it was so clear that you will write the website since January, why was it a point on GSoC list and why don't you have already started? (Would you write your own page even if it was a GSoC project? What's the difference now?) And since we used the pygame svn repo at google and the at the beginning introduced webiste/Trac everyone could always notice what we were doing and we don't come back from nowhere surprisingly. We telled your our plans and did that thus far whereas it's a bit curious to me that you check in your competitive product just a few hours after our fist preview release. Julian
[pygame] Pygame Website Rewrite: First alpha version ready for testing
Hello, A first version of the rewritten pygame.org website is ready for testing: http://pygameweb.no-ip.org/ Main focus is on project management and user system. News are also yet available. Feel free to register or log in with guest/guest, create and edit projects, releases, screenshots and your profile or vote the (dummy-)project of the month. Devon is still working on the design and often changes it. For development organization we use Trac and a mailing list at google groups. More information at http://pygameweb.no-ip.org/trac/wiki/. If you spot any bugs or have an idea for this first version thats not already on our ToDo list (http://pygameweb.no-ip.org/trac/wiki/ToDo) create a ticket. There was a problem with email and Trac, but now, all registration and email stuff should work. Regards, Julian
Re: [SPAM: 3.500] Re: [pygame] This one baffles me
I think you forgot the newline: .replace(\n+ *4, \n\t)
[pygame] starting the rewrite
Hello, Today, I started to write some first lines of code for the new pygame.org website and just checked it into SVN. For further questions I'd like to create tickets in the development-trac (and maybe write here a mail with a link). We are still searching for a web-designer, so please help us. Over again, please write your name to the list there if you'd like to participate. Regards Julian
Re: [pygame] PyGame Website Rewrite
Hi, using Trac with google SVN is not directly provided, but could be done. You need to mirror the repo on the server where Trac is running on. Because you have no access to SVN-hook scripts at google it's a bit tricky. Have a look at http://rc98.net/googsvnsync. I'm not a SVN expert so who could undertake this? We are still waiting for the current database structure, but I think it will be possible to import old wiki data. At http://trac-hacks.org/wiki/script are some scripts to import wiki data from other wikis (eg. MoinToTrac). I think we could write an equal script. - Jug
Re: [pygame] PyGame Website Rewrite
Hi, I just got the DjangoAuthIntegration (1) Trac plugin working. With this plugin, you can login to Django, go to Trac and are logged in (without reentering username and password). After logging out at Django, you are logged out with Trac, too. Thats really cool. Now need some testing. -Jug (1) http://trac-hacks.org/wiki/DjangoAuthIntegration
Re: [pygame] PyGame Website Rewrite
Hello, I'm kinda amazed about some points: 1) Did anyone read my concept? Some of the discussed ideas here I had before but no one cared. 2) I created a trac an you said nice! and created a Google project. 3) This project was an gsoc candidate and AFAIK all applicants wanted to use Django. At least 2 of them (Orcun and me) would like to do it even without google. Now you say let's do it with cherrypy because you don't know Django. Hm. I my view, both - Django and cherrypy - are mighty enough for our needs, thus its a relig. question of faith. But you asked so to do it. So, here we are! We have time and (only) want to do it with Django, cause we don't know cherrypy as you don't know Django. Maybe here are some php-experts why do it with php? 4) Even if you don't know Django, you can participate by helping to develop the concept, writing specific requirements, care about design, read the old code, transfer it and write new templates (Django templates are really easy to learn). If we use Trac the way things are going, there will be some work on adapting it by editing the Trac templates and style to make it fit into the whole page. Then, care about plugins that could be useful or necessary (auth, notification, feeds, irc-announcer, ...). Be sure you can help us even when using Django for the backend. Regards Jug PS, well, I'm a slow writer, so I agree with Marcus.
Re: [pygame] PyGame Website Rewrite
There's one problem remaining. One of the few weaknesses of Django is that it does not support subdomains. Thus, pygame.org/dev would be much easier to handle. To concretize, please specify the structure again. What would Trac be used for? Replace the current wiki and add a ticket system for bug-tracing and more (enhancements, etc)? So, the rough structure would be Django - News - Flatpages - Projects Trac - Wiki - Ticket system - code browser - (maybe more?) I'm going to test the django-trac thing today. If we use now my Trac please try to keep the concept up to date and edit it with our discussion results. - Jug http://www.dict.cc/englisch-deutsch/weakness.html
Re: [pygame] Re: PyGame Website Rewrite
Hi # need a numeric version? or save it as string? version = models.FloatField() the version should be a string beceause it allows for different kind of version formats like 1.0.4 Right! I thought of sorting but sorting different projects by version is rubbish. Better by last update or so. I've just changed that ;)
Re: [pygame] PyGame Website Rewrite
Hi, Analyzing the current page in detail is a good aspect to exchange the site without any problems. Do we need to run and modify the current page or is enough to read the code? Then you could send it to me and I'll upload it to the page (I think we don't need it in SVN, do we?). Sure, we could do that at google code but first I think, Tracs better (and looks nicer) for developing with the community and then we could run the new website from SVM there so everyone can always have a look at the latest version and test it. And you normally don't get an confirmation email. Just register and login. Regards Jug
Re: [pygame] PyGame Website Rewrite
Have a look at http://pygameweb.no-ip.org/trac/wiki/Concept Most of your points are already listed there. Add new ones so we get an overview. Jug
Re: [pygame] PyGame Website Rewrite
Hello, to organize the development process, I've set up a SVN-repo and a small Trac at http://pygameweb.no-ip.org/trac/ You'll find there a first concept and you can take part in developing it by adding your ideas. Some of the point are completely to work out, so just have a look. If you have a complete concept for one of the points (eg the design) create a new wiki page and add a link. If you would like to participate in developing, add yourself to the list on the start page and provide some information like I did. I've done the setup on the quick so if there are any problems with Trac or you need more rights, please email me. Regards, Jug
[pygame] PyGame Website Rewrite
Hello, Even if it was not selected as a project for GSoC, I would like to do the pygame website rewrite. Like the other applicants, I'd do that with Django. Now that there can not only be one student/participant, it would be cool to work together and combine forces. Since I applied for GSoC, I've already made a small concept. Merging multiple implementing-/design ideas may become difficult, but before I go into detail just say me if you are interested. Regards Jug
[pygame] Re: GSoC Proposal: Basic gui system
If you all think, a lot of people would use a built-in gui but it's not worth the work, is there a chance to put one of the existing guis into pygame? We could poll the users on the website and/or the mailing list about the best pygame gui. Then maybe have a look on the best 2 or 3, discuss some pros and cons and include one into pygame? Because as I said before, one big problem of all of the existing guis is that they are at least one more dependency. In addition, new users don't have to test all guis and find the best but can have a look at pygame.gui and invest more time to understand it. I'm really tired from reading up on guis (used 2 and began to read about Albow). A pygame.gui module would get much more support (bug fixes, new ideas/ widgets, etc.) than now, too. Regards, Jug
[pygame] GSoC Proposal: Basic gui system
Hi, I would really like to have a pygame.gui module. Many/all pygame programs need to have a user interface and often it's more than two buttons. Thats always the same and why always reinvent the wheel? There are some pygame guis but I neither like dependences nor I want to redistribute external modules. In addition, I haven't yet found the ultimate pygame gui (if there is one, include that). So, I think it would be cool to have a well thought out, easy extensible gui system within pygame including some basic elements like button, label, entry, etc. and a kind of geometry manager. Of course you can write that yourself every time you need it but (i think) its not fun but only waste of time. Regards Jug
[pygame] Re: GSoC Proposal: Basic gui system
On 21 Mrz., 16:48, Marcus von Appen m...@sysfault.org wrote: Which is why a GUI backend within pygame was never realised. There is no ultimate design approach and having just a bunch of abstract base classes for users to implement is not worth the work :-). Then it should be a GSoC task to search for it. Surely the existing GUIs (or some of them) are not completely useless, but some are not supported/developed any longer, some are in an pre-alpha stadium, some work fine but have defects in their concept so that extending/writing own widgets is very difficult. If you can find some good reasons, why that system would be better, easier and more extensible than all the solutions available, go ahead. Be aware however, that this will probably cause a lot of discussion about the pros and cons. If there were a pygame.gui module, it would be developed faster, programmers could help with posting new widgets they made and bugs and ideas could be handled faster. If you think it's too much work, call a vote, take the best pygame gui, put it into pygame and start helping to develop and improve it. But I think most of the work will be to think about an easy but powerful concept for a game gui. The implementing part should be less work and less difficult. Regards Jug
[pygame] Re: Website requests
Hi, What techniques will be used for that? rewrite in python!!! is very unspecific.
[pygame] Re: Website requests
Hi, I vote for Django :) But I think thats a matter of arguments and personal interests/ knowledge. My opinion: I would really like to participate in the rewrite, but I only know Django and a little MoinMoin (standard installation). Now some arguments (quotes from http://pygame.org/wiki/gsoc2009ideas): -Don't write an own wiki, there are enough out there. MoinMoin would be a good sort, but only as wiki. feed(rss, atom) for wiki recent changes. MoinMoin supports rss (/atom?) Menu to use alternating background colours - to make it easier to read. Should be a very simple and small js hack (backend-independent) Optional email notification on project change, including release and comment. A per user, per project option. Django task Nicer urls for projects. eg projects/512/zanthor/ Django task (very easy) detect tabs in code blocks, and convert to spaces. Either ask to convert to 4 or 8 spaces, or do some magic to figure out how many spaces. Python task (backend independent) Browsing projects in more ways. By ranking, by date. Django task (easy) Spotlight projects changeable from management area. Django task Fix website for looking ok in 800x600 resolution - the header does not scale down well. html/css/template task (mostly backend independent) Combination of Django and MoinMoin is not trivial and will need some time/reading/testing, maybe starting with http://moinmo.in/HelpOnAuthentication/ExternalCookie. If it meets the requirements, http://github.com/sneeu/django-wiki/tree/master could be an alternative. Conclusion: In my opinion, the pygame.org rewrite could be done with Django and an integrated (MoinMoin-)wiki. Regards Jug
