So I guess PyUI is long abandonded? What else is there?

[Martin Maney]

In my copious spare time [that's a joke, I say, that's a joke] I've
been dabbling at getting a computerized version of a board game
working. After deciding that tk just made me want to vomit, and wx was
like swimming through concrete slurry, and others I have mercifully
forgotten about, I stumbled across pygame. (maybe not for the first
time; I think I set it aside earlier because it was described as being
aimed at a different sort of game, and besides, I had hoped wx might
serve more than one purpose for me.) This summer I picked the project
up again, and with PyGame pretty nearly all the things that had me
tearing my hair out with wx instead just work. Well, okay, I did need
some help finding the less visible parts of the docs, but that took all
of five minutes on IRC to get straightened away.

So the biggest part of the GUI is mostly done: the board and such
display, scroll, etc. Next up are the mostly non-graphic bits, the
text and numbers section of the display. I guess this part would have
been more or less easy in wx, but PyGame offers only very low-level
primitives. PyUI was the most promising package I found, but it seems
to be long dead, judging by the lack of life in its mailing list,
untouched bug list, and general brokenness. The fact that the last
several releases are all zip archives with names that include "win32"
reinforces my feeling that this is not going to get me anywhere useful
for a project that has to work on both MS and X11 platforms. :-(

So I'm just trolling, my hook baited in accordance with Aahz's
instructions, in hopes that PyUI still lives in a form that would be
useful, and that someone will rise to the bait and explain to me the
error of my ways (and more usefully, where the useful versions are to
be found). Alternately, any leads on a nice, simple widget set for a
PyGame environment would be equally appreciated.

Thanks!

[I don't normally like to get emailed and posted replies, but since I
only intermittently have time to sift through this very active group,
in this case I would appreciate the favor, if it's convenient.]

 

[Carlos Ribeiro]

So the biggest part of the GUI is mostly done: the board and such
display, scroll, etc. Next up are the mostly non-graphic bits, the
text and numbers section of the display. I guess this part would have
been more or less easy in wx, but PyGame offers only very low-level
primitives. PyUI was the most promising package I found, but it seems
to be long dead, judging by the lack of life in its mailing list,
untouched bug list, and general brokenness. The fact that the last
several releases are all zip archives with names that include "win32"
reinforces my feeling that this is not going to get me anywhere useful
for a project that has to work on both MS and X11 platforms. :-(

I've checked PyUI right now, and it seems that there is a release
numbered "1.0" - which is a sign that it must have reached a somewhat
stable stage. The win32 ZIP file that I've downloaded does not contain
any windows specific dll, pyd or exe file, but only pure Python code.
It includes renderers for OpenGL and PyGame itself, which are cross
platform, as far as I know. Are your sure that it will not work for
you? What is the latest version you tried?

Best regards,

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)

 

[Martin Maney]

I've checked PyUI right now, and it seems that there is a release
numbered "1.0" - which is a sign that it must have reached a somewhat
stable stage. The win32 ZIP file that I've downloaded does not
contain any windows specific dll, pyd or exe file, but only pure
Python code.

Yes, as an already-installed tree with the files compiled - well, that
explains the 1.0.Py2-2 versioning in the name.

Anyway, I've found the problem buried in a feature request at the
project's sourceforge site. In his own words:

The OpenGL renderer on 0.95 depends on WGL which is available only on
Windows implementations. Support for other platforms such as Mac and
Linux would be nice.

Since the project description claims it, yeah, that sure would be nice.
This perfectly explains the errors I've been seeing. Thanks, Carlos,
you stirred me to dig deeper and put the nail in it - it's another case
of "Microsoft compatibility" leading another poor fool astray.

This truly does help. Now I can stop wondering whether it was
something I was doing wrong and walk away from this waste of time.
Would some god-like person with access please make a note of this on
the uneditable PyUi page on the wiki? Then there'd be at least a
chance others could avoid wasting their time.

Thanks!

--
Microsoft, which used to say all the time that the software business
was ruthlessly competitive, is now matched against a competitor whose
model of production and distribution is so much better that Microsoft
stands no chance of prevailing in the long run. They're simply trying
to scare people out of dealing with a competitor they can't buy,
can't intimidate and can't stop. -- Eben Moglen

 

[Christophe Cavalaria]

Yes, as an already-installed tree with the files compiled - well, that
explains the 1.0.Py2-2 versioning in the name.

Anyway, I've found the problem buried in a feature request at the
project's sourceforge site. In his own words:

The OpenGL renderer on 0.95 depends on WGL which is available only on
Windows implementations. Support for other platforms such as Mac and
Linux would be nice.

Since the project description claims it, yeah, that sure would be nice.
This perfectly explains the errors I've been seeing. Thanks, Carlos,
you stirred me to dig deeper and put the nail in it - it's another case
of "Microsoft compatibility" leading another poor fool astray.

This truly does help. Now I can stop wondering whether it was
something I was doing wrong and walk away from this waste of time.
Would some god-like person with access please make a note of this on
the uneditable PyUi page on the wiki? Then there'd be at least a
chance others could avoid wasting their time.

Thanks!

Well, I think that it's simply due to the fact that the docs for pyui are
out of date. It's true that the gl rendere needs WGL, but the p3d renderer
only needs SDL and pygame to work. Too bad that they don't mention it,
isn't it ?

 

[Carlos Ribeiro]

Martin,

As the other poster mentioned, the SDL-based renderer for PyUI may
help you. Please let us know if you made it work.

I share your pain -- I'm fighting a long battle to find a simple,
intuitive, productive and cross-platform GUI framework for my own
apps. In the end, I'll probably do with many others had done before me
-- end up writing my own framework as a shim layer over someone's else
work. I don't know the reason - if that's just because we can't agree
on a framework, or if it's because there are so many different ways
(and platforms) to make it work that some type of agreement, or
standardization, is just impossible at this point. But I hope the
situtation will improve.

Yes, as an already-installed tree with the files compiled - well, that
explains the 1.0.Py2-2 versioning in the name.

Anyway, I've found the problem buried in a feature request at the
project's sourceforge site. In his own words:

The OpenGL renderer on 0.95 depends on WGL which is available only on
Windows implementations. Support for other platforms such as Mac and
Linux would be nice.

Since the project description claims it, yeah, that sure would be nice.
This perfectly explains the errors I've been seeing. Thanks, Carlos,
you stirred me to dig deeper and put the nail in it - it's another case
of "Microsoft compatibility" leading another poor fool astray.

This truly does help. Now I can stop wondering whether it was
something I was doing wrong and walk away from this waste of time.
Would some god-like person with access please make a note of this on
the uneditable PyUi page on the wiki? Then there'd be at least a
chance others could avoid wasting their time.

Thanks!

--
Microsoft, which used to say all the time that the software business
was ruthlessly competitive, is now matched against a competitor whose
model of production and distribution is so much better that Microsoft
stands no chance of prevailing in the long run. They're simply trying
to scare people out of dealing with a competitor they can't buy,
can't intimidate and can't stop. -- Eben Moglen

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)

 

[Martin Maney]

Well, I think that it's simply due to the fact that the docs for pyui are
out of date.

And incomplete at any time, though that's hardly uncommon.

It's true that the gl rendere needs WGL, but the p3d renderer
only needs SDL and pygame to work. Too bad that they don't mention it,
isn't it ?

It would be nice if the problem were so easily solved, but as of 0.95
(last one released as an installable package rather than an image of an
installed-on-Windows tree), p3d seems to be openGL based and is, in
fact, the invoker of the crash in some of the tests I tried to run to
see if the package were working:

<source pyui/core.py, init()>
elif renderer == "p3d":
from renderers.openglPygame import OpenGLPygame
</source>

renderers.openglPygame imports openglBase, and that tries to import the
WGL thing, and then it falls over. :-(

Perhaps you meant the "2d" renderer (aka pygame2D module)? With that
explicitly requested, many of the test/demo programs run, sort of.
Their behavior is not what I'd call encouraging, from the request for
"font.ttf", with the failure, on both an older and quite recent version
of pygame, reported as "Couldn't find arial.ttf" (WTF?), to the lack of
any apparent means of stopping them other than control-C in the xterm
from which they were run (well, or doing something that crashes them -
I'm still not sure what I did to minesweeper).

Oh, and there's no way to tell it what font you'd like to use, nor what
size (at least with the pygame renderer; there's a "font" argument to
one function, but it's ignored). Or are you supposed to go poking
around at the module-scope variables, like poke'ing bytes into magic
locations in a prehistoric Basic program?

"Pining for the fjords" sounds about right. :-(

 

[Martin Maney]

stable stage. The win32 ZIP file that I've downloaded does not contain
any windows specific dll, pyd or exe file, but only pure Python code.

Sorry, 100% Python code is no more inherently portable than 100% C
code. It's avoiding non-portable libraries and etc. that make the
difference in both cases.

Are your sure that it will not work for you? What is the latest
version you tried?

See longer reply in this thread, and yes, I'm sure it would be like
pissing into the wind... the wind along the Gulf coast last week. :-(

 

[Christophe Cavalaria]

And incomplete at any time, though that's hardly uncommon.


It would be nice if the problem were so easily solved, but as of 0.95
(last one released as an installable package rather than an image of an
installed-on-Windows tree), p3d seems to be openGL based and is, in
fact, the invoker of the crash in some of the tests I tried to run to
see if the package were working:

<source pyui/core.py, init()>
elif renderer == "p3d":
from renderers.openglPygame import OpenGLPygame
</source>

renderers.openglPygame imports openglBase, and that tries to import the
WGL thing, and then it falls over. :-(

I remember now, you must also comment the import for WGL. It isn't needed
anyway since it uses SDL for the fonts and WGL was only used for that on
windows.

Perhaps you meant the "2d" renderer (aka pygame2D module)? With that
explicitly requested, many of the test/demo programs run, sort of.
Their behavior is not what I'd call encouraging, from the request for
"font.ttf", with the failure, on both an older and quite recent version
of pygame, reported as "Couldn't find arial.ttf" (WTF?), to the lack of
any apparent means of stopping them other than control-C in the xterm
from which they were run (well, or doing something that crashes them -
I'm still not sure what I did to minesweeper).

Oh, and there's no way to tell it what font you'd like to use, nor what
size (at least with the pygame renderer; there's a "font" argument to
one function, but it's ignored). Or are you supposed to go poking
around at the module-scope variables, like poke'ing bytes into magic
locations in a prehistoric Basic program?

The only way to tell him what font to use seems to be writing a new theme,
or using a theme with a font parameter.

 

[Aahz]

[p&e per request, but please don't return the favor]

This truly does help. Now I can stop wondering whether it was
something I was doing wrong and walk away from this waste of time.
Would some god-like person with access please make a note of this on
the uneditable PyUi page on the wiki? Then there'd be at least a
chance others could avoid wasting their time.

Which wiki? If you're talking about the one on python.org, you need to
go through the UserPreferences link to get yourself an account, but
after that, Bob's your uncle. (Even works with Lynx, as long as cookies
are enabled....)

 

[Martin Maney]

Which wiki? If you're talking about the one on python.org, you need to
go through the UserPreferences link to get yourself an account, but

Did that, it found the account I'd setup some time past, so maybe it
was just a lost or expired cookie. I wouldn't have expected a
"membership required to edit" setting to have shown up as "immutable",
but I take it that's just Moin's funny way of handling that case.