Re: [pygame] Ocemp

[mva@xxxxxxxxxxxx]

Andre Roberge <andre.roberge@xxxxxxxxx>:

[...]
> [snip]
>
> How about porting an existing GUI library built on top of SDL?   I just did
> a quick search and found paraGUI
> http://www.bms-austria.com/projects/paragui/index.php
>
> I think it looks great.

That adds a third party dependency to your project besides SDL/Python, which
possibly has its own limitations of platform availability besides the both
above. While other existing GUI libraries, that are completely written in
Python or portable C code, guarantee the same broad usability range as Python
and SDL do, a third party kit could limit this (I did not check this for
ParaGUI, it's just an general annotation).

> Whereas many of the objections raised by Marcus are valid, I would argue
> that having a "standard" widget set (already existing in the C++ world)
> would be a strong asset to developping using Pygame.  For those concerned
> about speed, it could be use as a selling point: develop in python/pygame
> and, for those few parts that are not fast enough, translate into C++....

This can be already accomplished with existing solutions (be it third party
GUI libraries for pygame or not). Simply recode the necessary parts. The current
two major ones (imho), pgu and ocempgui, were designed using python to allow an
easy extensibility and user integration (speaking for ocempgui here only, but
I think, Phil had the same in mind with pgu). If you'd have to code this in C or
C++, the development progress for both on the developer side and user side
could be slowed down as both languages force you to take more care in order to
keep portability, maintainability and safety on a high level.

>  *Strong disclaimer*: I have no idea how much work would be require to
> develop a python "wrapper" to it...

Depends on the one(s) who would want to do that :-).
Also such wrappers can break easily, if the responsible original kit changes
the one or other part. Instead of taking care about the compatibility to SDL,
this would add a bunch of more work. Again I would ask here, who _would_ want
to take care of such a work. This of course applies to the existing GUI
solutions fo pygame, too (speaking about the user code), but does not force
the pygame developers to work overtime ;-).

Do not get me wrong. An out-of-the-box GUI module definitely would push the
acceptance, but the user base is pretty different about how it should work and
what it should offer, as you already see for X with Gtk+, Qt, Tk, AnyGUI,
etc.pp..

Thus I am not sure, if it would be worth the work be it either the one or other
way.

Regards
Marcus