PyGUI as a standard GUI API for Python?

[lkcl]

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/programme/abstract-LKCLeighton-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.

 

[lkcl]

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.

this might help:
http://aruiz.typepad.com/siliconisland/2006/12/allinone_win32_.html

it includes python-gobject, python-gtk, gtk runtime and much more.
exactly _how_ much help it will be, i don't know: you may need instead
to track down the (individual) libraries instead, in order to get the
header files and appropriate .libs.

l.

 

[lkcl]

if there's a way to enforce the displaying of text - for the _text_

to say "i need to be a total area of X in order to display my words.
if you make my width too small, i will _force_ my height to be larger
as i wrap the text".

just like an HTML <p> </p> does.

... of course, i'm well aware of the reasons _why_ this isn't
supported - in either of Qt4 or Gtk2. it's because automatic-
resizing, and correct (i.e. exact) size-hinting, is a complete lairy
nightmare to implement. browsers get it right, because they have to,
and the trade-off is a rather awkward judder-judder-displaying of
content (which, for example, gives the use of HTML tables such a bad
name).

all of which of course makes the desktop-app developers' job just that
little bit more awkward...

 

[David Boddie]

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. Is there a
way to select Qt instead of GTK?

however, clicking too fast _did_ end up with fifty little windows of
text (!)

and the respect for text boundaries is definitely broken - shrink the
window to 300 x 400 with the kitchensink example (which is where i
stopped and moved to webkit, so all the _other_ examples prior to that
will work) and you'll see that the text in a column down the left hand
side end up all overlapping each other. so, you get to see the top
few pixels of each word.

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.

if there's a way to enforce the displaying of text - for the _text_
to say "i need to be a total area of X in order to display my words.
if you make my width too small, i will _force_ my height to be larger
as i wrap the text".

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.

David

 

[greg]

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.

 

[lkcl]

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.

 

[lkcl]

hello_loader.py is the main.... err.... um.... i just double-

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.

 

[lkcl]

terry, hi:
instructions to ensure that you have the right build environment for
windows is here:
http://webkit.org/building/tools.html

it's not made clear whether the use of VS 2005 will _automatically_
download all of the build dependencies for you - you'll have to find
out

regarding pywebkitgtk:

http://www.python.org/doc/2.5.2/ext/win-cookbook.html

not sure how much use this will be, but i'm sure you'll definitely
need gnu autoconf and friends, so i'd start here:

http://gnuwin32.sourceforge.net/

l.

 

[Terry Reedy]

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.

 

[Kay Schluehr]

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/