Python and GUI

[Uwe Grauer]

Re: dabo framework dependancies

daniel gadenne wrote:

Paul McNett wrote:

>Shameless plug: consider using Dabo on top of wxPython - we feel it
>makes wxPython even easier and more pythonic, but admittedly there's a
>bit of a learning curve there too. Even though Dabo is a full
>application framework originally meant for desktop database
>applications , it is modular and you can choose to only use the UI
>bits... http://dabodev.com

>
>
Hi Paul,
>
I'm considering moving over to dabo for wxpython development.
However I do not write traditional database applications
à la foxpro (I'm a 20 years user of fox...) anymore.
Only xml-fed applications.
>
I'm a bit hesitant to jump onboard since dabo seemns to carry
over its own lot of database connectivity dependancy.
>
Can you reasonably use dabo for plain datafree application?
>
François
>
>

Yes, the only database dependency is sqlite as a store for app-preferences.
But even this could get changed easily.

Uwe

[Peter Decker]

Re: dabo framework dependancies

On 5/22/07, daniel gadenne <daniel.gadenne @caramail.frwro te:

I'm considering moving over to dabo for wxpython development.
However I do not write traditional database applications
à la foxpro (I'm a 20 years user of fox...) anymore.
Only xml-fed applications.
>
I'm a bit hesitant to jump onboard since dabo seemns to carry
over its own lot of database connectivity dependancy.
>
Can you reasonably use dabo for plain datafree application?

That's exactly how I use it. I write apps that don't use database
servers, and don't have any database programs installed. I just want
the dabo.ui stuff, since it makes wxPython so easy to work with.

--

# p.d.

[Paul McNett]

Re: dabo framework dependancies

Peter Decker wrote:

On 5/22/07, daniel gadenne <daniel.gadenne @caramail.frwro te:
>

>I'm considering moving over to dabo for wxpython development.
>However I do not write traditional database applications
>à la foxpro (I'm a 20 years user of fox...) anymore.
>Only xml-fed applications.
>>
>I'm a bit hesitant to jump onboard since dabo seemns to carry
>over its own lot of database connectivity dependancy.
>>
>Can you reasonably use dabo for plain datafree application?

>
That's exactly how I use it. I write apps that don't use database
servers, and don't have any database programs installed. I just want
the dabo.ui stuff, since it makes wxPython so easy to work with.

Dabo has three main modules: db, biz, and ui, and an overarching
application object. Every class descends from an abstract dObject. For
database apps, you'd typically set some connection information in the db
layer, put all your business code in the biz layer, and define your GUI
in the (you guessed it) ui layer. You can certainly do what Peter has
done and only use the ui layer and application object. I've done this
myself and if I ever had to code a non-database UI that's probably what
I'd do, too. Although I have to admit I can't really picture an
application that doesn't need to save data. Here's a simple example that
puts up a textbox:

"""
import dabo
dabo.ui.loadUI( "wx")

app = dabo.dApp()
app.setup()

frm = app.MainForm
tb = dabo.ui.dTextBo x(frm, Value="Type in here", FontBold=True)

app.start()
"""

You can easily define your own subclasses, too:

"""
import dabo
dabo.ui.loadUI( "wx")

class MyRadioList(dab o.ui.dRadioList ):
def initProperties( self):
self.Choices = ["Snakes", "Bees", "Fishes"]

def onHit(self, evt):
print "Radio choice '%s' selected." % self.Value

app = dabo.dApp()
app.setup()
frm = app.MainForm
rl = MyRadioList(frm )
app.start()
"""

So, yes, you can reasonably use Dabo even if you have no traditional
database in the mix.

--
pkm ~ http://paulmcnett.com

[Brian Blais]

Re: Python and GUI

Peter Decker wrote:

On 5/21/07, Paul McNett <p@ulmcnett.com wrote:
>

>Shameless plug: consider using Dabo on top of wxPython - we feel it
>makes wxPython even easier and more pythonic, but admittedly there's a
>bit of a learning curve there too. Even though Dabo is a full
>application framework originally meant for desktop database
>applications , it is modular and you can choose to only use the UI
>bits... http://dabodev.com

>
I second this. I used (and struggled!) with wxPython for over a year.
The results were great, but I hated coding it. I switched to the Dabo
UI wrapper, and stuff that used to take me a day to create is now done
in an hour or two.
>

Hello,

I'd like to ask the Python community about this, because it seems to me that there is
a real need that is not being met very effectively. Almost everyone agrees that
wxPython looks great and is very powerful, and for full-fledged cross-platform
applications is nearly the best, if not *the* best, choice as far as *function* and
*look* are concerned. The next sentence out of Python programmers seems to be
"...but wx is written in C++ and definitely shows, even in the Python port". It's
just not very pythonic.

Then there is Dabo, which I personally have had problems with. I am looking for a
pythonic, professional looking GUI framework. I first tried dabo with python 2.4,
and had to install sqlite, which seemed a bit odd for trying to just get a GUI
framework...I understand why, but when you're looking for one thing, having it tied
to a completely different thing feels a little strange. I never got it working in
Python2.5, either on Linux or OS X, and the problem is most definitely mine and I
didn't have the patience to debug it. I am really not trying to diss dabo here,
because there enough people who swear by it, that it must be doing many things right.

My problem with Dabo is not what it is, it is what I am looking for...a pythonic GUI
framework. Coming from Unix, I generally feel that a program should try to do one
thing, and one thing well. To mix really different functionality seems to me to be a
bad idea. If you can use the GUI parts separately, why not package it separately?
One might find a lot of users who only what that.

Finally, consider wax (http://zephyrfalcon.org/labs/wax.html). In my view, this is
*exactly* what python needs, and its not being maintained anymore as far as I can
tell. What I like about it is:

1) it is small...I can include the entire wax distribution in my app with only a 780k
footprint.
2) it is a very thin layer on wx, so when something doesn't quite work, I can
immediately fall back onto wx, mixing and matching wax and wx objects. it's just
that the wax objects have more pythonic calling and use properties


Is there a reason that the port of wxPython doesn't include wax, or something
similar? It would seem pretty straightforward , when porting the wx to Python, to
simply include such a wrapper. I wish I were more clever, and had more time, to take
over the maintenance of wax because I think it is the most straightforward ,
practical, and pythonic solution out there.


Do others think like me here?


thanks,

Brian Blais


--
-----------------

bblais@bryant.e du

http://web.bryant.edu/~bblais

[Grant Edwards]

Re: Python and GUI

On 2007-05-24, Brian Blais <bblais@bryant. eduwrote:

I'd like to ask the Python community about this, because it
seems to me that there is a real need that is not being met
very effectively. [...] "...but wx is written in C++ and
definitely shows, even in the Python port". It's just not
very pythonic.
>
Then there is Dabo, which I personally have had problems with.
[...]

I haven't tried Dabo, so I can't comment.

Finally, consider wax (http://zephyrfalcon.org/labs/wax.html).
In my view, this is *exactly* what python needs, and its not
being maintained anymore as far as I can tell. What I like
about it is:
>
1) it is small...I can include the entire wax distribution in
my app with only a 780k footprint.
>
2) it is a very thin layer on wx, so when something doesn't
quite work, I can immediately fall back onto wx, mixing and
matching wax and wx objects. it's just that the wax
objects have more pythonic calling and use properties

I did try wax, and I liked it. It seemed much more "Pythonic"
than bare wxPython, and resulted in cleaner, easier-to-read
code. When I tried it, it was still early in its development,
and there were still parts of it that needed to be fleshed out
(a lot of stuff was still unwrapped). I contributed a little
bit of code (wrapping one or two more things), but I didn't
have enough time at that point to wrap and debug all the things
I needed, so I switched back to plain wxPython (I had a mixture
of wax and wx for a little while, but I that annoyed me too
much).

Is there a reason that the port of wxPython doesn't include
wax, or something similar? It would seem pretty
straightforward , when porting the wx to Python, to simply
include such a wrapper. I wish I were more clever, and had
more time, to take over the maintenance of wax because I think
it is the most straightforward , practical, and pythonic
solution out there.
>
Do others think like me here?

Yes. I thought wax was a good idea, and there was a a good
start on an implementation.

--
Grant Edwards grante Yow! My nose feels like a
at bad Ronald Reagan movie ...
visi.com

[Ed Leafe]

Re: Python and GUI

On May 24, 2007, at 10:22 AM, Brian Blais wrote:

Then there is Dabo, which I personally have had problems with. I
am looking for a
pythonic, professional looking GUI framework. I first tried dabo
with python 2.4,
and had to install sqlite, which seemed a bit odd for trying to
just get a GUI
framework...I understand why, but when you're looking for one
thing, having it tied
to a completely different thing feels a little strange.

FWIW, we made that decision only after Python itself committed to
including SQLite as part of the standard distribution. While there
may have been some problems during the transition, such as you
apparently had, it made for a much better product in the long run.

I never got it working in
Python2.5, either on Linux or OS X, and the problem is most
definitely mine and I
didn't have the patience to debug it. I am really not trying to
diss dabo here,
because there enough people who swear by it, that it must be doing
many things right.

I checked the archives, and didn't find any messages from you asking
for help. We know that the documentation is far from complete, and
the installation process can be problematic, but one thing we pride
ourselves on is quick response to help requests, and then fixing
whatever it was that caused the initial problem.

My problem with Dabo is not what it is, it is what I am looking
for...a pythonic GUI
framework. Coming from Unix, I generally feel that a program
should try to do one
thing, and one thing well. To mix really different functionality
seems to me to be a
bad idea. If you can use the GUI parts separately, why not package
it separately?
One might find a lot of users who only what that.

We've thought about doing exactly that, but to be honest, it would
take a large investment of time without a corresponding increase in
value. Right now all you have to do is install Dabo, and then just
use the dabo.ui classes. You never need to touch the database or
business object layers if you don't want to.

Also, I don't feel that we are "mixing different functionality".
Rather, we are creating an integrated environment for those wishing
to create rich desktop apps. Nearly all such apps require displaying
and persisting information, and that's what Dabo is designed to do.
If you don't need persistent information, the display stuff works
just fine.

I'd encourage anyone who is curious about what dabo.ui offers to
view the part of my recent PyCon presentation that discusses exactly
this topic. Take a look at http://dabodev.com/pycon2007?3 to see an
example of simpler and more Pythonic Dabo code is compared to what
you would have to write in either raw wxPython or even Wax.

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com

[Russell E. Owen]

Re: Python and GUI

In article <1179761984.704 369.116310@b40g 2000prd.googleg roups.com>,
sdoty044@gmail. com wrote:

Just wondering on what peoples opinions are of the GUIs avaiable for
Python?
>
All I am doing is prompting users for some data (listbox, radio
buttons, text box, ect...). Then I will have some text output, maybe
a scrolling text message as things are happening.
>
I have some minor things I need to do, for example, if Checkbutton X
is clicked, I need to disable TextBox Y, and I would like to display
the scrolling text (output)
>
Ultimately, is it worth downloading and learning some of the packages
avaiable for Python, or should I just stick to the Tkinter stuff that
is included.
>
More specifically, has anyone used the Qt stuff for python, easy to
use?

My opinion is that Tkinter is perfect for the job you describe. It is
easy to use, fairly pythonic (an issue with some competing toolkits) and
does not require any fancy installation.

If you want a very professional and "native" look then you have to work
harder. Options include Tkinter with tile, wxPython, PyQt and several
others.

-- Russell

[Stef Mientki]

Re: Python and GUI

>

Finally, consider wax (http://zephyrfalcon.org/labs/wax.html). In my
view, this is *exactly* what python needs, and its not being maintained
anymore as far as I can tell. What I like about it is:
>
1) it is small...I can include the entire wax distribution in my app
with only a 780k footprint.
2) it is a very thin layer on wx, so when something doesn't quite work,
I can immediately fall back onto wx, mixing and matching wax and wx
objects. it's just that the wax objects have more pythonic calling and
use properties
>

Sorry I don't know wax,
but I wonder "a GUI designer without screenshots",
is that Pythonic ;-)

cheers,
Stef

[Grant Edwards]

Re: Python and GUI

On 2007-05-24, Stef Mientki <S.Mientki-nospam@mailbox. kun.nlwrote:

>Finally, consider wax (http://zephyrfalcon.org/labs/wax.html). In my
>view, this is *exactly* what python needs, and its not being maintained
>anymore as far as I can tell. What I like about it is:
>>
>1) it is small...I can include the entire wax distribution in
> my app with only a 780k footprint.
>>
>2) it is a very thin layer on wx, so when something doesn't quite work,
> I can immediately fall back onto wx, mixing and matching wax and wx
> objects. it's just that the wax objects have more pythonic calling and
> use properties

>
Sorry I don't know wax, but I wonder "a GUI designer without
screenshots", is that Pythonic ;-)

Uh, wha?

Who are you quoting about the screenshots?

Wax isn't a "GUI designer", and I'm a bit lost as to what
screenshots have to do with the topic at hand.

--
Grant Edwards grante Yow! I'm changing the
at CHANNEL ... But all I get
visi.com is commercials for "RONCO
MIRACLE BAMBOO STEAMERS"!

[Stef Mientki]

Re: Python and GUI

Grant Edwards wrote:

On 2007-05-24, Stef Mientki <S.Mientki-nospam@mailbox. kun.nlwrote:
>

>>Finally, consider wax (http://zephyrfalcon.org/labs/wax.html). In my
>>view, this is *exactly* what python needs, and its not being maintained
>>anymore as far as I can tell. What I like about it is:
>>>
>>1) it is small...I can include the entire wax distribution in
>> my app with only a 780k footprint.
>>>
>>2) it is a very thin layer on wx, so when something doesn't quite work,
>> I can immediately fall back onto wx, mixing and matching wax and wx
>> objects. it's just that the wax objects have more pythonic calling and
>> use properties

>Sorry I don't know wax, but I wonder "a GUI designer without
>screenshots" , is that Pythonic ;-)

>
Uh, wha?
>

quote original message:
"I am looking for a pythonic, professional looking GUI framework."

Who are you quoting about the screenshots?

Sorry, maybe I'm not Pythonic enough,
but talking about "GUI framework",
the first thing I want to see are screenshots.

cheers,
Stef Mientki

>
Wax isn't a "GUI designer", and I'm a bit lost as to what
screenshots have to do with the topic at hand.
>

[Grant Edwards]

Re: Python and GUI

On 2007-05-24, Stef Mientki <S.Mientki-nospam@mailbox. kun.nlwrote:

>>>Finally, consider wax (http://zephyrfalcon.org/labs/wax.html). In my
>>>view, this is *exactly* what python needs, and its not being maintained
>>>anymore as far as I can tell. What I like about it is:
>>>>
>>>1) it is small...I can include the entire wax distribution in
>>> my app with only a 780k footprint.
>>>>
>>>2) it is a very thin layer on wx, so when something doesn't quite work,
>>> I can immediately fall back onto wx, mixing and matching wax and wx
>>> objects. it's just that the wax objects have more pythonic calling and
>>> use properties
>>>
>>Sorry I don't know wax, but I wonder "a GUI designer without
>>screenshots ", is that Pythonic ;-)

>>
>Uh, wha?

>
quote original message:
"I am looking for a pythonic, professional looking GUI framework."

>Who are you quoting about the screenshots?

Sorry, maybe I'm not Pythonic enough, but talking about "GUI
framework", the first thing I want to see are screenshots.

0) While wax is a GUI framework, it is not a GUI designer, so I
was wondering who you were quoting when you wrote "a GUI
designer [...]".

1) Wax doesn't have any effect on the appearance of
applications, only on the appearance of the Python code used
to write the applications. So, screenshots are irrelevent.

If you want screenshots of what wxWidgets apps look like,
there are lots of them at wxWidgets.org. But, since
wxWidgets generally uses "native" widgets, wxWidget apps
look pretty much like any other app on the given platform.

--
Grant Edwards grante Yow! WHOA!! Ken and Barbie
at are having TOO MUCH FUN!!
visi.com It must be the NEGATIVE
IONS!!

[Stef Mientki]

Re: Python and GUI

>

>Sorry, maybe I'm not Pythonic enough, but talking about "GUI
>framework", the first thing I want to see are screenshots.

>
0) While wax is a GUI framework, it is not a GUI designer, so I
was wondering who you were quoting when you wrote "a GUI
designer [...]".
>
1) Wax doesn't have any effect on the appearance of
applications, only on the appearance of the Python code used
to write the applications. So, screenshots are irrelevent.
>
If you want screenshots of what wxWidgets apps look like,
there are lots of them at wxWidgets.org. But, since
wxWidgets generally uses "native" widgets, wxWidget apps
look pretty much like any other app on the given platform.
>

Thanks for the information,
didn't know that.

cheers,
Stef Mientki

[matt.newville@gmail.com]

Re: Python and GUI

Do others think like me here?

Yes!! I agree completely: Wax is not only a fantastic idea, but a very
good start at an implementation of that idea.

--Matt Newville

[daniel gadenne]

Re: dabo framework dependancies

Hi Paul, Peter, Uwe

Thank to the three of you for your
clear answers :)

[rzed]

Re: Python and GUI

Brian Blais <bblais@bryant. eduwrote in
news:mailman.81 19.1180016569.3 2031.python-list@python.org :

[...]

Finally, consider wax (http://zephyrfalcon.org/labs/wax.html).
In my view, this is *exactly* what python needs, and its not
being maintained anymore as far as I can tell. What I like
about it is:
>
1) it is small...I can include the entire wax distribution in my
app with only a 780k
footprint.
2) it is a very thin layer on wx, so when something doesn't
quite work, I can immediately fall back onto wx, mixing and
matching wax and wx objects. it's just that the wax objects
have more pythonic calling and use properties
>
>
Is there a reason that the port of wxPython doesn't include wax,
or something similar? It would seem pretty straightforward ,
when porting the wx to Python, to simply include such a wrapper.
I wish I were more clever, and had more time, to take over the
maintenance of wax because I think it is the most
straightforward , practical, and pythonic solution out there.
>
>
Do others think like me here?
>

I certainly do. Whether wax is the particular solution or not,
something very like it should be. Something like this was tried at
one time (Anygui) and the general consensus seems to be that it
doesn't work as an approach because the packages are too
different. I think that it's past time to revisit that conclusion.

It would be very useful to a user of the Language we call Python
to be able to write GUI code without regard to the back-end
package. If there were a standard Python GUI API (call it the PGA,
say) that be the target for app developers, they wouldn't have to
worry about the back end. The PGA would have to be flexible enough
to handle incompatibiliti es among the various approaches to
displaying widgets and text. In order for that to happen, some
kind of meeting of minds (among those who now deal with the murky
middle between gui packages and python) would have to take place.
A standard would have to be hammered out and then used.

The standard would have to allow for generic calls for tasks that
any reasonable GUI would have to handle. It would also have to
provide for system-specific calls for those things that each
package might require uniquely. The interface to the system-
specific stuff should itself be the same regardless of the back
end. What I mean by this is that, where wax's limitations are
overcome by dropping to wx directly, there should instead by a PGA
winsys() call that permits passing command strings, values, or
whatever in a dict-like object that would be permit the pga2wx
interface to create the specific calls it needs. When the back end
changes to Qt, the pga2Qt interface would make the translation
instead. The code from the app programmer should not have to
change, except maybe to add another item or items to the winsys
dict.

I also think there should something similar for an interface for
Python database access (PDBA). Anydb might not be the solution,
but it could be. It would take cleverness (which abounds in the
Python community), determination (which may not be in such
abundance) and project coordination for either of these projects
to come to fruition. A summer of code kind of thing would provide
a good initial push, and some sprints could move things along at a
good clip. Wax, anygui, and anydb seem to be acceptable starting
points, but the key thing is to get agreement from key players
(like the developers of wxPython, dabo, PythonCard, and so on) to
agree that this is a good direction to go in, and to try to work
out the requirements for a flexible PGA and PDBA. I'm sure that
the approach could produce usable results in short order, and then
attack the remaining limitations over time.

Do I think this is going to happen? No.

There are two overlapping things we call Python: the Language and
the Package. The Language comes from Guido and a few others, but
the Package comes from many sources, mostly volunteers. The GUI
interfaces come from many such sources, each with a different view
of what constitutes a good Pythonic interface. Having put a lot of
time and effort into getting their version up and running, they're
not about to change for some abstract reason, but nonetheless, I
do believe that the Language of Python should have a GUI API
defined, and that the Package of Python should accommodate to
that. Unless that happens, we'll see more of what we now see:
continual questions about what is the best GUI or the best
Database. Because once you start building an app, you commit to
the syntax of the package and you are no longer (in my view)
coding in Python, but in that subset that includes the GUI Package
of your choice.

--
rzed