up with PyGUI!

[Zooko O'Whielacronx]

I'm a fan of Greg Ewing's PyGUI [1]. I used it to code a simple game
for my son [2], and enjoyed it. Programming with wxPython feels like
programming with a C++ tool that has been wrapped in Python.
Programming with PyGUI feels like programming with a real Python tool.

If you're developing a commercial application in Python, wxPython is
currently the only option that offers native widgets on w32. It would
be a boost for Python if PyGUI got a native w32 backend.

Therefore, I offer the following suggestions:

Python programmers: use PyGUI! It's nice. Contribute bug reports and
so forth.

Python developers: Is it too early to include PyGUI in the standard
library? It seems stable to me.

PSF: If anyone applies for a grant [3] to put a proper w32 backend into
PyGUI, please give them money. I would offer to do that job myself,
but (a) I'm not w32 expert and (b) I'm busy trying to make one of those
aforementioned commercial apps.

Thanks,

Zooko, Journeyman Hacker

[1] http://www.cosc.canterbury.ac.nz/~greg/python_gui/
[2] http://zooko.com/log-2004.html#d2004-06-23
[3] http://python.org/psf/call-2004.html

[Ed Leafe]

On Sep 26, 2004, at 2:31 AM, OKB (not okblacke) wrote:

How am I supposed to know, just by looking at that, which
controls are in which sizers and what the relationship is between the
two sizers? I have to visually parse every single line -- not just the
creation of each widget, but also the line that adds it to a sizer.
And
there could easily be an inconsistency -- you might accidentally give a
widget a parent that's inconsistent with the sizer you add it to. With
a nested structure it becomes clear:

class frame(wxFrame):
class sizer1(wxBoxSizer):
class button1(wxButton):
# name, size, etc.
class button2(wxButton):
# etc.
class panel(wxPanel):
class sizer2(wxBoxSizer):
class listBox1(wxComboBox): # etc.
class listBox2(wxComboBox): # etc.
class button3(wxButton): # etc.
class text(wxTextCtrl): # etc.

Forgive me if this is an oversimplification, but it looks like what
you want is an XML-based definition of your UI objects, and are trying
to approximate that with Python syntax. What you've written looks an
awful lot like an XRC file structure, albeit without the closing tags.

In Dabo, our first attempt at creating a visual form designer was
along the lines of PythonCard: place controls on their container, and
resize/move them visually. Once we started to tackle nested containers,
though, we abandoned that approach for the reasons you cited: it's
simply too confusing to see what goes where. We are now working on
adapting wxGlade to use Dabo classes, as that visually shows the
nesting in a clear an unambiguous tree. Dabo would then know how to
create the form from the XML, or, in the alternative, we would create
Dabo code that the developer could then modify. The latter seems like
it would have to be a one-way process, while keeping things in XML
could allow for two-way editing.

___/
/
__/
/
____/
Ed Leafe
http://leafe.com/
http://dabodev.com/

[Carlos Ribeiro]

On Sun, 26 Sep 2004 08:28:10 -0400, Ed Leafe <[e-mail]> wrote:

Forgive me if this is an oversimplification, but it looks like what
you want is an XML-based definition of your UI objects, and are trying
to approximate that with Python syntax. What you've written looks an
awful lot like an XRC file structure, albeit without the closing tags.

Here we go -- Sunday morning, coding and discussing...

I'm avoiding a data-driven approach (XML) because I think that keeping
all declarations in Python will make my code easy to work with in the
long run. I've tried some XML based tools, but found the process to be
too convoluted -- it needs another set of tools and skills, and it
means that I need to be able to read yet another completely different
syntax. Also, I'm trying to avoid visual GUI designers at this point
-- I realized that I simply lose to much time futzing with pixel
alignment details, and that I'm better investing my time doing other
stuff. I've read a comment in the Wing IDE website that puts it very
well:

http://wingware.com/doc/howtos/wxpython
"""
A Caveat: Because Python lends itself so well to writing data-driven
code, you may want to reconsider using a GUI builder for some tasks.
In many cases, Python's introspection features make it possible to
write generic GUI code that you can use to build user interfaces on
the fly based on models of your data and your application. This can be
much more efficient than using a GUI builder to craft individual menus
and dialogs by hand. In general hand-coded GUIs also tend to be more
maintainable.
"""

(It's interesting to note that although Wing folks talk about
"data-drive code", it really applies very well to the declarative
approach)
But while interesting, all this discussion is just revolving around a
few points. I think that we agree on more things than we disagree. We
mostly disagree with the (ab)use of Python as a tool to declare
complex nested elements. I don't think this is a real problem, and I
think that Python can add enough power to the declarations as to make
them more flexible than it's possible using XML or other similar data
format. It's easy to write small blocks of reusable declarations in
Python, and it's easy to mix code and static data on the declarations.
This is more difficult with a XML approach. For example:

class Username(EditBox):
label = _('User name')
size = 12

class UserForm(Form):
class username(Username):
datalink = userfield
class password(EditBox):
label = _('Password')
size = 12
datalink = password
password = True

In the example above, I'm using two features:

1) It's possible to call functions in the middle of the declaration.
In the example, the _() call it's a shorthand convention for gettext()
internationalization code. I like the way it's presented in the class
declaration. It's visible and easily editable.

2) The Username class is declared outside of the form. In this way it
can be used for several form declarations. It's harder to do the same
for individual elements of design with XML. Also, the use of
inheritance makes it clear that some of the parameters can be
individually overriden on each form.

As a side note, the fact that many classes are nested makes easier to
manage the namespace. It's something that we also get for free with
this design.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: ca********@gmail.com
mail: ca********@yahoo.com

[Steve Holden]

Alex Martelli wrote:
[...]

Basically, easily transportable/tradable goods and services tend to have
more similar prices across different economies -- not considering
absurdly high and punitive tariffs that distort things (generally
raising the prices of clothing here, of cameras in India, etc), a shirt
or a camera should cost the same here and there. Goods and most
particularly services that _aren't_ easily transportable and tradable
are quite a different story; my barber charges me ten times as much as a
Mumbai barber would, taking advantage of the cost and inconvenience it
would be for me to have my head sent to Mumbai for hairstyling...:-).
In actual fact what tends to happen is that manufacturers in the wealthy
countries outsource their production to the developing economies and
continue to charge inflated prices in international markets. This is
why, for example, Nike are able to charge $125 in the US for a pair of
trainers that cost them $6 to make under sweatshop conditions in
Malaysia and similarly developing countries.

This is, of course, appreciated by the stockholders in the
multinationals, who see huge profits with greatly-reduced obligations to
support the people who provide the labor.

Microsoft have, if rumor is to be believed, even gone so far as to
outsource their HR department, surely the ultimate irony.

Much of my information on this comes from "No Logo" by Naomi Klein (see
http://www.amazon.com/exec/obidos/tg...8961?v=glance),
and I blogged about this in relation to software production in "How Much
Profit is enough?" in
(http://www.artima.com/weblogs/viewpost.jsp?thread=5870

with a mixed reaction of responses.
[...]
Personally, I think there will be _some_ modest reduction of
differences, and movements back and forth, if legal barriers can be
lowered a bit (I don't consider that lowering a certainty), but, judging
from these historical examples, I don't think it will reduce diffences
by ALL that much...

My own personal history involved growing up in the 1950's in a city with
a large immigrant population, mostly from Pakistan and the West Indies,
who had responded to advertising placed in their local papers by
Bradford City employers: the economy was booming, and the indigenous
population could earn far better money than was offered by the jobs the
immigrants took, frequently working in mills or on the buses.

Of course twenty years later the booming textile economy had been
overtaken by the globalization that was inevitable. As is currently
happening in the USA, much of the foreign expansion of competitive
economies was fueled by British capital migrating to countries with a
lower cost of labor, resulting in higher return on capital employed.

Of course the response of (some of) the Bradford population was to
complain along the lines of "they come here and take our jobs", quite
happily ignoring that immigrants had been almost begged to take the
lower-paid jobs that were going begging. Of course by the time the
industry that provided those jobs had faded away the immigrants were in
a much better position to compete across the board for employment, and
were frequently better-motivated (being the sort of people who were
prepared, like myself, to relocate across the globe) to compete for the
remaining jobs.

The racist British National Party found this an ideal situation to
attempt to exploit, with famous consequences in certain hotbeds of
racism. Overall, I am happy to say, the British population seems to
reject such racism as nonsensical.

The laughable thing is that, in general, the American population is
delighted to support outsourcing as long as it leads to a lower cost of
capital acquisition. It's only when the inevitable consequences (chief
among which is a less-globally-competitive American economy) that they
start to whinge and moan.

I think it's to Bush's discredit that the pretends to support a
globalized economy while still attempting to promote protectionism, and
it's to Kerry's discredit that he promotes protectionism by suggesting
tax incentives for companies that don't outsource.

People vote with their wallets, unfortunately without a sufficient
appreciation for the long-term consequences. But then that's the way
they reproduce too, so we shouldn't expect too much of a fundamentally
flawed lifeform. In two hundred years we will have drowned in our own shit!

regards
Steve

[Steve Holden]

Arthur wrote:

[...]

And the impact of the the energy of this brew is then labeled a new
imperialism.

Well, it's probably something to do with the way that arms are used to
promote the economic imperative when monetary incentives fail.

regards
St=eve

[OKB (not okblacke)]

Ed Leafe wrote:

Forgive me if this is an oversimplification, but it looks like
what
you want is an XML-based definition of your UI objects, and are
trying to approximate that with Python syntax.

You're partially right, I suppose, in that the usual structure of
XML is more like this than the usual structure of Python code. As
Carlos mentioned, however, an important point (which I neglected to
explicitly put into my example) is that if you're doing it in Python you
can include actual Python code in the GUI definition. I admit there's a
certain attraction to totally separating the layout from the code by
using XML (or whatever) to define the layout and then linking it up with
Python code, but on the other hand it's confusing to have a button
defined someplace and have what it does defined in a completely
different place.

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

[Bengt Richter]

On 26 Sep 2004 05:35:03 GMT, "OKB (not okblacke)" <br************@NObrenSPAMbarn.net> wrote:

Bengt Richter wrote:

myFrame = (
Frame(
Sizer(
CustButton(size= ... etc),
CustButton(size= ... etc),
Panel(
Sizer(
CustListBox(etc),
CustListBox(etc),
CustButton(etc),
Text( etc )
)
)
)
)
)
One problem with this is that it's not possible to define methods
on your widgets in this kind of structure.

^^-- I take it you mean within...
Hm, yes. Need a full lambda or "anonymous def" to do that inline. At least
for non-trivial methods. Wasn't thinking about that. Hm, "not possible" pushes
a button somewhere deep in my psyche though. I guess it's the occasional reward of
discovery that keeps the circuit alive ;-) Not sure ... ;-)

If Python's syntax were more flexible, this could perhaps be done
in other ways -- I'm not saying I want that -- but as it is the
only real way to construct nested structures in Python is with
class definitions. You don't mean that ("...only real way...") as broadly as it
sounds, do you?

Sorry, you're right. Obviously dictionaries and lists can be
nested. A key point, though, is the one I mentioned above: classes are
the only structure which allow you define nested structures with
arbitrary in-line code. The "in-line" proviso there may seem obtuse,
but I think it's important. For instance, if you define a button, you
should be able to define the event handler for a click on that button
right there, as part of writing the button code. Having to separate the
event-handling code out into a separate routine leads to
spaghettification, and also introduces a bunch of naming problems (you
need to have a consistent naming convention that links a widget to its
event handler).

whatever = factory("""
any source format you like # ;-)
""")
Not entirely kidding.

(Also, just for the record: I know you can nest function
definitions in other functions, but this isn't useful here because I was going to chase down that rabbit trail a bit ;-)there's no way to access the nested function definition from outside the There you go again, pushing the "no way" button ;-)enclosing function, whereas you can reference nested classes with normal
attribute access.)

The trouble with accessing nested functions is there's no unboxed way to mutate
closure variables, otherwise I think you could get around the "no way" building
on something like

def nester(*args, **kw): ... def foo(*a,**k): print 'foo here with', args, a, k
... def bar(*a,**k): print 'bar here with', args, a, k
... def accessnest(self, name, *args, **kw):
... return getattr(self, name)(*args, **kw)
... accessnest.foo = foo
... accessnest.bar = bar
... accessnest.__dict__.update(kw)
... return accessnest.__get__(accessnest)
... callnested = nester('nester arg', outsider=lambda x: 2*x)
callnested('foo', 1,2, hi='ho') foo here with ('nester arg',) (1, 2) {'hi': 'ho'} callnested('bar') bar here with ('nester arg',) () {} callnested('outsider', ' xxx') ' xxx xxx' callnested('outsider', 123)

246

Not that this is crisp and clean and lean as a way of expressing design intent ;-)

Regards,
Bengt Richter

[Christophe Cavalaria]

Carlos Ribeiro wrote:

On Sun, 26 Sep 2004 08:28:10 -0400, Ed Leafe <[e-mail]> wrote:

Forgive me if this is an oversimplification, but it looks like
what
you want is an XML-based definition of your UI objects, and are trying
to approximate that with Python syntax. What you've written looks an
awful lot like an XRC file structure, albeit without the closing tags.
Here we go -- Sunday morning, coding and discussing...

I'm avoiding a data-driven approach (XML) because I think that keeping
all declarations in Python will make my code easy to work with in the
long run. I've tried some XML based tools, but found the process to be
too convoluted -- it needs another set of tools and skills, and it
means that I need to be able to read yet another completely different
syntax. Also, I'm trying to avoid visual GUI designers at this point

Did you check that new project :
http://techgame.net/projects/Framework/wiki/
-- I realized that I simply lose to much time futzing with pixel
alignment details, and that I'm better investing my time doing other
stuff.

That's why I like QtDesigner. The think lets you place as you want the
controls on the form, but you are encouraged to always group the controls
and to never relly on pixel placement. And it is really easy to use once
you know how.

[Greg Ewing]

Peter Hansen wrote:

class MainFrame(FrameDescription):
b1 = ButtonDescription(
size = (40, 40),
text = "b1",
)

That's pretty close to what you asked for. You're welcome,
in advance. <wink>

The idea was to be able to specify attributes of the
widget using a suite of assignments instead of a function
call. Not a big difference, but it would tidy things up
a bit and avoid those awkward dangling parentheses that
you get with the above style.

My example was a little off target, btw. It should
have been more like

class MyWindow(Window):

def __init__(self):

instance b1(Button):
size = (40, 40)
text = "b1"

i.e. the created objects are to be attributes of
*instances* of MyWindow, not its class.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Carlos Ribeiro]

On Wed, 29 Sep 2004 17:52:35 +1200, Greg Ewing
<gr**@cosc.canterbury.ac.nz> wrote:

class MyWindow(Window):

def __init__(self):

instance b1(Button):
size = (40, 40)
text = "b1"

Greg,

I don't know how far have you advanced with your own system. I'm
writing my own, but I decided to focus on HTML generation -- it's a
templating system, but designed to work entirely in Python. But the
basic design can be used for other types of application - for example,
generation of Qt or wxPython code.

I've posted some code last week, but I have improved greatly since,
and solved some problems. There are a few issues where I still haven't
found a satisfactory solution. Here's a sample of code I'm working
with:

class Page(HtmlPage):
class html_head(HtmlHeader):
copyright = trimdocstring("""
Web Application Framework
ABCD/TS - Abusing Class Declarations Templating System
(c) 2004 Carlos Ribeiro
ca********@gmail.com
""")
title = 'Web Application Framework'
style = CSSStyleSheet
class html_body(HtmlBlock, Tag('body')):
class main_document(TwoColumnLayout):
class head(PageHeader):
title = ''
class nav(NavigationPane):
class menu(HtmlMenu)
id = 'navmenu'
options = [("Usuários", "/usuarios"),
("Tarefas", "/tarefas"),
("Notas fiscais", "/notasfiscais"),
("Estoque", "/estoque"),
("Sobre o sistema", "/sobre"),
])
class content(DocumentPane):
text = ''

class AboutPage(Page):
class html_head(Page.html_head):
title = 'About this system'
class html_body(Page.html_body):
title = 'About this system'
class main_document(Page.html_body.main_document):
class content(Page.html_body.main_document.content):
text = trimdocstring("""
<h2>Templating system</h2>
<p>
This is a templating system based on Python
declarations. The main
advantage is the possibility to express complex
data structures using
code-driven intelligence. The system is fully
object-oriented, supports
inheritance, and allows for easy modularization
and code reuse.
</p>
""")

All interesting classes shown above are descendants from a single
HtmlElement class, which declares a method 'text'. The following
sequence renders the AboutPage:

AboutPage().text()

One thing that still bothers me is that I need to redeclare the full
path to the nested classes when I want to override some behavior, as
in:

.... class content(Page.html_body.main_document.content):

That was the best solution that I could find. I tried to use
descriptors to write this code in a slightly simpler way, but couldn't
manage to make them work as wanted, and I'm not even sure if it's
possible.

The resulting html code is being designed for *readability* first, and
is properly indented, which makes easier to debug the system at this
stage. I'm keeping good distance of premature optimization at this
point. It's my intention, in the future, to provide a way to generate
native applications from the same templates, within a 'browser-like'
environment but using native controls for data editing whenever
possible.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: ca********@gmail.com
mail: ca********@yahoo.com