up with PyGUI!

  • Thread starter Zooko O'Whielacronx
  • Start date
J

Josef Dalcolmo

on Fri, 17 Sep 2004 12:02:17 -0300

CR> As far as I know, no open source tool is close to the quality that
CR> professional tools like Adobe Acrobat can give to you. Part of the

Maybe as far as features are concerned. However I changed from MS-Word + Acrobat to OpenOffice.org on a large document (output is in PDF format), simply because Acrobat (and pdfwriter) kept choking (crashing) on that particular document, while OOo never gave me that kind of trouble.

- Josef
 
S

Stephen Kellett

JanC said:
This is probably not only Apple's fault. Most local music distribution
rights are owned by different, local companies that don't want to lose
their possible income/power, so online music stores like Apple often have
to make separate agreements per country...

Indeed, try purchasing Hevia's music in the UK. There are no
distributors because the rights are not available in the UK. It is very
hard to get his music in the UK, but go to Northern Spain (Galicia,
Asturias) and you can't move for falling over his music.

Stephen
 
C

Cliff Wells

I intentionally restricted myself to one sentence, with one opinion word --
'reactionaries', on a topic people have written books about. However ...


To me, the global information economy is as real as the global Python
community.

Community certainly. Economy less so. The main reason I say "so-
called" is because the widely disparate costs-of-living and
corresponding pay scales make it unrealistic to assume there is anything
"global" about it. Local economies, while clearly needing to
participate in the global market, are just that: local.
To the extent that all US employers producing similar products have equal
access to such cost savings, the long-term competitive benefit should tend
toward zero and most benefit should go to consumers and non-US workers. It
was Indian software entrepreneurs who pursued US businesspeople more than
the reverse.

I'm not referring to employers when I refer to the damage done by
outsourcing. I'm referring to the work force in first-world countries.
When a US employer can pay far below minimum wage (U.S. minimum) then
the only option for U.S. workers is to also work for that same wage or
find other lines of work. This is already happening. I know many
programming jobs here in Portland now pay as little as $10 an hour.
Unskilled manual labor typically pays at least that, semi-skilled and
skilled manual labor up to three or four times that. Some of this is
undoubtedly due to economic factors that have nothing to do with
programming per se, but I strongly suspect most of it is the direct
result of skills required to be a programmer being "cheapened" (not in a
disparaging sense, just in economic terms), by low-paid programmers in
countries where the cost of living is far lower than in the U.S.
I did not try to quantify in my original statement. However, it takes more
than a few people to get myriads of job protection laws passed in countries
around the globe. Dislike of competition for 'my job' is pretty universal.

That's right. But it isn't the foreign worker who is being rejected,
it's US employers who want to pay $5 an hour for skilled workers that
are being curtailed.
[snip]
let's ...have laws that require employers to pay prevailing wage

The prototype 'prevailing wage' law in the US, the 1930s Davis-Bacon Act,
was passed and signed by begruding people. It had the explicit purpose
(and effect) of excluding dark-skinned Americans from participating in the
American construction industry, especially in northern states, by making it
unprofitable to hire them. Its negative effects continue today.

Well, that's certainly *one* interpretation of the intent of that law.
Here's another:

From: http://www.solidarity.com/Davis-Bacon.htm

"""
Then as now, construction is a time and materials industry. Low bid
requirements on public projects allowed contractors from outside an area
to bid and win work based on substandard wages and helped create the
situation where contractors literally ´imported¡ low-wage workers from
around the country rather than use the local labor force.

Abuses were wide spread in the years preceding the Acts passage. Bacon,
a former Banker, explained the need for the law when he detailed for his
colleagues during debate on the bill how a construction firm from
Alabama transported thousands of unskilled workers to a public project
in New York.

´They were herded onto this job, they were housed in shacks, they were
paid a very low wage, and ... it seems to me that the federal government
should not engage in construction work in any state and undermine the
labor conditions and the labor wages paid in that state.¡
"""

The point of prevailing wage isn't to exclude foreigners. It's to
prevent corporations from exploiting local economies (U.S. or
otherwise). What you seem to be missing is that the work doesn't get
distributed, it gets moved from place to place, wherever the workers are
cheapest. That isn't a global economy, it's global strip-mining.
Programmers in developing countries generally are employed by local
employers who pay them more than the previous local prevailing wage. In
terms of real economic goods -- food, clothing, housing, internet service,
and so on -- their pay may be comparable to that of programmers in the
'industrial' nations.

I just quit working at a company where Ukrainian developers were paid to
develop products at a fraction of what U.S. developers working on
similar software would have been paid. Were they paid well? Certainly,
by Ukraine standards. I'm not arguing that. I'm arguing that the
company who paid them essentially bypassed U.S. minimum-wage laws that
exist for a reason.
Their apparent cheapness per comparable output is largely a function of
exchange rates at least partly distorted by centuries of government force.

Exchange rates? Um, okay. The bottom line is that when U.S. companies
are allowed to hire Ukrainian developers at the equivalent of $5 an hour
they are certainly going to take advantage of that. And when Manila
starts pushing out developers at $2 an hour, those Ukrainians who were
doing so well a minute ago are going to find themselves out of work.
The bottom line is that corporations exploit workers to whatever extent
they are allowed to. The so-called "global economy" is the latest and
greatest method of doing so. Consider the exploits of Nike, Walmart,
Levis, Reebok, et al to get a foreshadowing of what's to come in the
software trade. I was told flat out at my last job that the main reason
the company had any U.S. employees at all was so that customers would be
able to talk to people who spoke English.
I expect such distortions will lessen as communication makes them less
tenable.

This may be so. Of course I expect the U.S. job market for software
development will be gone by then (or simply seen as a good first job for
students before they can get a better job at Walmart).
I also expect increasing numbers of US knowledge/information
workers with portable skills to take advantage of the distortions while
they last.

Well, I've certainly considered other lines of work, if that's what you
mean.


Cliff
 
N

Nicolas Fleury

Hans said:
Zooko said:
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.


This problem is addressed by Wax:

I think it doesn't go far enough. Wouldn't it better to hide the
concept of wxPython ownership by now passing the parent in the
constructor, but instead create the wxPython widget when it is finally
added to its parent? It could also be a good idea to take the occasion
to respect PEP8. Note also that "import wax" would be better than "from
wax import *".

Regards,
Nicolas
 
H

Hans Nowak

Nicolas said:
Hans said:
Zooko said:
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.

This problem is addressed by Wax:


I think it doesn't go far enough. Wouldn't it better to hide the
concept of wxPython ownership by now passing the parent in the
constructor, but instead create the wxPython widget when it is finally
added to its parent?

I'm not sure what you mean. One known issue is, that there is some redundancy
when creating a control and adding it to its parent:

b = Button(parent, ...)
parent.AddComponent(b, ...)

I am thinking of ways to make this simpler. One possible solution would be to
accept a 'layout' parameter:

b = Button(parent, ..., layout={'expand': 'both', 'border': 2})

....but I'm not sure that actually makes things simpler or more readable.

It's also possible to do something like this:

parent.Add(some_control, parameters_for_control, parameters_for_layout)

I think this is rather ugly, and I don't like the mixing of control constructor
parameters and layout parameters. Aside from that, it's sometimes useful or
necessary to use the control before it's added to the parent. Consider:

from wax import *

class MainFrame(Frame):

def Body(self):
b1 = Button(self, text="b1")
b1.Size = (40, 40)
self.AddComponent(b1)

b2 = Button(self, text="b2")
self.AddComponent(b2)
b2.Size = (40, 40)

self.Pack()

app = Application(MainFrame)
app.Run()
It could also be a good idea to take the occasion
to respect PEP8.

Which recommendations of the style guide does the Wax code violate?
Note also that "import wax" would be better than "from
wax import *".

I'm considering it. This way, it would also be possible to import things on
demand. On the other hand, I don't like to write 'wax.' before everything.
 
A

anton muhin

Hans said:
I'm not sure what you mean. One known issue is, that there is some
redundancy when creating a control and adding it to its parent:

b = Button(parent, ...)
parent.AddComponent(b, ...)

I am thinking of ways to make this simpler. One possible solution would
be to accept a 'layout' parameter:

b = Button(parent, ..., layout={'expand': 'both', 'border': 2})

....but I'm not sure that actually makes things simpler or more readable.

It's also possible to do something like this:

parent.Add(some_control, parameters_for_control, parameters_for_layout)

I think this is rather ugly, and I don't like the mixing of control
constructor parameters and layout parameters. Aside from that, it's
sometimes useful or necessary to use the control before it's added to
the parent. Consider:

from wax import *

class MainFrame(Frame):

def Body(self):
b1 = Button(self, text="b1")
b1.Size = (40, 40)
self.AddComponent(b1)

b2 = Button(self, text="b2")
self.AddComponent(b2)
b2.Size = (40, 40)

self.Pack()

app = Application(MainFrame)
app.Run()

I beg your pardon for possibly stupid comment---I haven't practice GUI
programming for a long time, especially in Python. However I mostly
prefer declarative approach for the problems like that. Therefore,
wouldn't it be interesting to describe the structure with class and
metaclass mechanism, like:

class MainFrame(FrameDescription):

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

etc.

with the best regards,
anton.
 
C

Carlos Ribeiro

I beg your pardon for possibly stupid comment---I haven't practice GUI
programming for a long time, especially in Python. However I mostly
prefer declarative approach for the problems like that. Therefore,
wouldn't it be interesting to describe the structure with class and
metaclass mechanism, like:

class MainFrame(FrameDescription):

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

etc.

Thats *exaclty* what I'm doing, after spending a long time evaluating
a lot of GUI packages, Wax included. Not that I didn't like Wax -- I
think the design is very good, and I would put it in the same class as
Greg Ewing's PyGUI, with the advantage that Wax runs in Windows. But I
miss the ability to write a declaration like you've done.

I have tested a metaclass engine yesterday that does something like
you wrote. In my particular case, I'm going to work with automatic
layout generation, so I'm not providing absolute positioning
parameters. But the mechanism is about the same. Here are two
declarations from my test script:

class UserForm(Form):
nickname = TextBox(length=15, default="")
password = TextBox(length=10, default="", password=True)
name = TextBox(length=40, default="")

class ComplexForm(Form):
class Header(Form):
nickname = TextBox(length=15, default="")
password = TextBox(length=10, default="", password=True)
name = TextBox(length=40, default="")
class Comment(Form):
comments = TextBox(length=200, default="", multiline=True)

It already accepts nested classes and some special attributes. There
are a few catches involving hacks to detect the original order of the
attributes in the class declaration. That's going to make a
difference, because one would implicitly assume that the tab order of
the data entry elements is the same as the declaration order. Solved
that, I'm working today on the code generation engine that will
generate the UI from the class declaration. I'll post a note here as
soon as I have something working.

--
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)
 
H

Hans Nowak

anton said:
I beg your pardon for possibly stupid comment---I haven't practice GUI
programming for a long time, especially in Python. However I mostly
prefer declarative approach for the problems like that. Therefore,
wouldn't it be interesting to describe the structure with class and
metaclass mechanism, like:

class MainFrame(FrameDescription):

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

etc.

with the best regards,
anton.

Yes. But not in Wax. :) The way Wax works is pretty much set in stone, and
although there is room for many improvements and shortcuts (passing layout in
constructor, auto-packing, etc), I'm not going to rewrite it so it supports the
above. It's meant as a friendly layer on top of wxPython; as such, I want it
to stay rather close to wxPython, so I'm less interested in writing an
innovative API.

Aside from that, I'm not sure if the construct described above is all that
great... it makes nested classes significant, and uses class attributes to
describe an instance (unless b1 is meant as a template for other buttons). It
also requires a bunch of magic "under the hood". I'd rather use less
surprising constructs. But that's just a matter of opinion; YMMV.

Cheers,
 
C

Cameron Laird

.
[long lament about
loss of good life
for US programmers]
.
.
This may be so. Of course I expect the U.S. job market for software
development will be gone by then (or simply seen as a good first job for
students before they can get a better job at Walmart).


Well, I've certainly considered other lines of work, if that's what you
mean.
.
.
.
It's worse than that, Cliff: there's serious reason to fear
that non-price factors might soon work *against* us in the US,
almost as much as they have for us in the past. I see this
running along a couple of lines:
*) "security"-related and DRM-IP-enforcing
export restrictions directly interfere
with our ability to deliver internation-
ally; and
*) MS hasn't been alone in habituating
international customers to associate US
software with expense and unreliability.
 
N

Nicolas Fleury

Hans said:
I'm not sure what you mean. One known issue is, that there is some
redundancy when creating a control and adding it to its parent:

b = Button(parent, ...)
parent.AddComponent(b, ...)

What I'm suggesting is to avoid the redundacy and do:
parent.Add(Button(...))

I've done it for some GUI framework where I work encapsulating wxPython.
The drawback is that you need to delay the creation of widgets, which
means some attributes might be stored twice. But it's definitely easier
to use.

Another thing I'm suggesting is a mechanism to not destroy a widget
until it's corresponding python object is destroyed. It's more complex,
but Python has already ownership with refcount, garbage collection, etc.
and I think a truly pythonic GUI framework should use the same ownership
mechanism.
I am thinking of ways to make this simpler. One possible solution would
be to accept a 'layout' parameter:

b = Button(parent, ..., layout={'expand': 'both', 'border': 2})

...but I'm not sure that actually makes things simpler or more readable.

I personally prefer Java-Swing-Layout and wxPython-sizers approach. I
think it's better to add widgets in the layout.
It's also possible to do something like this:

parent.Add(some_control, parameters_for_control, parameters_for_layout)

Again, I think layouts/sizers are very nice, since the way to add can be
very different dependending on the layout/sizer. For example,
specifying col and row when adding to a GridBagLayout.
Which recommendations of the style guide does the Wax code violate?

IIRC, method names beginning with lowercase, as all the Python API.
I'm considering it. This way, it would also be possible to import
things on demand. On the other hand, I don't like to write 'wax.'
before everything.

It's just that when you work multiple modules, autocompletion for a
module doing a "from wx import *" is a nightmare (and is also slowing
debuggers, since so many symbols are in each module namespace). If wax
becomes big, it would also be a pain. You can do "import wax as w" ;)

Regards,
Nicolas
 
H

Hans Nowak

Nicolas said:
What I'm suggesting is to avoid the redundacy and do:
parent.Add(Button(...))

I've done it for some GUI framework where I work encapsulating wxPython.
The drawback is that you need to delay the creation of widgets, which
means some attributes might be stored twice. But it's definitely easier
to use.

I'm not sure it's *that* much easier... all you're saving is one parameter.
Another thing I'm suggesting is a mechanism to not destroy a widget
until it's corresponding python object is destroyed. It's more complex,
but Python has already ownership with refcount, garbage collection, etc.
and I think a truly pythonic GUI framework should use the same ownership
mechanism.

Hm. I'm not sure how wxPython handles that, and if it would be possible to
impose such a system on top of it.
IIRC, method names beginning with lowercase, as all the Python API.

Wax follows the wxPython standard here. Since most Wax controls derive
directly from wxPython classes, it would make little sense to add lowercase
methods to the mix (next to the existing uppercase methods), or to convert them.
It's just that when you work multiple modules, autocompletion for a
module doing a "from wx import *" is a nightmare (and is also slowing
debuggers, since so many symbols are in each module namespace). If wax
becomes big, it would also be a pain. You can do "import wax as w" ;)

I personally like 'from wax import *', kind of like how Tkinter is usually
imported. Either way currently works, though. Should I use the "lazy"
importing (which is admittedly useful), then the star-import would not be
possible anymore, I think.
 
N

Nicolas Fleury

Hans said:
I'm not sure it's *that* much easier... all you're saving is one parameter.

Easier is probably not the good word. It is less redundant and less
error-prone. It has happened to me to make mistakes in ownership of
widgets when copy-pasting code, when these errors would not have occured
if the parent parameter was not passed.

It is also more usable, since you can do things like:
myFrame.SetMenuBar(MenuBar([
Menu("File", [
Item("&New\tCtrl+N", self.onNew),
Menu("Some sub menu...", ...)]
Menu("Edit", ...)]

The problem is that that explicit cross-referencing between parent and
child forces the parent to be created before, removing capabilities like
that one.
Hm. I'm not sure how wxPython handles that, and if it would be possible
to impose such a system on top of it.

I honestly don't know. I guess a solution could be to create a frame in
two passes, and the wx.Frame created after the first pass is used as
parent of everything created in second pass.

Also, the wxPython mechanism could be completely hidden behind the
wrappers. The wrappers can contain all necessary information to create
the widgets, allowing widgets to be created with a parent when addded to
it and even recreated with another parent if added later to something
else. This way the user will not even have to think about the ownership
issue.
Wax follows the wxPython standard here. Since most Wax controls derive
directly from wxPython classes, it would make little sense to add
lowercase methods to the mix (next to the existing uppercase methods),
or to convert them.

Sorry, I though they were complete wrappers as in PythonCard. I totally
agree to keep things that way if wx widgets are inherited.

Regards,
Nicolas
 
H

Hans Nowak

Nicolas said:
Easier is probably not the good word. It is less redundant and less
error-prone. It has happened to me to make mistakes in ownership of
widgets when copy-pasting code, when these errors would not have occured
if the parent parameter was not passed.

Admittedly, having to state the parent-child (or container-child) relationship
twice is redundant. I am still thinking of ways to make that work better.
Maybe I'll post some suggestions on my weblog, so people can discuss it there,
rather than on the newsgroup.
It is also more usable, since you can do things like:
myFrame.SetMenuBar(MenuBar([
Menu("File", [
Item("&New\tCtrl+N", self.onNew),
Menu("Some sub menu...", ...)]
Menu("Edit", ...)]

In fact, a nested list would suffice here to contain the structure of the whole
menu. I have an application that uses just that. Maybe something that can be
added as well.
The problem is that that explicit cross-referencing between parent and
child forces the parent to be created before, removing capabilities like
that one.

But adding capabilities as well... see my example in a previous post.

Cheers,
 
E

Ed Leafe

I beg your pardon for possibly stupid comment---I haven't practice GUI
programming for a long time, especially in Python. However I mostly
prefer declarative approach for the problems like that. Therefore,
wouldn't it be interesting to describe the structure with class and
metaclass mechanism, like:

class MainFrame(FrameDescription):

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

etc.

That's the approach we've take with Dabo (albeit with slightly
different names). In fact, you could even avoid setting the size with a
tuple by typing:

class b1(dabo.ui.dButton):
Height = 60
Width = 40
Caption = "Click Me"

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

OKB (not okblacke)

anton said:
I beg your pardon for possibly stupid comment---I haven't practice
GUI programming for a long time, especially in Python. However I
mostly prefer declarative approach for the problems like that.
Therefore, wouldn't it be interesting to describe the structure
with class and metaclass mechanism, like:

class MainFrame(FrameDescription):

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

I've recently been working on a system that lets you do that kind
of thing. It's a set of metaclasses that wrap the wxPython classes so
you define your GUI with nested class structures. Certain things are
hard here because of the way class definitions are handled in Python,
but I am making progress.

If anyone's interested, you can see an example of what the GUI code
looks like at http://www.brenbarn.net/misc/idealgui.txt . This is code
that actually produces a working program with my current setup. It
won't work for anyone else, of course, because I haven't made my library
available yet. My main goal here, though, is to get it so the code
LOOKS nice, so just seeing how the code looks will give you an idea of
the style.

--
--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
 
N

Neuruss

I'd just like to add a comment, not to start an endless debate on U.S
economic or trade policy...
IMHO what you are experiencing in the U.S is just another sign of the
globalization process, which is bad from an american perspective, but
good from a global one.

For too long, the industrialized countries have enjoy the power of
their competitiveness and technical inovation while, at the same time,
they have been protecting their less competitive sectors such as
agriculture and labor intensive jobs. But this situation led to a club
of rich nations isolated from a mass of third world countries, whose
primary products weren't allowed to enter the rich markets due to very
rigid policy of subsidies and trade barriers.

But how can IBM, Microsoft, HP, and all those monsters keep on growing
without selling to the so called "emerging markets"? By trading with
Mars?
If the rich want to get richer, sooner or later they will have to even
the field, allowing others to rise from missery in order to
incorporate them to the consumption society.

Now you see China, India, Brazil and other countries that are doing
well, improving the condition of their inhabitants, getting them out
of missery and incorporating them to the global market.
Those foreigners buy american products, now more than before because
they have more money, thus improving the profit of the monsters
mentioned above.
Here in latin america we buy these products, and at the same price or
more in US Dollars (not a penny less), don't you think we deserve
something in exchange?
I don't mean humanitarian supplies, I mean more fair and equitable
rules for trading of products, skills and resources.

After a very hard devaluation of our currency, an argentine programmer
is paid 11 dollars less an hour than an indian one. Now, many educated
people, with knowledge of two or more languages and with high tech
skills can aspire to pay the rent and make a living, making 4 or 5x
less than an american counterpart.
These people worked their ass off to have what they're getting now.

Honestly, do you expect them to be sorry for you?
I'm affraid that there's no way back. A highly skilled programmer in
the third world (or any other kind of proffesional) deserves to get a
job if he/she can do it better and cheaper than an american (or
canadian or whatever..) one.
This is the internet age. I hope that it contributes to make the poor
less poor and the rich not so rich, and maybe, in a distant future we
will have a better world for all of us.
 
C

Corey Coughlin

Alright, here's the question I'm going to start asking whenever anyone
starts promoting a new gui for python. Is there an nice gui-driven
gui creation tool to go with this? I realize that you're really happy
with the API and all, but if there were a nice gui maker along with a
nice python ide to go along with it, you'd probably make a lot more
converts. And for once, it'd be nice to see a gui maker that isn't a
thin wrapper of some C++ gui maker and doesn't produce some crappy
non-python data file that another C++ program uses to make a library
or some such bs. Just have it produce a nice python loop or
something, that'd be good. Do that, make it truly cross platform,
free and add a nice python ide, and you're well on your way to making
it the standard python gui.
 
C

Cliff Wells

It's worse than that, Cliff: there's serious reason to fear
that non-price factors might soon work *against* us in the US,
almost as much as they have for us in the past. I see this
running along a couple of lines:
*) "security"-related and DRM-IP-enforcing
export restrictions directly interfere
with our ability to deliver internation-
ally; and

This is actually a reason to change countries rather than lines of work.
The current state of affairs wrt IP in the U.S. is sickening. Of
course, no matter where you go, there's always something that makes you
want to move somewhere else. And if there isn't today, there will be
tomorrow.
*) MS hasn't been alone in habituating
international customers to associate US
software with expense and unreliability.

Hey, let's not get personal <wink>.
 
E

Ed Leafe

Alright, here's the question I'm going to start asking whenever anyone
starts promoting a new gui for python. Is there an nice gui-driven
gui creation tool to go with this? I realize that you're really happy
with the API and all, but if there were a nice gui maker along with a
nice python ide to go along with it, you'd probably make a lot more
converts.

I agree 100%. One of the planned development projects for Dabo is a
true GUI designer. We have several ideas and a few proof-of-concept
attempts, but the major focus on the GUI designer will be after the 0.5
release. The plan is to create a solid basis before adding the exterior
goodies. ;-)

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

Nicolas Fleury

Hans said:
Admittedly, having to state the parent-child (or container-child)
relationship twice is redundant. I am still thinking of ways to make
that work better. Maybe I'll post some suggestions on my weblog, so
people can discuss it there, rather than on the newsgroup.

My suggestion is to do as in Python for normal objects; they exists
because they are referenced. The widget can even be added under
multiple parents; under the hood multiple wx widgets are created.
It is also more usable, since you can do things like:
myFrame.SetMenuBar(MenuBar([
Menu("File", [
Item("&New\tCtrl+N", self.onNew),
Menu("Some sub menu...", ...)]
Menu("Edit", ...)]


In fact, a nested list would suffice here to contain the structure of
the whole menu. I have an application that uses just that. Maybe
something that can be added as well.

Admittedly I did the same thing. But I changed it to something like my
example. Instead of having one piece of code analyzing nested lists or
tuples, everything is delegated to small classes and therefore
expandable by user and more flexible.

It's easier to do that with menus because they are not wx.Window IIRC
and you don't have to pass the parent in constructors. What would be
really cool is to have the same approach for everything:

panel = Panel(
BoxLayout(VERTICAL, [
Label("Some text),
BoxLayout(HORIZONTAL, [
Button("OK", self.onOk),
Button("Cancel", self.onCancel)])]))

What is cool about that approach is that you can do everything with
constructors, but can still do more complex things in mulitple
statements like in wxPython (you can still have add methods). It has
also the advantage to have the capability to present things
hierarchically, as with other suggestions of using metaclasses.
But adding capabilities as well... see my example in a previous post.

The problem with:
b = Button(parent, ..., layout={'expand': 'both', 'border': 2})
is that the constructor of Button is receiving arguments to a layout it
should not know about. The arguments can also be specific/complex for a
certain type of layout. It mean that widgets contructors, in addition
to parent argument, would also need flags for the layout. I see it the
other way, ownership should be specified when doing the composition
itself, and widgets constructors should only take flags for themselves
and their children if they can have one.

Note that I'm describing what kind of API I would like to use, not
necessarily the one you want to make;)

Cheers,
Nicolas
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Staff online

Members online

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,012
Latest member
RoxanneDzm

Latest Threads

Top