As anyone knows, the state of Python GUI programming is a little
fractured at this time, with many toolkits, wrappers and meta-wrappers
dead and alive, with or without documentation.
I've come across two projects that have the appeal of striving for
simple, pythonic APIs: PyGUI and wax. The latter is a wrapper around
wxPython. It is lacking documentation but actually quite usable and
concise. The other, PyGUI, has an even nicer API and more docs but has
relatively few widgets implemented at this time. It also strives for
compatibility with several toolkits (two at this time), which I think
is the right idea.
So far, development of PyGUI seems to be a one-man effort, and it may
be slowed down by the attempt to develop the API and the
implementations concurrently. Could it be useful to uncouple the two,
such that the API would be specified ahead of the implementation? This
might make it easier for people to contribute implementation code and
maybe port the API to additional toolkits. It seems that this approach
has been quite successful in case of the Python database API. That API
defines levels of compliance, which might be a way of accommodating
different GUI toolkits as well.
I may be underestimating the difficulties of my proposed approach - I
don't have much practical experience with GUI programming myself.
Best, Michael
37  8998 
Michael Palmer schrieb:
As anyone knows, the state of Python GUI programming is a little
fractured at this time, with many toolkits, wrappers and meta-wrappers
dead and alive, with or without documentation.
I've come across two projects that have the appeal of striving for
simple, pythonic APIs: PyGUI and wax. The latter is a wrapper around
wxPython. It is lacking documentation but actually quite usable and
concise. The other, PyGUI, has an even nicer API and more docs but has
relatively few widgets implemented at this time. It also strives for
compatibility with several toolkits (two at this time), which I think
is the right idea.
I disagree with that. Meta-wrappers like this will always suffer from
problems, as they have difficulties providing a consistent api. For
example wx is said to be very windows-toolkit-centric in it's API. Yes I
know that it works under Linux with GTK, but it does not come as natural .
So far, development of PyGUI seems to be a one-man effort, and it may
be slowed down by the attempt to develop the API and the
implementations concurrently. Could it be useful to uncouple the two,
such that the API would be specified ahead of the implementation? This
might make it easier for people to contribute implementation code and
maybe port the API to additional toolkits. It seems that this approach
has been quite successful in case of the Python database API. That API
defines levels of compliance, which might be a way of accommodating
different GUI toolkits as well.
I may be underestimating the difficulties of my proposed approach - I
don't have much practical experience with GUI programming myself.
I think you do. The reason for the various toolkits is not because of
python - it's the proliferation of toolkits that exist out there. As
long as none of these is "the winner" (and it doesn't look is if that's
to happen soon), I doubt that one API to rule them all will exist - they
all have their different strengths and weaknesses, and a python-API
should reflect these.
Diez
On Sep 3, 12:57 pm, "Diez B. Roggisch" <de...@nospam.web.dewrote:
Michael Palmer schrieb:
The other, PyGUI, has an even nicer API and more docs but has
relatively few widgets implemented at this time. It also strives for
compatibility with several toolkits (two at this time), which I think
is the right idea.
I disagree with that. Meta-wrappers like this will always suffer from
problems, as they have difficulties providing a consistent api. For
example wx is said to be very windows-toolkit-centric in it's API. Yes I
know that it works under Linux with GTK, but it does not come as natural .
wax actually does a nice job at wrapping wxPython with a cleaner API.
So far, development of PyGUI seems to be a one-man effort, and it may
be slowed down by the attempt to develop the API and the
implementations concurrently. Could it be useful to uncouple the two,
such that the API would be specified ahead of the implementation? This
might make it easier for people to contribute implementation code and
maybe port the API to additional toolkits. It seems that this approach
has been quite successful in case of the Python database API. That API
defines levels of compliance, which might be a way of accommodating
different GUI toolkits as well.
I may be underestimating the difficulties of my proposed approach - I
don't have much practical experience with GUI programming myself.
I think you do. The reason for the various toolkits is not because of
python - it's the proliferation of toolkits that exist out there.
Right. But that is similar to the situation with relational databases.
There are so many of them that it's impossible to include an adapter
to each of them in the stdlib. The next best thing is to provide a
high-level API that abstracts away the differences.
As long as none of these is "the winner" (and it doesn't look is if that's
to happen soon), I doubt that one API to rule them all will exist - they
all have their different strengths and weaknesses, and a python-API
should reflect these.
I rather think that a standard API would cover a reasonable subset -
it should NOT contain the idiosyncrasies of each individual toolkit.
The anygui project, which has been dormant for a while, is another
attempt at a high-level api. Apparently, it tried to implement
backends for a lot of toolkits - which again may have been to
ambitious an agenda. Maybe someone who was involved in that project
might provide some insight.
Michael Palmer schrieb:
>I disagree with that. Meta-wrappers like this will always suffer from
problems, as they have difficulties providing a consistent api. For
example wx is said to be very windows-toolkit-centric in it's API. Yes I
know that it works under Linux with GTK, but it does not come as natural .
wax actually does a nice job at wrapping wxPython with a cleaner API.
wax wraps wx. It does not wrap PyQt, Tk, win32, GTK and whatnot. That
was what I was talking about.
Right. But that is similar to the situation with relational databases.
There are so many of them that it's impossible to include an adapter
to each of them in the stdlib. The next best thing is to provide a
high-level API that abstracts away the differences.
>As long as none of these is "the winner" (and it doesn't look is if that's
to happen soon), I doubt that one API to rule them all will exist - they
all have their different strengths and weaknesses, and a python-API
should reflect these.
I rather think that a standard API would cover a reasonable subset -
it should NOT contain the idiosyncrasies of each individual toolkit.
And thus reduce the usability massively. A reasonable subset is already
included in python, with tkinter, available on a wide range of plattforms.
Yet still people strive for the various other toolkits, because they
miss richer widgets, gui-designers (an important topic you don't cover
at all) or e.g. multi-threading capabilities.
The anygui project, which has been dormant for a while, is another
attempt at a high-level api. Apparently, it tried to implement
backends for a lot of toolkits - which again may have been to
ambitious an agenda. Maybe someone who was involved in that project
might provide some insight.
Sure, that would be interesting.
Diez
Michael Palmer wrote:
As anyone knows, the state of Python GUI programming is a little
fractured at this time, with many toolkits, wrappers and meta-wrappers
dead and alive, with or without documentation.
How about Dabo? http://www.dabodev.com/
--
--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
Michael Palmer wrote:
So far, development of PyGUI seems to be a one-man effort, and it may
be slowed down by the attempt to develop the API and the
implementations concurrently. Could it be useful to uncouple the two,
such that the API would be specified ahead of the implementation?
I'm not sure that would work very well. I don't think
it's possible to invent a good API for something as
complex as a GUI toolkit in the absence of experience
using it, so the API has to evolve in parallel with at
least one implementation, and with real applications
that actually use the features concerned.
Also, the features that go into the PyGUI API are partly
determined by what is available in the underlying target
libraries. I don't want to end up with things in the
API specification that are too difficult or unwieldy
to implement on some of the target platforms. I also
don't want one implementation to get too far ahead of
the others, for the same reason.
If anyone wants to help, what's needed most right now
is a good native Windows implementation. One or two
people claimed to be working on that some time ago,
but I haven't heard from them recently. For the reasons
I mentioned above, I'm reluctant to forge ahead with
too many new features until a native Windows version
exists.
--
Greg
On 3 Sep., 18:34, Michael Palmer <m_palme...@yahoo.cawrote:
As anyone knows, the state of Python GUI programming is a little
fractured at this time, with many toolkits, wrappers and meta-wrappers
dead and alive, with or without documentation.
A few thoughts.
1) This topic is discussed here every few months. While some kind of
AnyGUI is theoretically very elegant it hasn't worked out well in
practice: GUI libs are huge and heterogeneous. It's much unlike
building an API-layer on top of SQL. Moreover I'd like to ask whether
the fragmentation turns out to be that much of a problem in practice?
2) Tcl/Tk might have a revival due to the new Tk-theme engine in
version 8.5. http://www.tcl.tk/software/tcltk/8.5.tml http://wiki.tcl.tk/13636
Chances are Tkinter widgets will not look like early '90s legacy
anymore.
3) Following the public rumor mill and the latest hype RIA i.e. the
merge of web- and desktop applications with systems like Adobe AIR,
JavaFX, Google Gears and MS Silverlight is the future of frontend
development. With the exception of IronPython and Silverlight, Python
hasn't even entered this game and no one knows if it ever will.
Ciao, Kay
On 2008-09-04 07:49, Kay Schluehr wrote:
3) Following the public rumor mill and the latest hype RIA i.e. the
merge of web- and desktop applications with systems like Adobe AIR,
JavaFX, Google Gears and MS Silverlight is the future of frontend
development. With the exception of IronPython and Silverlight, Python
hasn't even entered this game and no one knows if it ever will.
Actually, it has already and quite some time ago: http://www.artima.com/weblogs/viewpo...?thread=208528
The recipe is simple: use Python for the business logic, database
interfacing, etc and have it talk to a Flex front-end via XML-RPC
or REST.
As a nice side-effect, this also results in a better separation
between GUI and backend, effectively making the solution future-proof
and easy to adapt to other front-end technologies.
We've been working with this approach for almost a year now and
so far never had to look back.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Sep 04 2008)
>>Python/Zope Consulting and Support ... http://www.egenix.com/
mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
__________________________________________________ ______________________
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
On 4 Sep., 10:31, "M.-A. Lemburg" <m...@egenix.comwrote:
On 2008-09-04 07:49, Kay Schluehr wrote:
3) Following the public rumor mill and the latest hype RIA i.e. the
merge of web- and desktop applications with systems like Adobe AIR,
JavaFX, Google Gears and MS Silverlight is the future of frontend
development. With the exception of IronPython and Silverlight, Python
hasn't even entered this game and no one knows if it ever will.
Actually, it has already and quite some time ago:
http://www.artima.com/weblogs/viewpo...?thread=208528
The recipe is simple: use Python for the business logic, database
interfacing, etc and have it talk to a Flex front-end via XML-RPC
or REST.
Python is still server-side in this scenario and plays no role in UI
definitions. So one doesn't get more than e.g. Django apps that
respond to HTTP requests triggered by JavaScript forms except that
JavaScript+HTML+Browser is replaced by Flex = AS3+MXML+FlashPlayer.
The role of Python is somewhat arbitrary. This could change only if
Python becomes a client side language executed by AVM, V8 etc. like
IronPython in Silverlight.
About separating UI from application logics by assigning functionality
to different general purpose languages I have to admit that I don't
think it is such a great idea ...
On 2008-09-04 11:14, Kay Schluehr wrote:
On 4 Sep., 10:31, "M.-A. Lemburg" <m...@egenix.comwrote:
>On 2008-09-04 07:49, Kay Schluehr wrote:
>>3) Following the public rumor mill and the latest hype RIA i.e. the
merge of web- and desktop applications with systems like Adobe AIR,
JavaFX, Google Gears and MS Silverlight is the future of frontend
development. With the exception of IronPython and Silverlight, Python
hasn't even entered this game and no one knows if it ever will.
Actually, it has already and quite some time ago:
http://www.artima.com/weblogs/viewpo...?thread=208528
The recipe is simple: use Python for the business logic, database
interfacing, etc and have it talk to a Flex front-end via XML-RPC
or REST.
Python is still server-side in this scenario and plays no role in UI
definitions.
That depends on how you design the application. It is well possible
to have Python drive the GUI by sending the required details to
the Flex front-end via XML (ie. data-driven GUIs).
So one doesn't get more than e.g. Django apps that
respond to HTTP requests triggered by JavaScript forms except that
JavaScript+HTML+Browser is replaced by Flex = AS3+MXML+FlashPlayer.
You really can't compare the Flex stack to an AJAX stack. Flex
has a lot more to offer for GUI programming than AJAX, it also
doesn't suffer from the problems of AJAX having to support several
different sets of browser or library bugs.
We switched from an AJAX approach to a Flex-based approach last year
and never even considered moving back again.
The role of Python is somewhat arbitrary. This could change only if
Python becomes a client side language executed by AVM, V8 etc. like
IronPython in Silverlight.
About separating UI from application logics by assigning functionality
to different general purpose languages I have to admit that I don't
think it is such a great idea ...
In my experience, Flex + Python gives you the best of both worlds,
the nice GUI features of Flex and the efficiency of Python for the
business logic.
A long time ago, there was a Python plugin for Netscape
which allowed you to run Python straight in the browser. Perhaps
it's time to revive such an idea... but then you're still missing
out on the GUI part, since you're still stuck with what the
browser has to offer in terms of widget support.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Sep 04 2008)
>>Python/Zope Consulting and Support ... http://www.egenix.com/
mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
__________________________________________________ ______________________
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
On 2008-09-04 12:57, Banibrata Dutta wrote:
On Thu, Sep 4, 2008 at 3:45 PM, M.-A. Lemburg <ma*@egenix.comwrote:
>On 2008-09-04 11:14, Kay Schluehr wrote:
>>On 4 Sep., 10:31, "M.-A. Lemburg" <m...@egenix.comwrote:
On 2008-09-04 07:49, Kay Schluehr wrote:
3) Following the public rumor mill and the latest hype RIA i.e. the
merge of web- and desktop applications with systems like Adobe AIR,
JavaFX, Google Gears and MS Silverlight is the future of frontend
development. With the exception of IronPython and Silverlight, Python
hasn't even entered this game and no one knows if it ever will.
Actually, it has already and quite some time ago:
http://www.artima.com/weblogs/viewpo...?thread=208528
The recipe is simple: use Python for the business logic, database
interfacing, etc and have it talk to a Flex front-end via XML-RPC
or REST.
Python is still server-side in this scenario and plays no role in UI
definitions.
That depends on how you design the application. It is well possible
to have Python drive the GUI by sending the required details to
the Flex front-end via XML (ie. data-driven GUIs).
>>So one doesn't get more than e.g. Django apps that
respond to HTTP requests triggered by JavaScript forms except that
JavaScript+HTML+Browser is replaced by Flex = AS3+MXML+FlashPlayer.
You really can't compare the Flex stack to an AJAX stack. Flex
has a lot more to offer for GUI programming than AJAX, it also
doesn't suffer from the problems of AJAX having to support several
different sets of browser or library bugs.
We switched from an AJAX approach to a Flex-based approach last year
and never even considered moving back again.
The approach does seem quite impressive, but isn't Flex's platform
neutrality quite over-rated ? I mean after-all, it assumes that Flex is
available for and available on the platform. Flex today is not yet so
ubiquitous as the JRE...
Since Flex is compiled to Flash and runs inside the Flash player, it
is fairly easy to get Flex apps running. You do have to have the
Flash9 player installed and the default minimum is 9.0.115.0 for
Flex builder 3.
Are there some established best-practices on how to package such
applications -- s.a. shipping with its's own Flex runtime, offer-download if
missing etc. ? What happens if owner of target machine decides to upgrade
their version of Flex, will it impact the application package in anyway, and
render rest of it "non-upgradable" ?
So far we have not had any such problems, but that could change when
Flash10 starts to ship, of course.
We currently ship the application as a server application. The only
requirement on the client side is having a browser with Flash9
installed. Pointing the browser at the server will then load the
compiled Flex application (as .swf file).
An alternative approach is bundling the client as AIR application
which then runs as stand-alone app on the client side, but we
haven't tried that yet.
>>The role of Python is somewhat arbitrary. This could change only if
Python becomes a client side language executed by AVM, V8 etc. like
IronPython in Silverlight.
About separating UI from application logics by assigning functionality
to different general purpose languages I have to admit that I don't
think it is such a great idea ...
In my experience, Flex + Python gives you the best of both worlds,
the nice GUI features of Flex and the efficiency of Python for the
business logic.
A long time ago, there was a Python plugin for Netscape
which allowed you to run Python straight in the browser. Perhaps
it's time to revive such an idea... but then you're still missing
out on the GUI part, since you're still stuck with what the
browser has to offer in terms of widget support.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Sep 04 2008)
>>>>Python/Zope Consulting and Support ... http://www.egenix.com/
mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
_________________________________________________ _______________________
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
--
http://mail.python.org/mailman/listinfo/python-list
------------------------------------------------------------------------
--
http://mail.python.org/mailman/listinfo/python-list
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Sep 04 2008)
>>Python/Zope Consulting and Support ... http://www.egenix.com/
mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
__________________________________________________ ______________________
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
On Wed, Sep 3, 2008 at 11:57 AM, Diez B. Roggisch <de***@nospam.web.dewrote:
Michael Palmer schrieb:
>>
As anyone knows, the state of Python GUI programming is a little
fractured at this time, with many toolkits, wrappers and meta-wrappers
dead and alive, with or without documentation.
I've come across two projects that have the appeal of striving for
simple, pythonic APIs: PyGUI and wax. The latter is a wrapper around
wxPython. It is lacking documentation but actually quite usable and
concise. The other, PyGUI, has an even nicer API and more docs but has
relatively few widgets implemented at this time. It also strives for
compatibility with several toolkits (two at this time), which I think
is the right idea.
I disagree with that. Meta-wrappers like this will always suffer from
problems, as they have difficulties providing a consistent api. For example
wx is said to be very windows-toolkit-centric in it's API. Yes I know that
it works under Linux with GTK, but it does not come as natural .
With all due respect, it seems like you are not terribly familiar with
wxPython. It uses the native UI toolkit for each platform wherever
possible: Aqua on OS X; MFC on Windows and Gtk on Linux. Applications
tend to look 'natural' on each platform, rather than uniform across
platforms, and I believe that this is what most people prefer.
--
# p.d.
Peter Decker schrieb:
On Wed, Sep 3, 2008 at 11:57 AM, Diez B. Roggisch <de***@nospam.web.dewrote:
>Michael Palmer schrieb:
>>As anyone knows, the state of Python GUI programming is a little
fractured at this time, with many toolkits, wrappers and meta-wrappers
dead and alive, with or without documentation.
I've come across two projects that have the appeal of striving for
simple, pythonic APIs: PyGUI and wax. The latter is a wrapper around
wxPython. It is lacking documentation but actually quite usable and
concise. The other, PyGUI, has an even nicer API and more docs but has
relatively few widgets implemented at this time. It also strives for
compatibility with several toolkits (two at this time), which I think
is the right idea.
I disagree with that. Meta-wrappers like this will always suffer from
problems, as they have difficulties providing a consistent api. For example
wx is said to be very windows-toolkit-centric in it's API. Yes I know that
it works under Linux with GTK, but it does not come as natural .
With all due respect, it seems like you are not terribly familiar with
wxPython. It uses the native UI toolkit for each platform wherever
possible: Aqua on OS X; MFC on Windows and Gtk on Linux. Applications
tend to look 'natural' on each platform, rather than uniform across
platforms, and I believe that this is what most people prefer.
You got me wrong. I didn't say it doesn't use the native toolkit under
various OSes, I'm well aware of that it does.
What I *did* say was that wx API is designed primarily with windows'
toolkit as base, and as a consequence the API tends to be less
functional for other toolkits, making it harder to work with it. As the
OP was after a "one API to rule them all" for GUIs, I pointed that out.
See for example this (arguably somewhat dated) post that illustrates my
point: http://mail.python.org/pipermail/pyt...ch/313354.html
From my personal experience with Qt and Cocoa, I can say that both are
great, but their full power is unleashed only if used directly - talk
about Multi-threading in Qt4, or KeyValue-coding in Cocoa. Neither is
available in wx.
Diez
M.-A. Lemburg wrote:
A long time ago, there was a Python plugin for Netscape
which allowed you to run Python straight in the browser. Perhaps
it's time to revive such an idea... but then you're still missing
out on the GUI part, since you're still stuck with what the
browser has to offer in terms of widget support.
There is still a plugin (extension) for Mozilla based products, that
enables use of Python in products like Firefox: http://pyxpcomext.mozdev.org/
Mark Hammond's Python/Mozilla work has enabled products like Komodo,
Miro (Democracy) and the OLPC project to use Python as a major driver
for consistent cross-platform GUI applications.
Personally, I believe XULRunner has a lot to offer for Python GUI
development, I'm currently finishing up some documentation steps to show
off how to use it specifically for Python (I'll post it to this list
when it's finished).
Cheers,
Todd
On Fri, Sep 5, 2008 at 10:48 AM, Diez B. Roggisch <de***@nospam.web.dewrote:
You got me wrong. I didn't say it doesn't use the native toolkit under
various OSes, I'm well aware of that it does.
What I *did* say was that wx API is designed primarily with windows' toolkit
as base, and as a consequence the API tends to be less functional for other
toolkits, making it harder to work with it. As the OP was after a "one API
to rule them all" for GUIs, I pointed that out.
See for example this (arguably somewhat dated) post that illustrates my
point:
http://mail.python.org/pipermail/pyt...ch/313354.html
OK, that's a little clearer.
That's one of the things that I like about Dabo - it gets rid of the
ugly (IMO) wxPython API and replaces it with a much more consistent
(and, IMO) more Pythonic API. I hated coding in wx, but I love coding
in Dabo.
--
# p.d.
Todd Whiteman <to***@activestate.comsaid :
Personally, I believe XULRunner has a lot to offer for Python GUI
development, I'm currently finishing up some documentation steps to show
off how to use it specifically for Python (I'll post it to this list
when it's finished).
That would be really nice !
I've long been curious about the potential of XUL+Python, but put off by
the lack of leads to follow up, and not having time to do the digging
myself...
TIA,
fp
On 10 sep, 20:36, Fred Pacquier <xne...@fredp.lautre.netwrote:
Todd Whiteman <to...@activestate.comsaid :
Personally, I believe XULRunner has a lot to offer for Python GUI
development, I'm currently finishing up some documentation steps to show
off how to use it specifically for Python (I'll post it to this list
when it's finished).
That would be really nice !
I've long been curious about the potential of XUL+Python, but put off by
the lack of leads to follow up, and not having time to do the digging
myself...
TIA,
fp
I will also like to see such documentation as soon as possible.
To me, XUL+python really looks like what could be my prefered solution
for multiplatform GUI for my python program.
I'm really impatient and hope a strong and motivated community could
set up arrond such XUL+python project.
All the best,
David
On 10 sep, 20:36, Fred Pacquier <xne...@fredp.lautre.netwrote:
Todd Whiteman <to...@activestate.comsaid :
Personally, I believe XULRunner has a lot to offer for Python GUI
development, I'm currently finishing up some documentation steps to show
off how to use it specifically for Python (I'll post it to this list
when it's finished).
That would be really nice !
I've long been curious about the potential of XUL+Python, but put off by
the lack of leads to follow up, and not having time to do the digging
myself...
TIA,
fp
I will also like to see such documentation as soon as possible.
To me, XUL+python really looks like what could be my prefered solution
for multiplatform GUI for my python program.
I'm really impatient and hope a strong and motivated community could
set up arrond such XUL+python project.
All the best,
David
3) Following the public rumor mill and the latest hype RIA i.e. the
merge of web- and desktop applications with systems like Adobe AIR,
JavaFX, Google Gears and MS Silverlight is the future of frontend
development. With the exception of IronPython and Silverlight, Python
hasn't even entered this game and no one knows if it ever will.
http://pyjd.org
tadaaaaa :)
(based on webkit, just like adobe air is).
ofhttp://code.google.com, and you'll need to check out a revision some
time around sep 2007 of the llpamies branch.
rsrrmsrrwssrrfssnrssrr :) http://code.google.com/p/pyjamas then follow through to svn
instructions, bearing in mind that, other than the llpamies branch,
that code is out-of-date.
lkcl wrote:
I got the impression that there is currently no Windows binary
available. Correct? If not, perhaps someone trustworthy will someday
donate one.
You can remove layouts from layouts with the QLayout.removeItem() method.
yes... it didn't work. a layout within a layout - i think it was a
QHorizontalLayout within a QGridLayout - didn't want to be removed.
it's probably a bug.
Was it detached from the layout, but still visible?
i don't know if it _was_ detached from the layout, but it was
definitely still visible. see http://pyjs.org/examples/gridtest/output/GridTest.html
for the example i was porting to pyqt4. each time i clicked "Next", a
new set of N,N would be _overlaid_ on top of the old ones, even though
i was doing removeItem().
the code's at http://lkcl.net/pyjamas-desktop/pyqt4.tgz
although i'm interested to know if there's a solution (to this
particular problem), the amount of additional work to provide an
equivalent of the "1px", "10em", "25%" etc. subdivisions on layouts,
and the amount of additional work to provide "flowing" and HTML-
substitutable layouts (see http://pyjd.org/api/pyjamas.ui.HTMLPanel-class.html)
is just... it's a lot of work.
l.
the bottom line is: if you want a windows version of pywebkitgtk, i'm
happy to assist and advise anyone of the process- it should be quite
straightforward _if_ you have MSVC and follow the standard procedure,
but i'm not about to spend my own time and effort on providing a win32
port using ming32, doing all the work _myself_, on my own, without
financial incentive and renumeration.
Is Visual Studio 2005 OK, or is some other compiler required?
i'll happily explain to other people what _they_ need to do, though.
l.
If Visual Studio 2005 suffices, I'd give it a try.
Propad
lkcl wrote:
On Oct 11, 11:17 pm, Terry Reedy <tjre...@udel.eduwrote:
>lkcl wrote:
I got the impression that there is currently no Windows binary
available. Correct? If not, perhaps someone trustworthy will someday
donate one.
sorry, terry, you deleted a bit too much context :)
I was referring to this at pyjd.org:
Pre-built amd64 .debs are available for download, providing
pywebkitgtk-1.0, libwebkit-1.0-2 and libwebkit-dev, here:
* Download libwebkit-dev, libwebkit-1.0-2 and pywebkitgtk-1.0
and this
>If not, perhaps someone trustworthy will someday donate one.
was my acknowledgement that a Windows binary is not trivial and that I
don't expect one from you after all the nice work you have done.
[compiling with mingw32]
why the python developers didn't include the patches, and keep them up-
to-date, isn't clear.
Mostly likely because no one who uses mingw32 has volunteered to become
the mingw32 Python developer who would update such patches to current
Python (now 2.6/3.0) and support them by responding to bug reports and
by upgrading them to 2.7/3.1 in the next few years.
Any system supported in core Python code with a set of #includes needs
*someone* who will support that set. If the supporter disappears and no
one else volunteers, the #includes become obsolete and get deleted.
Terry Jan Reedy
Propad wrote:
>the bottom line is: if you want a windows version of pywebkitgtk, i'm
happy to assist and advise anyone of the process- it should be quite
straightforward _if_ you have MSVC and follow the standard procedure,
but i'm not about to spend my own time and effort on providing a win32
port using ming32, doing all the work _myself_, on my own, without
financial incentive and renumeration.
Is Visual Studio 2005 OK, or is some other compiler required?
I believe 2.4/2.5 used VS 2003 while 2.6/3.0 do (and 2.7/3.1 will) at
least officially use VS 2008. The free express version apparently
works. It is possible the extension extension modules compiled with
2005 have/will work. I would ask in a separate thread with VS 2005 in
the subject line.
>
>i'll happily explain to other people what _they_ need to do, though.
l.
If Visual Studio 2005 suffices, I'd give it a try.
Propad
--
http://mail.python.org/mailman/listinfo/python-list
On Monday 13 October 2008 11:42, lkcl wrote:
i don't know if it _was_ detached from the layout, but it was
definitely still visible. see
http://pyjs.org/examples/gridtest/output/GridTest.html
for the example i was porting to pyqt4. each time i clicked "Next", a
new set of N,N would be _overlaid_ on top of the old ones, even though
i was doing removeItem().
Yes, it just sounds like you needed to delete the layouts after removing
them.
the code's at http://lkcl.net/pyjamas-desktop/pyqt4.tgz
I might take a look later in the week if the code in there is runnable.
David
On 13 Okt, 23:59, Orestis Markou <ores...@orestis.grwrote:
Just want to say, thank you for a very enlightening writeup. You *
should really post this somewhere that we can link to.
Is this not good enough for you...? http://mail.python.org/pipermail/pyt...er/511375.html
I don't see the Python mail archives going away soon, although there's
also the Wiki for updated and maintained documents.
Although using browser technologies for desktop applications is
interesting (and not new by any means), there are a few things with
regard to layouts which are very difficult with Web technologies (and
aren't getting any easier, either) but which are almost trivial with
classic graphical user interface toolkits, and of course there are
cases where the roles are reversed. I haven't really written any
classic GUI applications for quite some time, but I feel that it's
worth pointing this out.
Paul
On Oct 13, 9:59 pm, Orestis Markou <ores...@orestis.grwrote:
Just want to say, thank you for a very enlightening writeup. You
should really post this somewhere that we can link to.
orestis, thank you for the encouragement. i did post it on my diary: http://advogato.org/person/lkcl/diary/523.html - i decided against
doing a full-blown article because i've been doing quite a _lot_ of
writing on advogato :) but i'm reconsidering. will post here if i do.
i note with interest your comments here: http://orestis.gr/blog/2008/09/19/ra...eb-and-python/
whilst pyjamas and pyjamas-desktop are definitely cross-browser, cross-
desktop, cross-platform and can even be made to be cross-widget-set,
there isn't anything to substitute for _design_ ethos on a per-
platform basis. by that i mean, expectations of there being a "File"
menu on which the word "Quit" will occur, or, as you point out, mac-
user expectations of application behaviour.
l.
On Oct 13, 9:12 pm, Terry Reedy <tjre...@udel.eduwrote:
lkcl wrote:
On Oct 11, 11:17 pm, Terry Reedy <tjre...@udel.eduwrote:
lkcl wrote:
I got the impression that there is currently no Windows binary
available. Correct? If not, perhaps someone trustworthy will someday
donate one.
sorry, terry, you deleted a bit too much context :)
I was referring to this at pyjd.org:
Pre-built amd64 .debs are available for download, providing
pywebkitgtk-1.0, libwebkit-1.0-2 and libwebkit-dev, here:
* Download libwebkit-dev, libwebkit-1.0-2 and pywebkitgtk-1.0
thanks for confirming, i thought so.
and this
>If not, perhaps someone trustworthy will someday donate one.
was my acknowledgement that a Windows binary is not trivial
ha ha - i found that out :)
and that I
don't expect one from you after all the nice work you have done.
thanks.
[compiling with mingw32]
why the python developers didn't include the patches, and keep them up-
to-date, isn't clear.
Mostly likely because no one who uses mingw32 has volunteered to become
the mingw32 Python developer who would update such patches to current
Python (now 2.6/3.0) and support them by responding to bug reports and
by upgrading them to 2.7/3.1 in the next few years.
*nods head side-to-side*... yeahh, good point :)
On Oct 13, 4:03 pm, Propad <npropado...@googlemail.comwrote:
the bottom line is: if you want a windows version of pywebkitgtk, i'm
happy to assist and advise anyone of the process- it should be quite
straightforward _if_ you have MSVC and follow the standard
If Visual Studio 2005 suffices, I'd give it a try.
ok. let's change the subject....
it's bog-standard compile-procedure for webkit, under VS, but you
must add in the patch for the glib bindings.
you'll need a _hell_ of a lot of libraries. read this: http://lkcl.net/webkit/cross-compile-gtk.notes.txt
and of course ignore mingw32 bits - use it to track down the locations
for the various libraries in win32 form, including the .a files.
you'll need cairo, gtk, gdk, libxml, libxslt and libicu. ibm's moved
that on to version 4 and it's compiled up for win32 already.
do make yourself known to the #webkit-gtk team on irc.freenode.net and
ask for their help.
_do_ use the code i have at github.org, use the 16401.master branch, i
do not recommend attempting to use the latest svn plus the patch at
bugs.webkit.org because alp has moved things on a bit and i haven't
the time to update to the latest svn and redo the patch. http://github.com/lkcl/webkit/tree/16401.master
then, once you have a libwebkit.dll, you'll be in a position to
recompile pywebkitgtk for windows. this should be very very
straightforward: there's nothing out-of-the-ordinary, other than you
must patch it, use the last download / attachment from here: http://code.google.com/p/pywebkitgtk...s/detail?id=13
i'm not _entirely_ sure how you go about compiling a c-based python
module under windows, esp. one that requires autoconf: perhaps someone
else here can advise, but if i was to be doing it, i'd start off by
installing MSYS, locating a windows version of autoconf and gnu make
and friends, and seeing how far i could get from there.
you'll definitely need a windows version of python-gtk2 first, though,
which will, aside from anything, give you lots of clues as to how to
go about compiling pywebkitgtk - it's exactly the same principle.
the reason why you'll need python-gtk2 is because of codegen.py - that
is used to turn the webkit.defs into a webkit.c file.
good luck! :)
l.
Although using browser technologies for desktop applications is
interesting (and not new by any means), there are a few things with
regard to layouts which are very difficult with Web technologies (and
aren't getting any easier, either) but which are almost trivial with
classic graphical user interface toolkits, and of course there are
cases where the roles are reversed.
if it wasn't for luis pamirez's brilliant work, porting pygtk to
pyjamas, i would be absolutely agreeing with you, 100%.
see this: http://code.google.com/p/pyjamas/wiki/GsocLlpamies
luis has demonstrated that it's possible to have your cake and eat it.
effectively - incredibly - he's ported pygtk ... to the browser!
so your python pygtk application gets compiled, along with his
reimplementation of gtk.py, gdk.py etc., into javascript (using the
pyjamas compiler) and - unmodified - your pygtk app gets to run in
every major web browser.
that's just... stunning.
regarding what you say about web technologies being more difficult to
do layouts than traditional desktop apps - i'm really sorry to say
that, from my experience with using the pyjamas widget set API, i
couldn't agree less.
HOWEVER - if this were pure HTML and CSS, i would utterly, utterly be
agreeing with you - 100%. the first paragraph of my talk for ukuug
2009 says it best: http://ukuug.org/events/linux2008/pr...ighton-2.shtml
it was _such_ an abortion trying to do a simple centred layout. and
it's for exactly this reason that GWT was created (and then pyjamas
ported from GWT).
when you're using javascript to manipulate the DOM model (or, in the
case of pyjamas-desktop, manipulating the DOM model directly) then
it's an _entirely_ different matter. then, when you put "standard"-
like widgets which include layout manager on top of _that_, which have
identical functions and functionality to those of Desktop Widgets...
.... the distinction between "web" and "desktop" suddenly becomes...
moot. especially in the context of luiz's work.
there isn't a _single_ thing that pyjamas can't do that pygtk2,
wxWidgets or pyqt4 can do. there are _lots_ of things that pyjamas
can do that pygtk2, wxWidgets and pyqt4 can't do (as they stand.
without extra work and/or extensions e.g. derivative customised
classes based on QAbstractLayout)
ok - i'm exaggerating a little :) you can't access standard python
modules from pyjamas apps in a web browser, because javascript is a
restricted execution environment, so you have to make do (and you can
make do _extremely_ well with what's available) with the provided
implementation of builtins. so, if you don't mind using
XMLHTTPRequest to communicate with the rest of the world - even if
it's on http loopback - _then_ you're ok :) and yes, XMLHTTPRequest
is supported in pyjamas-desktop (it has to be).
also, writing new layouts and new widgets, which _happen_ to operate
underneath on the DOM model of a browser (or a browser-kit-library
such as PyKDE or PyWebKitGTK) is trivial. _really_ trivial. i've
outlined how to write your own widget, here: http://pyjd.sourceforge.net/controls_tutorial.html
and it's interesting to compare that to writing one for pygtk (there's
a "stars" example which is easy to find "python gtk tutorial" i think
it's hit number 3).
the only thing i _can_ say, for definite, is that because pyjamas is
missing an equivalent of glade, the UI-generator, and those GUI-based
UI editors / designers, it _is_ at the moment a bit more... hard work
doing the UI design manually, if you're used to using a GUI tool to
design your UI.
but i'm sure that will change.
l.
Paul Boddie wrote:
there are a few things with
regard to layouts which are very difficult with Web technologies (and
aren't getting any easier, either) but which are almost trivial with
classic graphical user interface toolkits, and of course there are
cases where the roles are reversed.
I've written quite a lot of desktop gui apps, and I
don't think I've ever felt the need for free-flowing
widget layouts. To say that a desktop gui api is
severely lacking without this feature is somewhat
overstating the case.
Also, I think that proportional resizing is overrated.
In my experience, either it's sufficient to just
resize one pane and keep the others a fixed size, or
you really want user control over the size of each
pane individually. Proportional resizing is a
compromise that just ends up annoying me.
--
Greg
On Oct 15, 12:27 am, greg <g...@cosc.canterbury.ac.nzwrote:
Paul Boddie wrote:
there are a few things with
regard to layouts which are very difficult with Web technologies (and
aren't getting any easier, either) but which are almost trivial with
classic graphical user interface toolkits, and of course there are
cases where the roles are reversed.
I've written quite a lot of desktop gui apps, and I
don't think I've ever felt the need for free-flowing
widget layouts.
i have. an image library. placed in a scrollpanel, the images
automatically flow left-to-right then down the page. the application
doesn't dictate what size of panel the user _must_ view the images
in. if they want to use the whole screen width, they can. if they
want to view the images in a single column, they can.
To say that a desktop gui api is
severely lacking without this feature is somewhat
overstating the case.
it's the _combination_ of the limitations that makes them severely
lacking. each limitation on its own does not, of course.
the key point is, really, that if you take away one particular layout
methodology from designers, they _will_ adapt - they _will_ cope, and
rejig the design of the app to fit the widget set.
... but that's cart-before-horse. that's "IT tail wagging the
business Dog".
so, when it comes to moving the same application functionality to a
different platform, or to the web, people freak out. you're locked
in. the cost is too great. the effort is too much.
... as you might be aware, i'm not really a big fan of restrictions
imposed by software design :)
Also, I think that proportional resizing is overrated.
proportional resizing is very difficult to do well, and so many
people don't even consider it. many designers will say "this app is
to be used on a 1024x768 screen" (and now of course they're running
into difficulties with the netbook pcs with the 1024x600 screens, and
KDE's control panel "close" button is now off-screen for example!)
it took several months to design a 2d graph widget which was "useful"
when scaled down to 200x150, especially given that the axes could be
logarithmic (!) starting with the axes themselves, we had to break
things down into small, medium and large graticules, where the
distance between each range of graticules would no longer be
displayed, below a certain number of pixels (5 or so). likewise with
the axes numbering. then the axis description had to go, below a
certain size.
then, we had controls (sliders and dials) where, again, the graticules
automatically disappeared, and, also, if below a certain size, the
"readout" would also disappear.
so if you're doing _simple_ applications, then yes, proportional
resizing is entirely unnecessary.
but if you're doing applications where you have to display vast
amounts of interactive graphical data (the example above was a real-
time digital audio restoration GUI) then you really do have to think a
bit harder about what you're going to present the user with.
Proportional resizing is a
compromise that just ends up annoying me.
if it's done badly, then yeah, i agree.
if you look, for example, at the source code of my web site, http://lkcl.net/site_code, you'll see that the site is capable of
resizing to deal with anything down to about 300 pixels in width. the
onResize function redoes the layout, placing the seven components in a
hexagon if there's space, a side-on "H" below 800 pixels, and a single
line below 640 pixels.
it didn't take too much effort, and it means that anyone viewing my
web site even on a QVGA screen won't have to do horizontal scrolling.
not that i'm _expecting_ anyone to do that - i just wanted to prove a
point :)
l.
hello_loader.py is the main.... err.... um.... i just double-
checked, so i'd be able to advise you and... err... the problem i
described (with the GridTest) seems to have... gone away!!
There are lots of references to PyGTK classes in there.
yes, that's because i had started with the gtk port, and was going
through the examples one-by-one removing them and replacing them with
qt.
as i only got up to the "Info" tab of KitchenSink, there is still
quite a bit to do. i _say_ quite a bit - but it's only about ...
16-24 hours of work.
pyjamas is surprisingly small.
Is there a way to select Qt instead of GTK?
sorry! removing them :)
Hacking the code a bit,
:)
I can run the hello_loader.py example. The items
on the left do indeed overlap. It looks like the minimum size of the
labels aren't being respected for some reason.
yeah. and the pyjamas ui.HTML() class is based on a Qt.QLabel(). if
that can be fixed, then there's a fair good reason to continue.
Yes, there are ways to relate the height of a widget to its width, and
there may well be a way to do that for a standard text widget, but it
might involve some experimentation with the underlying text document.
*sharp intake of breath* :) yehhh, i did word-breaking by wrapping
groups of 8 letters at a time in floating-divs once, to simulate word-
breaking in a situation where the column width was 200px and people
were putting in web site addresses of 50 chars in length.... yukk.
Albert-jan Roskam wrote:
Hi,
When you start a new topic/, make sure that you start a new thread by
hitting the appropriate button on your program and not by replying to a
different thread. Your post has nothing to do with GUIs and will be
missed by anyone who has threads collapsed and who skips the GUI thread.
On 11 Okt., 09:56, lkcl <luke.leigh...@googlemail.comwrote:
The role of Python is somewhat arbitrary. This could change only if
Python becomes a client side language executed by AVM,V8etc.
pyv8 -http://advogato.org/article/985.html
pyjs.py - standalone python-to-javascript compiler, seehttp://pyjs.org.
O.K. you got me all. I give up!
I've already imlemented some small Flex supporting functionality in
the P4D Langlet [1] and I'll also checkout pyjamas ( didn't worn them
for long ) and if they are fine I work out a bridge the next days.
Then only style sheets are left :)
[1] http://pypi.python.org/pypi/P4D Langlet/ This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Zooko O'Whielacronx |
last post by:
I'm a fan of Greg Ewing's PyGUI . I used it to code a simple game
for my son , and enjoyed it. Programming with wxPython feels like
programming with a C++ tool that has been wrapped in Python....
|
by: Iwan van der Kleyn |
last post by:
Please ignore if you are allergic to ramblings :-)
Despite a puritan streak I've always tried to refrain from language wars
or syntax bickering; call it enforced pragmatism. That's the main...
|
by: DurumDara |
last post by:
Hi !
Have the python standard mod. lib. a html/xml encoder functions/procedures ?
like this:
def ToSafeHTM(Text):
s=ToHuStrSafe(Text)
l=
for c in s:
|
by: gord |
last post by:
As a complete novice in the study of Python, I am asking myself where this
language is superior or better suited than others. For example, all I see in
the tutorials are lots of examples of list...
|
by: akbar |
last post by:
I googled and searched in archive. All I can find is finding
resolution with Tkinter and pygame. Any idea to find monitor
resolution with standard python module?
I can check from output of: xprop...
|
by: Kevin D. Smith |
last post by:
I would like to move files and directories to the Recycle Bin on
Windows from Python. I have found some older articles describing how
to do this, but they require additional packages to be...
|
by: dananrg |
last post by:
Is there a module available in the standard library, for Python 2.4
running on Windows, like "crypt" for Python 2.4 running on *nix
machines?
I need to store database passwords in a Python 2.4...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| |
