PyGUI as a standard GUI API for Python?

[lkcl]

Compiling Webkit-Glib and PyWebkitGTK for Win32

On Oct 13, 4:03 pm, Propad <npropado...@go oglemail.comwro te:

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.ne t 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/issues/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.

[lkcl]

Re: PyGUI as a standard GUI API for Python?

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
reimplementatio n 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.

[greg]

Re: PyGUI as a standard GUI API for Python?

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

[lkcl]

Re: PyGUI as a standard GUI API for Python?

On Oct 15, 12:27 am, greg <g...@cosc.cant erbury.ac.nzwro te:

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.

[lkcl]

Re: PyGUI as a standard GUI API for Python?

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.

[lkcl]

Re: Compiling Webkit-Glib and PyWebkitGTK for Win32

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]

Re: newbie - merging xls files using xldt and xlwt

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.

[Kay Schluehr]

Re: PyGUI as a standard GUI API for Python?

On 11 Okt., 09:56, lkcl <luke.leigh...@ googlemail.comw rote:

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/