subject:"GUIs \- A Modest Proposal"

On Jun 13, 4:52 pm, a...@pythoncraft.com (Aahz) wrote:
 In article cf08e777-b98b-4b7c-96df-e7b127c02...@y4g2000yqy.googlegroups.com,

 lkcl  luke.leigh...@gmail.com wrote:

  i'm recording all of these, and any other web browser manipulation
 technology that i've ever encountered, here:

 http://wiki.python.org/moin/WebBrowserProgramming

 Neat!  Why aren't you including Selenium/Windmill?

 .  cos i'd nver not in a miiillion squillion years heard of
it.  until now.  loovelyy.  ok.  added selenium - now to look up
windmill.

 thanks aahz.
-- 
http://mail.python.org/mailman/listinfo/python-list

pyqt4 vs pygtk2 vs pyjamas (was: GUIs - A Modest Proposal)

On Jun 13, 3:43 pm, Michael Torrie torr...@gmail.com wrote:
 On 06/13/2010 05:29 AM, lkcl wrote:

   really?  drat.  i could have done with knowing that at the time.
  hmmm, perhaps i will return to the pyqt4 port after all.

 We're now wandering well off-topic here, but then again this thread was
 never really on any particular topic.

 :)

 I have to say I'm really confused as to your issues with GTK and Qt.

 yeahh... it's kinda necessary to have done complex HTML/CSS-based
layouts (or better yet, an equivalent, e.g. using declarative python-
driven widget-enhanced DOM programming) to appreciate the perspective
i'm coming from.

 the rules for table layouts in browsers are (aside from their
technical limitations) incredibly powerful, flexible and ultimately
very very forgiving of users' lack of knowledge and experience.

 use of - reliance upon - these rules results in quite a bit less code
(both for the pyjamas ui widget developers to have to write, and also
for the users/developers of the pyjamas widget set).

 so my expectations were that i should be able to do the same sort of
thing with GTK or QT, and... it just wasn't happening.

 to highlight this further, i should point out that i looked up paul
bonser's browser-written-in-python, called pybrowser:
   http://git.paulbonser.com/

 in it, you can find some pseudo-code for table/div which he's
obviously looked up somewhere, presumably in W3C DOM specifications.
he's already successfully implemented span / rules, but the div /
rules he left for another time.

 i tried implementing them: i cannot make head nor tail of the
algorithm/pseudocode :)  it's _that_ complex a recursive interaction,
between block-based and flowing layout objects.

 i mention this because to even _remotely_ attempt to accurately re-
create pyjamas desktop using Qt4 or Gtk2, it would be necessary,
ultimately, to implement the same browser-based recursive layout
algorithm that is already in existing web browsers.

 by doing that, effectively i would actually be creating the vast
majority of the functionality of a web browser... in python!

 and rather than do that from scratch, i would actually be better off
either helping (or waiting for) paul to work on pybrowser, or recover
and work on grailbrowser (which i've begun doing - it now runs under
python 2.4 and just needs all its regular expressions converted from
regex to sre in order to run under python2.5+) 
http://github.com/lkcl/grailbrowser
...

 ... and then using _that_ as the basis for another pyjamas port, by
adding and using W3C DOM functions (which don't exist in grailbrowser
sadly).  paul bonser's work is actually the better underlying
framework: he's already added the W3C DOM TR1 through to TR3
properties and functions, such as getElementById(), appendChild(),
offsetWidth and so on, but grailbrowser is the better _actual_ browser
on account of it actually... working! :)

 in a delicious piece of irony, which brings us back full circle to
the original discussion, python/tk-haters will howwl with fury to
learn that grailbrowser is a fully-functioning 35,000-line python/tk
application :)


 I've seen and done all kinds of fancy widget layouts in Qt and have
 *never* had to subclass layout.  If you think you need to subclass
 QLayout, most of the time you're doing it wrong.  You are familiar with
 how the vertical and horizontal layouts and spacers work in Qt, aren't
 you?

 yes.

 Sometimes you need a grid for a table or the specialized form
 grid.   But other than that you want a dynamically-sizing layouts most
 of the time.  And Qt's Vertical and Horizontal layouts do that.

 sadly, not to the kind of recursive / child _and_ parent inter-
dependent level as browser layouts that would make it a simple viable
alternative.


 I'm also confused by your claim that GTK lacks the layout widgets you
 need as well.  GTK has the GtkHBox layout class which acts much like
 your span tag.  Anything to pack in the hbox is automatically layed
 out in a dynamicially-resizing way.

 i did map pyjamas UI HorizontalPanel directly onto GtkHBox, and so
on: i got a long long way, very very quickly by doing that.

 perhaps... perhaps if you have time, if you could take a look at the
pyjd-gtk2 and/or the pyjd-qt4 ports, you might be able to point out
where i'm going wrong.  they're both here:

 http://github.com/lkcl/pyjamas-desktop

 they're a bit old, but are functional (install python-gtkhtml2 even
to get the pyjd-qt4 port to run, there's some code still accidentally
left in) and you run them with hello_loader.py by hacking in the
appropriate class - you'll see what i mean.

   excellent!  that actually makes it worthwhile carrying on.  the only
  other thing that needs solving is that RichText is forced to have its
  width and height set.  but it mayyy be possible to create an
  appropriate QLayout derivative: i'll have to see.

 Again I'm confused here.  I just created a little Window in Qt Designer
 and was able to get my RichText

Re: GUIs - A Modest Proposal

On Jun 13, 2:34 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
 On 6/13/10 4:29 AM, lkcl wrote:

   it's in fact how the entire pyjamas UI widget set is created, by
  doing nothing more than direct manipulation of bits of DOM and direct
  manipulation of the style properties.  really really simple.

 Did you just call DOM manipulation simple with a straight face? I don't
 think I've ever seen that before.

 *lol* - wait for it: see below.  summary: once you start using high-
level widgets: yes.  without such, yeah you're damn right.

 HTML+CSS have some very strong advantages. Simplicity is not one of
 them. Precision web design these days is a dark art. (Go center an image
 vertically and horizontally in an arbitrary sized field!)

 stephen, _thank_ you - that was _exactly_ why i decided i flat-out
was NEVER going to do plain HTML/CSS programming _ever_ again.  i
spent twwoo weeks trying to do exactly this (well, it was 7
boxes, not an image) - and i failed.

 i succeeded on firefox to get the boxes centred, but with IE, when
you resized the screen, the bloody boxes went off the top!  they were
so centred that they went off the top of the screen!  and the bloody
idiotic IE team forgot that you can't scroll _up_ off the top of the
screen :)

 in desperation, i blindly wandered into pyjamas, and went ye -
and within 50 minutes i had converted my site to do exactly this.

 you can see the results here: http://lkcl.net and the main code is
here:
http://lkcl.net/site_code/index.py

 the relevant (crucial) function is the onWindowResized function which
gets called because of this: Window.addWindowResizeListener(self)


   def onWindowResized(self, width, height):

self.toprow.removeFromParent()
self.middlerow.removeFromParent()
self.bottomrow.removeFromParent()
self.html.removeFromParent()
self.ads.removeFromParent()

self.create_layout()

 the create_layout function basically does this:

width = Window.getClientWidth()

if width  800:

toprow = HorizontalPanel()
middlerow = HorizontalPanel()
bottomrow = HorizontalPanel()

elif width  640:

# different types of layout panels

else:

# utterly skinny vertical-only panels

 those three panels are added into another panel which has 100% width
and 100% height, and has centre properties attached to its cells;
voila, the boxes always sit in the middle of the screen.  when the
screen is too big for the 100% height outer panel, the boxes push
against the constraints of their outer panel, thus forcing the screen
to become bigger and thus automatically a vertical scroll-bar is
added.  for some browsers this results in another onWindowResize
notification and for some it doesn't (eurgh) - but that's another
story :)

 this is what i was referring to in another message... rats, can't
find it now: it was the one asking about why qt4 and gtk2 layouts
don't cut it, and i explained about the recursive complex child-parent
interaction rules between DOM objects.


 but - allow me to write a quick app which does what you ask:

 from pyjamas.ui.Image import Image
 from pyjamaas.ui.AbsolutePanel import AbsolutePanel
 from pyjamaas.ui import RootPanel
 from pyjamas import Window

 class Thingy:
def __init__(self):
   self.panel = AbsolutePanel(Width=100%, Height=100%)
   self.image = Image(http://python.org/python.png;)
   self.panel.add(image, 0, 0) # add in top-left just for now

   # make a fake initial window resize notification
   self.onWindowResized(Window.getClientWidth(),
Window.getClientHeight())
   Window.addResizeListener(self)

def onWindowResized(self, width, height):
ok - ignore the image's width and height
   because you have to wait for it to load, first,
   and that means doing an onImageLoad async notification
   and this is supposed to be a short demo!

   self.panel.setWidgetPosition(self.image, width/2, height/2)

  RootPanel.add(Thingy())


and... yes, honest to god, that's a web application.  _really_ a web
application.  not an HTML/CSS one, but it's still a web application -
and not a single line of javascript or even DOM manipulation in sight.

if you had to do that as javascript, it would be... eurgh - 300 lines
of unreadable crap?  if you had to do that *without the pyjamas ui
widget set* it would be ... ergh... 150 lines of barely tolerable
crap.  but with the AbsolutePanel class, and the Image widget, and the
neat wrapping of event handling?  pffh - complete doddle.

i think... this is what's making pyjamas so hard for people to grasp.
it sits literally in the middle between _both_ technologies: web
browsers which have a reputation for being utterly utterly useless and
hard to program because any real programmer wouldn't _dream_ of
calling HTML an actual programming language; and on the other side
there's people who use

Re: GUIs - A Modest Proposal

On 6/14/10 7:15 AM, lkcl wrote:
 On Jun 13, 2:34 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
 On 6/13/10 4:29 AM, lkcl wrote:

  it's in fact how the entire pyjamas UI widget set is created, by
 doing nothing more than direct manipulation of bits of DOM and direct
 manipulation of the style properties.  really really simple.

 Did you just call DOM manipulation simple with a straight face? I don't
 think I've ever seen that before.
 
  *lol* - wait for it: see below.  summary: once you start using high-
 level widgets: yes.  without such, yeah you're damn right.


See, the thing is, my background is a little bit mixed. I've produced
complex yet approachable and dynamic interfaces for both traditional
client applications, and similar level user interfaces for the web. In
the latter case, I don't do HTML/CSS programming anymore as you describe
it, but JavaScript-based building out of the application.

And the recursive flow of the DOM is powerful (and in some cases,
superbly suited to a task), but I maintain fully: at no point is it
easy, simple, or even entirely comprehensible to most average geeks.
Traditional GUI models vs the web layout model are just alien to one
another, and the latter is -extremely- convoluted.

The virtue of the web model is that it is very easy to get Something
out which looks and behaves almost like what you expect or want with
minimal fuss.

Then you try to tweak it to get it exactly how you want, and suddenly it
can devour your soul in a hysterical haze of element style interactions
along the DOM. And just when you think you have it: somehow the entire
thing collapses and nothing works. :P

Eventually you start to -understand- the DOM, and thinking in DOM, and
you're clinically a little bit insane, but suddenly it all sort of makes
sense.

I think you've gone down this path and are slightly lost to the dark
forces of the DOM and are no longer seeing that its nutty, cuz
internally nutty is now natural :) I can usually do real-life interfaces
in traditional GUI models which are far simpler and use less code then
equivalent DOM based interfaces, /except/ in cases where I have a
content flow situation. Where large amounts of 'unknown' are inserted
into an interface and I want everything to go with it well.

That's not to say I think you're actually crazy. I just think you either
think naturally in the twisting and recursive mode of DOM or have taught
yourself to. Its a mental model that not all will ever grasp. :)

 
 HTML+CSS have some very strong advantages. Simplicity is not one of
 them. Precision web design these days is a dark art. (Go center an image
 vertically and horizontally in an arbitrary sized field!)
 
  stephen, _thank_ you - that was _exactly_ why i decided i flat-out
 was NEVER going to do plain HTML/CSS programming _ever_ again.  i
 spent twwoo weeks trying to do exactly this (well, it was 7
 boxes, not an image) - and i failed.
 
  i succeeded on firefox to get the boxes centred, but with IE, when
 you resized the screen, the bloody boxes went off the top!  they were
 so centred that they went off the top of the screen!  and the bloody
 idiotic IE team forgot that you can't scroll _up_ off the top of the
 screen :)
 
  in desperation, i blindly wandered into pyjamas, and went ye -
 and within 50 minutes i had converted my site to do exactly this.
 
  you can see the results here: http://lkcl.net and the main code is
 here:
 http://lkcl.net/site_code/index.py
 
  the relevant (crucial) function is the onWindowResized function which
 gets called because of this: Window.addWindowResizeListener(self)

[snip implementation]

See, even in *python*, this is all rediculiously complicated. It should
be one, or at most, two lines of code to do something like uh, center
please :-)

  those three panels are added into another panel which has 100% width
 and 100% height, and has centre properties attached to its cells;
 voila, the boxes always sit in the middle of the screen.  when the
 screen is too big for the 100% height outer panel, the boxes push
 against the constraints of their outer panel, thus forcing the screen
 to become bigger and thus automatically a vertical scroll-bar is
 added.  for some browsers this results in another onWindowResize
 notification and for some it doesn't (eurgh) - but that's another
 story :)
 
  this is what i was referring to in another message... rats, can't
 find it now: it was the one asking about why qt4 and gtk2 layouts
 don't cut it, and i explained about the recursive complex child-parent
 interaction rules between DOM objects.

I'm not entirely sure you fully understood qt or gtk's layout
mechanisms. Now, I do not know QT, but I know wx -- which is implemented
in temrs of gtk, so somehow the wx team got it working on GTK.

wx uses a complicated recursive layout engine (unless you're mildly nuts
and try to do absolute layouts) which in all essence does *exactly* what
you are describing there. With a little bit of

Re: GUIs - A Modest Proposal

On Jun 14, 11:17 am, Stephen Hansen me+list/pyt...@ixokai.io wrote:
 And the recursive flow of the DOM is powerful

This style of speaking reminds me of our former hillbilly president
(no not Clinton, he was the eloquent hillbilly!) No i am referring to
good old George Dubya. He left us with so many juicy sound bites

HOST: I’m curious, have you ever googled anybody? Do you use Google?
BUSH: Occasionally. One of the things I’ve used on the Google is to
pull up maps. It’s very interesting to see — I’ve forgot the name of
the program — but you get the satellite, and you can — like, I kinda
like to look at the ranch. It remind me of where I wanna be sometimes.

... Thanks Dubya for making a complete moron of yourself, AGAIN!

 (and in some cases,
 superbly suited to a task), but I maintain fully: at no point is it
 easy, simple, or even entirely comprehensible to most average geeks.
 Traditional GUI models vs the web layout model are just alien to one
 another, and the latter is -extremely- convoluted.

I'll have to very much agree with this assessment Stephan. There
exists not elegant API for these web UI's. The people over at
SketchUp (my second love after python) have this problem on a daily
bases with WebDialogs. Even the javascript gurus have a dificult time
juggling javascript, CSS, and Ruby code to make these grumpy beasts
come to life, and when they do it ain't really pretty. Many have
lamented for a simple to use GUI like Tkinter or even Wx but our cries
have fallen on deaf ears.

But digging a bit deeper you can think of the javascript/css/
langugageX here as the same mind warping power C/C++ hold over it's
users too. Low level C hackers cannot properly use a high level
language like Python (with some very small exceptions). I see it all
the time in the SketchUp Ruby API. These guys are like fish out of
water when you give them a Python/Ruby interpretor. Here is a nutty
example

# UI.inputbox(prompts, defaults, enums, title) - result
# With four params, it shows a drop down box for prompts that have
# pipe-delimited lists of options. In this case, the Gender prompt
# is a drop down instead of a text box.
prompts = [What is your Name?, What is your Age?, Gender]
defaults = [Enter name, , Male]
list = [, , Male|Female]
input = UI.inputbox prompts, defaults, list, Tell me about yourself.

...Does it need to be that messy, well in the C world yes, but in
Python/Ruby world lets make our lives easier shall we...

input = UI.inputbox(
'Title Here',
'prompt1=default1'
'prompt2=default2',
'prompt3=opt1|opt2',
)

... now i feel the same bliss old George knows all to well and
ignorance has nothing to do with it ;-).

 wx uses a complicated recursive layout engine (unless you're mildly nuts
 and try to do absolute layouts) which in all essence does *exactly* what
 you are describing there. With a little bit of boiler plate: you have to
 declare a certain box to be allowed to grow a scrollbar, so that's a
 little more work. But less in others: I never have to resort to resize
 hooks to get stuff to reconfigure itself (with the sole exception being
 the Expandable Text Control).

I must say of all the GUI's Tkinter does handle geometry management in
a most simplistic way. You have your choice between three managers
grid, pack, and place. Wx introduces a little less elegance however
nothing like what we have here.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-14 Thread Ricardo Aráoz


On 14/06/2010 02:57 p.m., rantingrick wrote:

On Jun 14, 11:17 am, Stephen Hansenme+list/pyt...@ixokai.io  wrote:
   

And the recursive flow of the DOM is powerful
 

This style of speaking reminds me of our former hillbilly president
(no not Clinton, he was the eloquent hillbilly!) No i am referring to
good old George Dubya. He left us with so many juicy sound bites
   



PLONK 

--
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 14, 4:17 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:

  Did you just call DOM manipulation simple with a straight face? I don't
  think I've ever seen that before.

   *lol* - wait for it: see below.  summary: once you start using high-
  level widgets: yes.  without such, yeah you're damn right.

 See, the thing is, my background is a little bit mixed.

 ahh?  good.  perfect.

 I've produced
 complex yet approachable and dynamic interfaces for both traditional
 client applications, and similar level user interfaces for the web. In
 the latter case, I don't do HTML/CSS programming anymore as you describe
 it,

 definitely not as i would describe it, either!  so let's substitute
the average web programmer for the word you.

 but JavaScript-based building out of the application.

 yes.  that's effectively what pyjs applications are about: as much
HTML/CSS as you can stand, then _absolute_ pure javascript from there-
on in... only using a compiler (python-to-javascript) so as not to go
completely insane - and, from the rest of your message, i _know_ you
know what i'm talking about, there :)

 And the recursive flow of the DOM is powerful (and in some cases,
 superbly suited to a task), but I maintain fully: at no point is it
 easy, simple, or even entirely comprehensible to most average geeks.

 correct.  i don't pretend to get it, completely. i tend to put my
trust in the pyjamas widgets - things with names like Grid,
FlexTable, Button, HorizontalPanel and VerticalSlider - and hope for
the best.

 to be absolutely honest, i very rarely even write my own widgets: i
advocate that people, myself _especially_ myself included, perform
literal line-for-line translations of GWT widgets from java to
python.  why? because, again: on the basis that google have tons of
money to put into GWT widgets, doing full regression tests, and have
thousands of users, they can afford to get the widget right across all
the browsers.  ergo, why duplicate that effort - just code-translate
it verbatim!

 oh, btw, that's turning into quite a powerful project on its own: the
goal is to have a fully automated java-to-python translator!

 http://github.com/thoka/java2python


 Traditional GUI models vs the web layout model are just alien to one
 another, and the latter is -extremely- convoluted.

 we've found that there's a third hybrid case, and it's hinted at
through RIA javascript libraries such as extjs: a traditional GUI
model *implemented* as a web app.

 so those RIA JS libraries are not vs, they're _both_.  except...
javascript has its own headaches, so that's why both pyjamas and GWT
remove _those_ headaches, by using language translators.

 so, yah - except when hybridly-hidden behind widgets, of which
pyjamas has something like... 70, and GWT must have 150+ and upwards,
if you include 3rd party libraries out there that i can't even begin
to count.

 The virtue of the web model is that it is very easy to get Something
 out which looks and behaves almost like what you expect or want with
 minimal fuss.

 Then you try to tweak it to get it exactly how you want, and suddenly it
 can devour your soul in a hysterical haze of element style interactions
 along the DOM. And just when you think you have it: somehow the entire
 thing collapses and nothing works. :P

 tell me about it ha ha - been there :)

 Eventually you start to -understand- the DOM, and thinking in DOM, and
 you're clinically a little bit insane, but suddenly it all sort of makes
 sense.

 I think you've gone down this path and are slightly lost to the dark
 forces of the DOM and are no longer seeing that its nutty, cuz
 internally nutty is now natural :)

 no, you'll be relieved to know that, as above, i entirely avoid it
unless absolutely necessary (by cheating, and using the java2python
approach).  i wrote a slider class (veeery basic).  ok, i'm lying
somewhat: after doing almost 40,000 lines of java to python
translation involving heavy amounts of DOM you can't _help_ but begin,
by a process of osmosis, to get to grips with it :)

 I can usually do real-life interfaces
 in traditional GUI models which are far simpler and use less code then
 equivalent DOM based interfaces, /except/ in cases where I have a
 content flow situation. Where large amounts of 'unknown' are inserted
 into an interface and I want everything to go with it well.

 i think i know what you're referring to: obtaining 700+ bits of data
and trying to insert them all at once into the DOM interface, as the
web engine is single-threaded, you lock up the browser.  and there's
no escape!  in these circumstances, the trick recommended is to use a
timer, breaking up the loop and adding bits at a time.  e.g.:
  http://pyjs.org/book/Chapter.py

 you can see in onTimer, a simple loop, reads up to 10 lines, fires
the timer again.

 i would _hate_ to have to do this sort of thing in pure javascript.

 That's not to say I think you're actually crazy. I just think you either
 think naturally in

Re: GUIs - A Modest Proposal

On Jun 14, 5:57 pm, rantingrick rantingr...@gmail.com wrote:
 On Jun 14, 11:17 am, Stephen Hansen me+list/pyt...@ixokai.io wrote:

  And the recursive flow of the DOM is powerful

 This style of speaking reminds me of our former hillbilly president
 (no not Clinton, he was the eloquent hillbilly!)

 the one with an IQ of 185?

 No i am referring to
 good old George Dubya.

 the one with an IQ of 190?

 He left us with so many juicy sound bites

 HOST: I’m curious, have you ever googled anybody? Do you use Google?
 BUSH: Occasionally. One of the things I’ve used on the Google is to
 pull up maps. It’s very interesting to see — I’ve forgot the name of
 the program — but you get the satellite, and you can — like, I kinda
 like to look at the ranch. It remind me of where I wanna be sometimes.

 o, you must mean sonny-boy, the one with the IQ of 85 due to
having destroyed his mind with drink and drugs - ahh, yehhs.  the only
thing i can respect that man for is the fact that he insists on going
to bed before 9:30pm.

 yeessh, how did america manage to vote in a president who *started
out* so blatantly unintelligent, as opposed to voting one in who had
an off-the-charts IQ and lost it to alzheimers, dear-old ronnie-boy??

 l.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 14, 5:57 pm, rantingrick rantingr...@gmail.com wrote:
 I'll have to very much agree with this assessment Stephan. There
 exists not elegant API for these web UI's. The people over at
 SketchUp (my second love after python) have this problem on a daily
 bases with WebDialogs. Even the javascript gurus have a dificult time
 juggling javascript, CSS, and Ruby code to make these grumpy beasts
 come to life, and when they do it ain't really pretty.

 ah.  again, the recommended pyjamas development model vs the
standard development model comes to the rescue, here.  in a pyjamas
app, the app loads ONCE and ONLY ONCE, as one whopping great
javascript behemoth which can be somewhere around 2mb if the original
python (pyjamas) source is around... 15 to 20,000 lines of code.

 from thereon in, you DO NOT do *any* HTML page GETs: it's a one-
time static HTML/JS load, and THAT's IT.

 the only further interaction that we recommend is first and foremost
JSONRPC (and so, out of the 30 or so pyjamas wiki pages, about 10 of
them involve HOWTOs for interacting with django, pylons, web.py,
web2py, twisted and so on) and the second one, because you have to, is
HTTP POST of Multi-Part FORMs.

 even with the HTTP Forms, you _still_ don't have to leave the main
pyjamas (static JS) application page, because the GWT team, bless 'em,
came up with a way to do a hidden iframe which does the HTTP POST in
the background.  _well_ smart cookies, them GWT boys - and we just...
lifted it straight into python :)

 so there's _zero_ further webuhhh pagizz lohdinn.

 we found some really smart cookie's jsonrpc server-side code, which
turns out to be a stonking JSONRPC service in under 30 lines of code,
where you can turn absolutely any python code, pretty much, into an
RPC service with one import line, one line of code and then one
decorator per function you want to be in the JSON RPC service.

 this approach, on its own, drastically simplifies python web service
development.  now your entire server-side web service is implemented
in terms of *data* _not_ the presentation-of-the-data-mixed-in-with-
the-data-and-oops-er-maybe-a-little-bit-of-javascript-oh-hell-actually-
it's-a-lot-of-javascript-and-oh-god-here-we-go-again-how-do-we-debug-
this?

the only down-side of this approach _would_ be that you'd now have to
do everything as a JSONRPC client, which if you were in pure
javascript land would truly be absolute hell on earth.

 _but_... as we're talking python... ta-daaa! easy :)

 ok, not _entirely_ easy, because it has to be done asynchronously.
make the call, then wait for a response, timeout or a server error -
but, guess what?  you can create a python class with functions
onResponse, onError and onTimeout which will be called when the
function has completed (or not) on the server.  ta-daaa :)

 running example:
http://pyjs.org/examples/jsonrpc/output/JSONRPCExample.html

 pyjamas client-side code:
http://pyjs.org/examples/jsonrpc/JSONRPCExample.py

 so - pyjamas developers _don't_ have the same juggling problems
that the average advanced AJAX + web-service programmer has, because
everything's compartmentalised along MVC lines:

   http://www.advogato.org/article/993.html

 i would say that GWT developers don't have the same problems, but
because java is a strongly-typed language, they have a biatch-and-a-
half god-awful time carrying out type-casting of JSONRPC parameters
and the function return type when it comes back from the server,
_even_ though the target language of the compiler is dynamic -
javascript!

 poor things.  haw, haw :)

 l.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On 6/14/10 11:47 AM, lkcl wrote:
 On Jun 14, 4:17 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
  yes.  that's effectively what pyjs applications are about: as much
 HTML/CSS as you can stand, then _absolute_ pure javascript from there-
 on in... only using a compiler (python-to-javascript) so as not to go
 completely insane - and, from the rest of your message, i _know_ you
 know what i'm talking about, there :)

Yeah. It sounds very interesting. I just wish it, like, somehow bundled
webkit cross-platformly. :)

  to be absolutely honest, i very rarely even write my own widgets: i
 advocate that people, myself _especially_ myself included, perform
 literal line-for-line translations of GWT widgets from java to
 python.  why? because, again: on the basis that google have tons of
 money to put into GWT widgets, doing full regression tests, and have
 thousands of users, they can afford to get the widget right across all
 the browsers.  ergo, why duplicate that effort - just code-translate
 it verbatim!
 
  oh, btw, that's turning into quite a powerful project on its own: the
 goal is to have a fully automated java-to-python translator!
 
  http://github.com/thoka/java2python

Somehow this is getting perverse. Java, to Python, to JavaScript. It
just sounds sort of incestuous. :)

But also worth looking into for my next web project.

 Traditional GUI models vs the web layout model are just alien to one
 another, and the latter is -extremely- convoluted.
 
  we've found that there's a third hybrid case, and it's hinted at
 through RIA javascript libraries such as extjs: a traditional GUI
 model *implemented* as a web app.
 
  so those RIA JS libraries are not vs, they're _both_.  except...
 javascript has its own headaches, so that's why both pyjamas and GWT
 remove _those_ headaches, by using language translators.

Well, yes. I have some experience with extjs (and making some pretty
fantastic real-world seeming apps on the web with it), and yeah,
removing Javascript headaches is a very interesting goal. (Pet peeve to
end all pet peeves: trailing commas in objects breaks IE. I always leave
trailing commas, always, in Python code: makes adding stuff easier
later. And I can't shake doing it in my javascript instinctively).

The current project occupying my time involves a fairly complicated mix;
on the server-side we have Pylons, but its interfacing with an external
application server, so about half of the Pylons layers are outsourced
(i.e., data and model access).

Then the web interface is ExtJS. Its just getting very, very -- ungainly
from a maintenance point of view. Maybe on its next iteration I'll look
into pyjamas.

 Now, I do not know QT, but I know wx -- which is implemented
 in temrs of gtk, so somehow the wx team got it working on GTK.

 wx uses a complicated recursive layout engine (unless you're mildly nuts
 and try to do absolute layouts) which in all essence does *exactly* what
 you are describing there.
 
  oooOo.  that's _very_ interesting to hear.  i'd assumed that there
 wouldn't be anything beneficial that wx would bring to the table, by
 using gtk.  ha.  that might be worthwhile doing a pyjd-wx port, then,
 after all.  hmm.

Well, I may have overstated it a little bit by mistake.

wx does not require you use this model, and it does not do it on its own
-- you do have to design the flow a little bit.

wx has two separate containment hierarchies. The first is a
hierarchical, parent-child relationship. This is what a lot of people
think is its layout: but its not. It has nothing to do with layout, but
instead its more about event propagation. Then again it can *affect*
layout (you can't lay out the child of PanelA in PanelB).

But the real layout system is based on the sizers. Every container
control can have a single sizer. This sizer can contain any number of
the children of the parent. It can choose to lay them out in any number
of basic ways: the horizontal box, vertical box, grid layout, flexgrid
layout, then a couple specialized ones. Each individual object in the
sizer can have any number of flags, such as align this way or that, add
this amount of border, and if the object should be expanded to fill the
available opposite-space. (This is complicated: basically, if you have a
Horizontal Box controlling a window, and you add three items into it,
they'll sit next to each other and not fill out either the horizontal or
vertical space. But if the first item is set to 'expand', then it will
fill out all the available *vertical* space that the sizer is allowed to
manage).

Then comes the most important setting: the proportion option. Here you
determine how much of the available primary space each given object
gets. If you have three objects, all proportion 1: then all will share
the horizontal space evenly, expanding to fill all available. If one is
2, and the others have 1... then they'll all expand, but one will have
2:1 of the size.

Now, while the sizers are making all these

Re: GUIs - A Modest Proposal

On 6/14/10 12:16 PM, lkcl wrote:
  from thereon in, you DO NOT do *any* HTML page GETs: it's a one-
 time static HTML/JS load, and THAT's IT.
 
  the only further interaction that we recommend is first and foremost
 JSONRPC (and so, out of the 30 or so pyjamas wiki pages, about 10 of
 them involve HOWTOs for interacting with django, pylons, web.py,
 web2py, twisted and so on) and the second one, because you have to, is
 HTTP POST of Multi-Part FORMs.

AJAJ ftw.

(Yes, how you describe the situation is how I develop web apps, minus
the pyjamas and plus the wtf-javascript for the client side)

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 14, 7:30 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
 On 6/14/10 11:47 AM, lkcl wrote:

  On Jun 14, 4:17 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
   yes.  that's effectively what pyjs applications are about: as much
  HTML/CSS as you can stand, then _absolute_ pure javascript from there-
  on in... only using a compiler (python-to-javascript) so as not to go
  completely insane - and, from the rest of your message, i _know_ you
  know what i'm talking about, there :)

 Yeah. It sounds very interesting. I just wish it, like, somehow bundled
 webkit cross-platformly. :)

   to be absolutely honest, i very rarely even write my own widgets: i
  advocate that people, myself _especially_ myself included, perform
  literal line-for-line translations of GWT widgets from java to
  python.  why? because, again: on the basis that google have tons of
  money to put into GWT widgets, doing full regression tests, and have
  thousands of users, they can afford to get the widget right across all
  the browsers.  ergo, why duplicate that effort - just code-translate
  it verbatim!

   oh, btw, that's turning into quite a powerful project on its own: the
  goal is to have a fully automated java-to-python translator!

   http://github.com/thoka/java2python

 Somehow this is getting perverse. Java, to Python, to JavaScript. It
 just sounds sort of incestuous. :)

 But also worth looking into for my next web project.

  Traditional GUI models vs the web layout model are just alien to one
  another, and the latter is -extremely- convoluted.

   we've found that there's a third hybrid case, and it's hinted at
  through RIA javascript libraries such as extjs: a traditional GUI
  model *implemented* as a web app.

   so those RIA JS libraries are not vs, they're _both_.  except...
  javascript has its own headaches, so that's why both pyjamas and GWT
  remove _those_ headaches, by using language translators.

 Well, yes. I have some experience with extjs (and making some pretty
 fantastic real-world seeming apps on the web with it), and yeah,
 removing Javascript headaches is a very interesting goal. (Pet peeve to
 end all pet peeves: trailing commas in objects breaks IE. I always leave
 trailing commas, always, in Python code: makes adding stuff easier
 later. And I can't shake doing it in my javascript instinctively).

 The current project occupying my time involves a fairly complicated mix;
 on the server-side we have Pylons, but its interfacing with an external
 application server, so about half of the Pylons layers are outsourced
 (i.e., data and model access).

 Then the web interface is ExtJS. Its just getting very, very -- ungainly
 from a maintenance point of view. Maybe on its next iteration I'll look
 into pyjamas.

  Now, I do not know QT, but I know wx -- which is implemented
  in temrs of gtk, so somehow the wx team got it working on GTK.

  wx uses a complicated recursive layout engine (unless you're mildly nuts
  and try to do absolute layouts) which in all essence does *exactly* what
  you are describing there.

   oooOo.  that's _very_ interesting to hear.  i'd assumed that there
  wouldn't be anything beneficial that wx would bring to the table, by
  using gtk.  ha.  that might be worthwhile doing a pyjd-wx port, then,
  after all.  hmm.

 Well, I may have overstated it a little bit by mistake.

 he he. rats!

 wx does not require you use this model, and it does not do it on its own
 -- you do have to design the flow a little bit.

 wx has two separate containment hierarchies. The first is a
 hierarchical, parent-child relationship. This is what a lot of people
 think is its layout: but its not. It has nothing to do with layout, but
 instead its more about event propagation.

 oh crap, yeah, i forgot about that.  event propagation rules.  darn
it.  y'know what?  forget it - i might as well, seriously, help
implement an entire modern web browser in python, and use that.

 Ahem. /Rant. I'm not saying its the best layout system in the world, but
 like your DOM/HTML example -- its resolution independant (and
 cross-platform), so you can start resizing things and changing the
 window size and it all reflows things as the window resizes. Lots of
 toolkits can do that, but I just really find the sizer approach both
 flexible and very powerful to achieve very usable interfaces. (And its
 very web-like, except the semantic difference of the two hierarchies)

 *sigh* i think i'm just going to have to try it, just to find out.  i
can't have me saying all desktop widget sets are rubbish! if i
haven't _actually_ gone and done my homework, can i?


   from there, you just... open it up in a web browser, just like you
  would any other HTML/CSS/Javascript app.

 Well, I got that much; I more meant the Pyjamas-Desktop thing.

 ohh, right - sorry.

 It makes
 regular seeming application/client-based user interfaces, right? Are
 those all entirely, once run, 100% JavaScript (post-compilation)?

 nope not

Re: GUIs - A Modest Proposal

On 6/14/10 1:00 PM, lkcl wrote:
 On Jun 14, 7:30 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
 On 6/14/10 11:47 AM, lkcl wrote:
 wx has two separate containment hierarchies. The first is a
 hierarchical, parent-child relationship. This is what a lot of people
 think is its layout: but its not. It has nothing to do with layout, but
 instead its more about event propagation.
 
  oh crap, yeah, i forgot about that.  event propagation rules.  darn
 it.  y'know what?  forget it - i might as well, seriously, help
 implement an entire modern web browser in python, and use that.

In practice its a non-issue; the parent-child hierarchy with rare
exception mirrors the sizer layout hierarchy, the latter is just more
dense. And only some kinds of events propagate by default.

Its really not that big of a deal.

If you want to hear when someone clicks a button, you can bind to that
button an event handler (very like JavaScript). Or, if you want, you can
bind a handler to the window, and catch -all- button events (*), and
decide what you want to do based on what button was pressed. I almost
never do this.

Only command events propagate. Those that represent a discrete user
action: a button press, clicking on a radio button, hitting 'enter' in a
text control, a right click. Stuff like that. But you don't have to
treat it like a propagating event-- I almost never do-- and you can
instead just add a handler onto the object itself. The rest of the more
abstract events (mouseover, etc) you have to bind the handler to the
object itself.

 It makes
 regular seeming application/client-based user interfaces, right? Are
 those all entirely, once run, 100% JavaScript (post-compilation)?
 
  nope not in the slightet - the javascript is literally out the
 window, bypassed entirely.  that same application you had which was
 the input to the pyjsbuild compiler pyjsbuild Hello.py?  you just...
 run it!  just like a pygtk2, pyqt4 or python-wx app:

Ahh. Interesting.

 If so, Desktop at least isn't useful to me. :( I can't access omniORB
 with it :)
 
  yeahh, you can... but then if you actually wanted it to be a web app
 as well, you'd be hosed (unless you want to create a browser plugin /
 extension which can talk omniORB!)
 
  what we typically recommend is that _even_ though you're going to run
 the application desktop - as pure python - you still use JSONRPC [or
 XmlHTTPRequest if JSONRPC is overkill].  so, _even_ though it's a
 desktop application, you still run a local 127.0.0.1 web service (even
 python -m SimpleCGIServer.py will do the job!)
 
  rick's article is highly illustrative on all these points:
 http://www.ibm.com/developerworks/web/library/wa-aj-pyjamas/

Hmm. Depending on just how rich of a UI is possible, this is a slightly
compelling idea. Right now, I have to essentially maintain two separate
code-bases: the desktop client and the web application. In my scenario,
both are actually lightweight (though not truly thin) clients to a
master application server existing Elsewhere, that does the heavy
lifting and manages all its users.

Being able to take a code base and provide it to users as a
traditional-seeming desktop application that works desktopy for them,
with-- it sounds like-- two separate processes, one which is Python and
is serving data, and more importantly accessing the MCP and getting
instructions and doing its lightweight local lifting-- and another
which is just a UI that communicates to that local server?

Then one would run basically the same code on a server to allow remote
access on some internet-accessible server, that sounds like what you're
implying is possible? This time the server is still there, but the
client UI is converted into pure JS and shipped to the persons machine.

That sounds too good to be true. I sort of have to be reading too much
into what you're saying.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 14, 7:30 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
 On 6/14/10 11:47 AM, lkcl wrote:

  On Jun 14, 4:17 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
   yes.  that's effectively what pyjs applications are about: as much
  HTML/CSS as you can stand, then _absolute_ pure javascript from there-
  on in... only using a compiler (python-to-javascript) so as not to go
  completely insane - and, from the rest of your message, i _know_ you
  know what i'm talking about, there :)

 Yeah. It sounds very interesting. I just wish it, like, somehow bundled
 webkit cross-platformly. :)

 _that's_ a long story - a brief insight into 8 months of hell i
posted in another message on this thread...

   to be absolutely honest, i very rarely even write my own widgets: i
  advocate that people, myself _especially_ myself included, perform
  literal line-for-line translations of GWT widgets from java to
  python.  why? because, again: on the basis that google have tons of
  money to put into GWT widgets, doing full regression tests, and have
  thousands of users, they can afford to get the widget right across all
  the browsers.  ergo, why duplicate that effort - just code-translate
  it verbatim!

   oh, btw, that's turning into quite a powerful project on its own: the
  goal is to have a fully automated java-to-python translator!

   http://github.com/thoka/java2python

 Somehow this is getting perverse. Java, to Python, to JavaScript. It
 just sounds sort of incestuous. :)

 oh i haven't mentioned the javascript-to-python converter yet, have
i?  *lol*.  am still looking for a good BNF / parser in python, for
that one.

 Well, yes. I have some experience with extjs (and making some pretty
 fantastic real-world seeming apps on the web with it), and yeah,

 The current project occupying my time involves a fairly complicated mix;
 on the server-side we have Pylons, but its interfacing with an external
 application server, so about half of the Pylons layers are outsourced
 (i.e., data and model access).

 Then the web interface is ExtJS. Its just getting very, very -- ungainly
 from a maintenance point of view.

 ooh.  ouch.  we've had people wanting to wrap extjs in pyjamas.  i
told them NO don't for god's sake do it.  it's _hundreds_ of thousands
of lines of javascript; looking at the GWT-EXTJS wrapper, the
startup code in javascript is a whopping 8,000 lines (which was more
than the entire pyjamas codebase at the time!) and the rest of the
wrapper code i believe is some 80,000 lines of java.

 then there's the issue that, apart from all that code to maintain,
you now have a whopping great 2.5mbyte javascript dependency, where
you'd need, if there was a bug in that, an expert javascript
programmer...

 so whilst pyjamas UI widgets are somewhat at the level of extjs
0.01, at least there is http://puremvc.org (which yes, that
_does_ compile to javascript cleanly!) which you can combine with e.g.
the Grid Widget and a few more prettifying widgets, in order to create
the kinds of looveliness that is extjs.

 Maybe on its next iteration I'll look
 into pyjamas.

 mmm, that leaves you with an all-or-nothing approach.  there's a
trick you could do, which involves using a pyjamas ui Frame widget,
where you could convert the site one bit at a time.  that's been done
before now.

 if you're already using an AJAX approach in the back-end server
(which it sounds like you are) then you'll be much much further ahead
than many pyjamas converts: all you'd need to do is reimplement page-
by-page the front-end widgets.

 ok gotta go, baby's dragging me away.

 l
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 14, 2:30 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:

Stephan speaking of Wx geometry managers...

 Ahem. /Rant. I'm not saying its the best layout system in the world, but
 like your DOM/HTML example -- its resolution independant (and
 cross-platform), so you can start resizing things and changing the
 window size and it all reflows things as the window resizes. Lots of
 toolkits can do that, but I just really find the sizer approach both
 flexible and very powerful to achieve very usable interfaces. (And its
 very web-like, except the semantic difference of the two hierarchies)

Oh Stephan i strongly disagree with that assessment. Tkinter blows Wx
away with it's simultaneousness powerful AND elegantly simplistic
geometry managers, grid, pack, and place. If you have not used them to
any extent i strongly encourage you do so before boasting on the
superiority of Wx geometry management. It's like night and day really.
Wx is very ugly in this respect, again due to fact it has a C base
developer pool.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 14, 2:16 pm, lkcl luke.leigh...@gmail.com wrote:
 On Jun 14, 5:57 pm, rantingrick rantingr...@gmail.com wrote:

  I'll have to very much agree with this assessment Stephan. There
  exists not elegant API for these web UI's. The people over at
  SketchUp (my second love after python) have this problem on a daily
  bases with WebDialogs. Even the javascript gurus have a dificult time
  juggling javascript, CSS, and Ruby code to make these grumpy beasts
  come to life, and when they do it ain't really pretty.

  ah.  again, the recommended pyjamas development model vs the
 standard development model comes to the rescue, here.  in a pyjamas
 app, the app loads ONCE and ONLY ONCE, as one whopping great
 javascript behemoth which can be somewhere around 2mb if the original
 python (pyjamas) source is around... 15 to 20,000 lines of code.

Hmm, we have a Python API already worked out. I wonder how much
trouble it would be to get pyjamas into this API. The SketchUp folks
are just busting at the seems for a more developer friendly web dialog
environment and SketchUp WebDialogs just ain't cutting the mustard
(more like the cheese!). Let me know if you may interested in
spearheading this endeavor as i can offer my motivational skills to
push the product and help you work out a friendly API!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On 6/14/10 3:44 PM, rantingrick wrote:
 On Jun 14, 2:30 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
 
 Stephan speaking of Wx geometry managers...
 
 Ahem. /Rant. I'm not saying its the best layout system in the world, but
 like your DOM/HTML example -- its resolution independant (and
 cross-platform), so you can start resizing things and changing the
 window size and it all reflows things as the window resizes. Lots of
 toolkits can do that, but I just really find the sizer approach both
 flexible and very powerful to achieve very usable interfaces. (And its
 very web-like, except the semantic difference of the two hierarchies)
 
 Oh Stephan i strongly disagree with that assessment. Tkinter blows Wx
 away with it's simultaneousness powerful AND elegantly simplistic
 geometry managers, grid, pack, and place. If you have not used them to
 any extent i strongly encourage you do so before boasting on the
 superiority of Wx geometry management. It's like night and day really.
 Wx is very ugly in this respect, again due to fact it has a C base
 developer pool.

I am familiar with grid, pack and place.

Are you arguing from an API point of view, or a functionality point of
view? I have no interest in debating the Pythonisity of Tkinter's API to
wxPython's -- its pointless, neither are particularly Pythonic, and I've
never argued wx does not have an API difficulty and learning curve.

From a functionality perspective, pack and grid are both distinctly
less capable then wx sizers. In the simpliest of interfaces, they
achieve similar goals in similar ways: but the lack of proportional
sizing kills it for me, unless I've been long mistaken in pack not
having a proportional option. A combination of fill/expand and
anchor do most of everything else, though, that wx's flags and
alignment options.

I've no interest in talking about place; absolute positioning is
simply pointless to me.

Now, from an API perspcetive? I'll not debate the merits of which is
better, except that your conclusion of 'why' its 'ugly' and difficult
that its a C based tool, is wrong. The API difficulty comes from the
fact that sizers are separate from containers, and that individual
items added to them don't actually have any internal knowledge of their
sizer environment. This creates some cumbersome interactions. However,
this can be largely made easier (And vastly more Pythonic) by simply
basing wx.lib.sized_controls as the base.

Then, instead of explicit sizer tweaking, you do things like:

import wx.lib.sized_controls as sc

class MyPanel(sc.SizedPanel):
def __init__(self):
sc.SizedPanel(self, -1)
self.SetSizerType(horizontal)

b1 = wx.Button(self, -1, OK)
b2 = wx.Button(self, -1, Cancel)

b1.SetSizerProps(expand=True)
b2.SetSizerProps(expand=True)

You can rewrite something very similar in Tkinter, sure. And you'll have
shorter names, and maybe you can argue 'pack' is more pythonic then
'SetSizerProps', but debating API pythonicity is just uneventful.

My original comments were about function, not form. I mean, we're
discussing the DOM here. There's never been a more hideous designed API
in the history of API's.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 14, 2:34 am, Stephen Hansen me+list/pyt...@ixokai.io wrote:
 HTML+CSS have some very strong advantages. Simplicity is not one of
 them. Precision web design these days is a dark art. (Go center an image
 vertically and horizontally in an arbitrary sized field!)

I agree, and I know that's a rhetorical question, but here goes

(I have no idea whether this works in IE though)

!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN DTD/xhtml1-
strict.dtd
html
head
style
div {
position: absolute;
border: 1px solid blue;
margin: 10px;
}
#one {
top: 50px;
width: 300px;
height: 300px;
}
#two {
top: 400px;
width: 200px;
height: 200px;
}
img {
position: absolute;
width:100px;
height: 100px;
margin: auto;
top: 0;
bottom: 0;
left: 0;
right: 0;
border: 1px solid red;
}
/style
/head
body
div id=oneimg src=image.jpg //div
div id=twoimg src=image.jpg //div
/body
/html


--
Cheers
Anton
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-14 Thread Ed Keith

--- On Mon, 6/14/10, AD. anton.l...@gmail.com wrote:

 From: AD. anton.l...@gmail.com
 Subject: Re: GUIs - A Modest Proposal
 To: python-list@python.org
 Date: Monday, June 14, 2010, 7:51 PM
 On Jun 14, 2:34 am, Stephen Hansen
 me+list/pyt...@ixokai.io
 wrote:
  HTML+CSS have some very strong advantages. Simplicity
 is not one of
  them. Precision web design these days is a dark art.
 (Go center an image
  vertically and horizontally in an arbitrary sized
 field!)

 I agree, and I know that's a rhetorical question, but here
 goes

 (I have no idea whether this works in IE though)

 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
 DTD/xhtml1-
 strict.dtd
 html
 head
 style
 div {
     position: absolute;
     border: 1px solid blue;
     margin: 10px;
     }
 #one {
     top: 50px;
     width: 300px;
     height: 300px;
     }
 #two {
     top: 400px;
     width: 200px;
     height: 200px;
     }
 img {
     position: absolute;
     width:100px;
     height: 100px;
     margin: auto;
     top: 0;
     bottom: 0;
     left: 0;
     right: 0;
     border: 1px solid red;
     }
 /style
 /head
 body
 div id=oneimg src=image.jpg
 //div
 div id=twoimg src=image.jpg
 //div
 /body
 /html

 --
 Cheers
 Anton
 -- 
 http://mail.python.org/mailman/listinfo/python-list

But that is in a fixed size field, can you make the height change based on the 
height of the browser window, and still keep it centered?

-EdK

Ed Keith
e_...@yahoo.com

Blog: edkeith.blogspot.com

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On 6/14/10 4:51 PM, AD. wrote:
 On Jun 14, 2:34 am, Stephen Hansen me+list/pyt...@ixokai.io wrote:
 HTML+CSS have some very strong advantages. Simplicity is not one of
 them. Precision web design these days is a dark art. (Go center an image
 vertically and horizontally in an arbitrary sized field!)
 
 I agree, and I know that's a rhetorical question, but here goes
 

Arbitrarily sized was the key point ;-) In that, you set the sizes of
the div's explicitly. I wasn't clear in my rhetorical question; the size
is arbitrary because you have no control over it.   You can do horizontal
center easy; just set margin-left and margin-right to auto (and be sure
to set display: block if you're not sure which mode you'll end up).
Vertical centering outside of a table cell is a right pain in the ass.  

Like so: Create an HTML single image that sits dead in the center of
your screen when your browser is maximized. Then if you adjust your
browser to be half as wide, its still in the center. Just the new center.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 15, 11:59 am, Ed Keith e_...@yahoo.com wrote:
 But that is in a fixed size field,

That's why I used the same image definition in two different sized
divs to show that the images position wasn't determined by the divs
size.

 can you make the height change based on the height of the browser window, and 
 still keep it centered?

Like this? The div is sized according to the browser window and
centered. The image is a fixed size, but still centered within the
div.

!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN DTD/xhtml1-
strict.dtd
html
head
style

div {
position: absolute;
border: 1px solid blue;
margin: auto;
top: 10%;
bottom: 10%;
left: 10%;
right: 10%;
}

img {
position: absolute;
width:100px;
height: 100px;
margin: auto;
top: 0;
bottom: 0;
left: 0;
right: 0;
border: 1px solid red;
}

/style
/head
body

div
img src=image1.jpg /
/div

/body
/html

--
Cheers
Anton
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-14 Thread Ed Keith

Nice! I've been looking for that trick for some time.

Thank you,

   -EdK

Ed Keith
e_...@yahoo.com

Blog: edkeith.blogspot.com


--- On Mon, 6/14/10, AD. anton.l...@gmail.com wrote:

 From: AD. anton.l...@gmail.com
 Subject: Re: GUIs - A Modest Proposal
 To: python-list@python.org
 Date: Monday, June 14, 2010, 8:56 PM
 On Jun 15, 11:59 am, Ed Keith e_...@yahoo.com
 wrote:
  But that is in a fixed size field,
 
 That's why I used the same image definition in two
 different sized
 divs to show that the images position wasn't determined by
 the divs
 size.
 
  can you make the height change based on the height of
 the browser window, and still keep it centered?
 
 Like this? The div is sized according to the browser window
 and
 centered. The image is a fixed size, but still centered
 within the
 div.
 
 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
 DTD/xhtml1-
 strict.dtd
 html
 head
 style
 
 div {
     position: absolute;
     border: 1px solid blue;
     margin: auto;
     top: 10%;
     bottom: 10%;
     left: 10%;
     right: 10%;
     }
 
 img {
     position: absolute;
     width:100px;
     height: 100px;
     margin: auto;
     top: 0;
     bottom: 0;
     left: 0;
     right: 0;
     border: 1px solid red;
     }
 
 /style
 /head
 body
 
 div
 img src=image1.jpg /
 /div
 
 /body
 /html
 
 --
 Cheers
 Anton
 -- 
 http://mail.python.org/mailman/listinfo/python-list
 


  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 15, 12:06 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
 Arbitrarily sized was the key point ;-) In that, you set the sizes of
 the div's explicitly.

As I said to Ed, I think you missed why I included the exact same
image in two divs of different sizes. That was to show it was still
centered no matter what size the container was. It is even easier to
fit it to the browser window.

 I wasn't clear in my rhetorical question; the size
 is arbitrary because you have no control over it.       You can do horizontal
 center easy; just set margin-left and margin-right to auto (and be sure
 to set display: block if you're not sure which mode you'll end up).
 Vertical centering outside of a table cell is a right pain in the ass.  

 Like so: Create an HTML single image that sits dead in the center of
 your screen when your browser is maximized. Then if you adjust your
 browser to be half as wide, its still in the center. Just the new center.

Even easier than the first example:

(Yeah I know these are trivial and quickly get out of hand on a real
UI)

!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN DTD/xhtml1-
strict.dtd
html
head
style

img {
position: absolute;
width:100px;
height: 100px;
margin: auto;
top: 0;
bottom: 0;
left: 0;
right: 0;
border: 1px solid red;
}

/style
/head
body

img src=image1.jpg /

/body
/html

Anyway, wasn't this supposed to be about Python :)

--
Cheers
Anton
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 15, 1:03 pm, Ed Keith e_...@yahoo.com wrote:
 Nice! I've been looking for that trick for some time.

 Thank you,

A lot of people (including pro web designers even) aren't really aware
of what CSS can actually do. Part of the problem is that everyone only
learnt the semi working subset that wouldn't fall to pieces in
Internet Explorer.

Don't get too excited though, while these proof of concept examples
are easy once you put that into real world usage you'll notice that
the absolutely positioned items are outside the normal flow and won't
hold open containers - especially those that use a different
positioning model etc. I reckon the main limitation with CSS is that
it doesn't let you mix it's different positioning models together very
easily.

Now, back to talking about Python GUIs... :)

--
Cheers
Anton
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-14 Thread python

Anton,

Very nice. 

As an aside: I don't think you need to explicitly set your image size,
eg. I found your examples worked well with the following CSS properties
removed from the img specification:

width:100px; 
height: 100px;

Malcolm
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On 6/14/10 6:02 PM, AD. wrote:
 On Jun 15, 12:06 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
 Arbitrarily sized was the key point ;-) In that, you set the sizes of
 the div's explicitly.
 
 As I said to Ed, I think you missed why I included the exact same
 image in two divs of different sizes. That was to show it was still
 centered no matter what size the container was. It is even easier to
 fit it to the browser window.

I didn't miss it at all; I just didn't accept (and still don't
-entirely-) that positioning within an explicitly sized div is the same
thing as one which has had a flow-determined size.

But! That said:

 Like so: Create an HTML single image that sits dead in the center of
 your screen when your browser is maximized. Then if you adjust your
 browser to be half as wide, its still in the center. Just the new center.
 
 Even easier than the first example:

Very nice. And interesting. position: absolute there is a mystery to
me and seems to be key, I'm not sure entirely what it is doing to the
layout manager in that scenario, but it seems to do the trick.

Much, much, much Googling led me to try many things to get it just
right, and all bemoaned the lack of a solid way to vertically center:
all the while using essentially similar methods to horizontally center.

Anyways. :)

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 14, 6:27 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
 I am familiar with grid, pack and place.

Apparently not, read on...

 Are you arguing from an API point of view, or a functionality point of
 view? snip

I going to argue that Tkinter offers the most elegant interface for
geometry management. And i'll leave it at that.

 From a functionality perspective, pack and grid are both distinctly
 less capable then wx sizers. In the simpliest of interfaces, they
 achieve similar goals in similar ways: but the lack of proportional
 sizing kills it for me, unless I've been long mistaken snip

YOU HAVE BEEN LONG MISTAKEN MY FRIEND! :-). It seems the answer was
right under your nose and like bad breath you failed to smell it. Here
is the first paragraph for the docs of place geometry manager...

The Place geometry manager is the simplest of the three general
geometry managers provided in Tkinter. It allows you explicitly set
the position and size of a window, either in absolute terms, or
relative to another window.

 I've no interest in talking about place; absolute positioning is
 simply pointless to me.

That argument ceases to be relevant. See the triple quoted text for
an explanation as to why it is irrelevant and based on ignorance.

 unless I've been long mistaken in pack not
 having a proportional option. A combination of fill/expand and
 anchor do most of everything else, though, that wx's flags and
 alignment options.

snip code

 You can rewrite something very similar in Tkinter, sure. And you'll have
 shorter names, and maybe you can argue 'pack' is more pythonic then
 'SetSizerProps', but debating API pythonicity is just uneventful.

What is this fascination with pack all about Stephan? The pack
geometry manager is the least useful of the three. Grid is your most
useful all around manager for laying out complex widget displays.
However that fact is not obvious to most Tkinter noobs because they do
not know about the rowconfigure and columnconfigure options that
allow for dynamic resizing of widgets within a container based on a
weight factor. There are also options for sticky behavior. The
following is my suggestions on when to use and *not* to use grid,
pack, and/or place.

GRID: Try to use grid for almost everything because it is the most
versatile of the three. However there are specific corner cases for
pack and place. Also never use grid and pack within the same
container widget or you'll cause Tk to lock up. You *can* however
use both managers in the same application as long as the widgets you
call pack and grid for do not share the same parent. Also like i
mentioned before you can get a dynamic resizing behavior on *any* or
*all* cols and rows by calling parent.rowconfigure(weight) and
parent.columnconfigure(weight). Use a weight of 1 to get full
elasticity ;). We all could use a bit more elasticity, no?

PACK: Only use pack if you have one widget and you wish it to fill
it's entire parent OR if you are stacking widgets in a horizontal or
vertical alignments (like a toolbar). This is where pack really
shines!

PLACE: Offers absolute and relative placements of widgets. Place will
not be used often but most of it's functionality can not be reproduced
with the other two options. Take for example the masks that are part
of a notebook widget, or placing a small button in the top left corner
of a frame or whatever...

The only people who like Wx geometry managers are the same who have no
experience with Tkinter's beautiful geometry managers. I encourage you
to investigate them for yourself. If anyone needs help feel free to
send me a private email or ask here on c.l.p.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 14, 6:27 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:

 From a functionality perspective, pack and grid are both distinctly
 less capable then wx sizers.

Are you just flapping your gums or can you prove it Stephen? I will
accept any Pepsi Challenge you can muster in Wx code and echo that
same capability using Tkinter[1] in what will be no less than elegant
simplicity. So bring it on baby!

[1] But please, make sure to post code that will run as-is. The last
block of wx code you posted is missing an application instance and
will not run without modification. There are noobs watching and we to
provide code that can be used to teach!


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On 6/14/10 7:05 PM, rantingrick wrote:
 The Place geometry manager is the simplest of the three general
 geometry managers provided in Tkinter. It allows you explicitly set
 the position and size of a window, either in absolute terms, or
 relative to another window.
 
 I've no interest in talking about place; absolute positioning is
 simply pointless to me.
 
 That argument ceases to be relevant. See the triple quoted text for
 an explanation as to why it is irrelevant and based on ignorance.

I didn't make an argument, so it can't be relevant or not. It remains
pointless.

 unless I've been long mistaken in pack not
 having a proportional option. A combination of fill/expand and
 anchor do most of everything else, though, that wx's flags and
 alignment options.
 
 snip code
 
 You can rewrite something very similar in Tkinter, sure. And you'll have
 shorter names, and maybe you can argue 'pack' is more pythonic then
 'SetSizerProps', but debating API pythonicity is just uneventful.
 
 What is this fascination with pack all about Stephan? The pack
 geometry manager is the least useful of the three. Grid is your most
 useful all around manager for laying out complex widget displays.
 However that fact is not obvious to most Tkinter noobs because they do
 not know about the rowconfigure and columnconfigure options that
 allow for dynamic resizing of widgets within a container based on a
 weight factor. There are also options for sticky behavior. The
 following is my suggestions on when to use and *not* to use grid,
 pack, and/or place.

I wasn't aware of [row|column]configure, no: however, I am dubious of
how it directly applies.

Consider this relatively simple user interface layout:
http://ixokai.io/get/layout-grid.jpg

In this context, we have two principle columns, A and B. A has a set
size, B grows to fill the rest of the dialog.

Inside of A, there are four items in a vertical line. The bottom which
takes up half of the total vertical space (poorly drawn, trust me, F
should be half :)), and the top three share the rest.

Inside of B, G is one third the size of H.

The layout should fully resize itself as the window is resized.

How would you implement that in tkinter? It sounds like you'd have a
grid with a pair of one-column grids, which is slightly bizarre seeming.

 The only people who like Wx geometry managers are the same who have no
 experience with Tkinter's beautiful geometry managers. I encourage you
 to investigate them for yourself. If anyone needs help feel free to
 send me a private email or ask here on c.l.p.

And exactly what's so great about it? All of the things you said it can
do, wx can do easily.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On 6/14/10 7:22 PM, rantingrick wrote:
 On Jun 14, 6:27 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
 [1] But please, make sure to post code that will run as-is. The last
 block of wx code you posted is missing an application instance and
 will not run without modification. There are noobs watching and we to
 provide code that can be used to teach!

No.


-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 15, 1:21 pm, pyt...@bdurham.com wrote:
 Anton,

 Very nice.

 As an aside: I don't think you need to explicitly set your image size,

Yeah, I only did that because I was assuming the image path would
actually be broken (and it was for me too) - it was just to 'simulate'
a 100x100 image :)

--
Cheers
Anton

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On 6/14/10 7:22 PM, rantingrick wrote:
 On Jun 14, 6:27 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
 
 From a functionality perspective, pack and grid are both distinctly
 less capable then wx sizers.
 
 Are you just flapping your gums or can you prove it Stephen? I will
 accept any Pepsi Challenge you can muster in Wx code and echo that
 same capability using Tkinter[1] in what will be no less than elegant
 simplicity. So bring it on baby!

But, as to capabilities-- the ones I use not infrequently:

  - Shaped expansion: the control maintains its aspect ratio.
  - Fitting: The parent widget is resized so that it is the right size
to contain all of its children widgets at their 'best' size (which is
configured per-widget, and not per-column; min sizes on a column is
insufficient). I absolutely adore this feature.
  - Alignment. If a widget is allocated 100x100 of space (due to
proportion rules), but not set to expand, control over if it should
center directly, or be aligned top-center or left-middle.
  - Spacers. As in a virtual 'widget' which takes up space but doesn't
really exist. Yeah, you can just put some empty looking widget in there,
but that's a hack. Still, this is only a nitpick.

I'm not interested in dueling code, but capabilities.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 15, 1:58 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
 Very nice. And interesting. position: absolute there is a mystery to
 me and seems to be key, I'm not sure entirely what it is doing to the
 layout manager in that scenario, but it seems to do the trick.

The Cliff Notes:

position: absolute allows different combos/subsets of
left,right,top,bottom,width,height to define where each edge is in
relation to the edges of its closest parent that has also been
positioned that way or the browser window if there is none. But it
does take that element out of the normal flow (like a float does),
which means all the statically positioned stuff won't interact with it
at all - that can be enough to negate the usefulness of it all.

position: relative is similar, but the edge offsets apply to where the
element would normally have sat rather than the edges of an explicitly
positioned parent element.


 Much, much, much Googling led me to try many things to get it just
 right, and all bemoaned the lack of a solid way to vertically center:
 all the while using essentially similar methods to horizontally center.

I'd recommend the book Pro CSS and HTML Design Patterns from Apress
for anyone who wants to get a more formal understanding of these
different models etc.

--
Cheers
Anton
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 14, 9:41 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:

 I wasn't aware of [row|column]configure, no: however, I am dubious of
 how it directly applies.

Maybe you should become more aware of a subject before you start
running your mouth about it, eh?

 Consider this relatively simple user interface 
 layout:http://ixokai.io/get/layout-grid.jpg

 In this context, we have two principle columns, A and B. A has a set
 size, B grows to fill the rest of the dialog.

 Inside of A, there are four items in a vertical line. The bottom which
 takes up half of the total vertical space (poorly drawn, trust me, F
 should be half :)), and the top three share the rest.

 Inside of B, G is one third the size of H.

 The layout should fully resize itself as the window is resized.

 How would you implement that in tkinter? It sounds like you'd have a
 grid with a pair of one-column grids, which is slightly bizarre seeming.

Please at least try to make it a bit harder next time, really!

import Tkinter as tk
app = tk.Tk()
app.columnconfigure(1, weight=1)
app.rowconfigure(3, weight=1)
tk.Button(app, text='C', width=20).grid(row=0, column=0,
sticky='nswe')
tk.Button(app, text='D', width=20).grid(row=1, column=0,
sticky='nswe')
tk.Button(app, text='E', width=20).grid(row=2, column=0,
sticky='nswe')
tk.Button(app, text='F', width=20).grid(row=3, column=0, rowspan=2,
sticky='nswe')
tk.Button(app, text='G').grid(row=0, column=1, rowspan=2,
sticky='nswe')
tk.Button(app, text='H').grid(row=2, column=1, rowspan=2,
sticky='nswe')
app.mainloop()

...but i won't hold my breath awaiting for your spectacular Wx code
because i know it was just vaporware from gum_flap[0] on.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On 6/14/10 8:04 PM, AD. wrote:
 Much, much, much Googling led me to try many things to get it just
 right, and all bemoaned the lack of a solid way to vertically center:
 all the while using essentially similar methods to horizontally center.
 
 I'd recommend the book Pro CSS and HTML Design Patterns from Apress
 for anyone who wants to get a more formal understanding of these
 different models etc.

Favorite'd on Safari, thanks for the tip.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/

P.S. Once upon a time, I'd have Amazon'd the book and skimmed it and
then lost it, and bought it again. I love Safari.



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On 6/14/10 8:31 PM, rantingrick wrote:
 On Jun 14, 9:41 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
 
 I wasn't aware of [row|column]configure, no: however, I am dubious of
 how it directly applies.
 
 Maybe you should become more aware of a subject before you start
 running your mouth about it, eh?

You know what?

You're an asshole.

Just saying.

I've been trying very hard not to say, Go screw yourself, jackass for
a few days now. Very hard. I've tried very hard to remain civil.

But really, I just feel a need to say it.

You're a complete and utter jackass.

Just saying.

 Consider this relatively simple user interface 
 layout:http://ixokai.io/get/layout-grid.jpg

 In this context, we have two principle columns, A and B. A has a set
 size, B grows to fill the rest of the dialog.

 Inside of A, there are four items in a vertical line. The bottom which
 takes up half of the total vertical space (poorly drawn, trust me, F
 should be half :)), and the top three share the rest.

 Inside of B, G is one third the size of H.

 The layout should fully resize itself as the window is resized.

 How would you implement that in tkinter? It sounds like you'd have a
 grid with a pair of one-column grids, which is slightly bizarre seeming.
 
 Please at least try to make it a bit harder next time, really!
 
 import Tkinter as tk
 app = tk.Tk()
 app.columnconfigure(1, weight=1)
 app.rowconfigure(3, weight=1)
 tk.Button(app, text='C', width=20).grid(row=0, column=0,
 sticky='nswe')
 tk.Button(app, text='D', width=20).grid(row=1, column=0,
 sticky='nswe')
 tk.Button(app, text='E', width=20).grid(row=2, column=0,
 sticky='nswe')
 tk.Button(app, text='F', width=20).grid(row=3, column=0, rowspan=2,
 sticky='nswe')
 tk.Button(app, text='G').grid(row=0, column=1, rowspan=2,
 sticky='nswe')
 tk.Button(app, text='H').grid(row=2, column=1, rowspan=2,
 sticky='nswe')
 app.mainloop()

Does not perform to spec. Quote, Inside of A, there are four items in a
vertical line. The bottom which takes up half of the total vertical
space, and the top three share the rest.

Notice in: http://ixokai.io/get/layout-results-tk.jpg

That C, D, and E do not expand as they do, but instead F takes it all,
when it is supposed ot be entitled to only half of the vertical space.

Compare: http://ixokai.io/get/layout-results-wx1.jpg
And: http://ixokai.io/get/layout-results-wx2.jpg

I took some extra care to colorize the panels so its easy to see the
layout characteristics.

The code is at: http://ixokai.io/get/layout-wx.py_

Yes, its more verbose. And object oriented. This is a positive. I could
have made it all a great deal shorter and more concise, but left it
verbose for clarity's sake.

 
 ...but i won't hold my breath awaiting for your spectacular Wx code
 because i know it was just vaporware from gum_flap[0] on.

Go screw yourself.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On 6/14/10 9:08 PM, Stephen Hansen wrote:
 The code is at: http://ixokai.io/get/layout-wx.py_

If you've already downloaded this, you have to do so again; I uploaded
the wrong one on accident.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 14, 11:08 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:

  Maybe you should become more aware of a subject before you start
  running your mouth about it, eh?

 You know what? SNIP EXPLETIVES

You know what Stephen, just calm down a little. I just pick on you
because you're one of the few people here that i enjoy arguing with.
Anyhoo i ran your code and got this traceback...

Traceback (most recent call last):
  File C:/Python26/tempGridWx.py, line 64, in module
main()
  File C:/Python26/tempGridWx.py, line 60, in main
app = TestApp(0)
  File C:\Python26\lib\site-packages\wx-2.8-msw-ansi\wx\_core.py,
line 7978, in __init__
self._BootstrapApp()
  File C:\Python26\lib\site-packages\wx-2.8-msw-ansi\wx\_core.py,
line 7552, in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
  File C:/Python26/tempGridWx.py, line 52, in OnInit
frame = TestFrame(None)
  File C:/Python26/tempGridWx.py, line 8, in __init__
panel_c = wx.Panel(self, -1, width=(100, -1))
  File C:\Python26\lib\site-packages\wx-2.8-msw-ansi\wx\_windows.py,
line 68, in __init__
_windows_.Panel_swiginit(self,_windows_.new_Panel(*args,
**kwargs))
TypeError: 'width' is an invalid keyword argument for this function

... i was hoping you would post some code that did not blow chunks and
since your explanations are a bit hard to follow i will await the bug-
free Wx code so nothing else is again lost in translation. When the
bug free code is supplied i will create the Tkinter mirror of it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On 6/14/10 9:26 PM, rantingrick wrote:
 On Jun 14, 11:08 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
 
 Maybe you should become more aware of a subject before you start
 running your mouth about it, eh?

 You know what? SNIP EXPLETIVES
 
 You know what Stephen, just calm down a little. I just pick on you
 because you're one of the few people here that i enjoy arguing with.
 Anyhoo i ran your code and got this traceback...

Argue.

Don't be an asshole.

There's a difference.

 ... i was hoping you would post some code that did not blow chunks and
 since your explanations are a bit hard to follow i will await the bug-
 free Wx code so nothing else is again lost in translation. When the
 bug free code is supplied i will create the Tkinter mirror of it.

I already uploaded the replacement. I pasted from my mac box instead of
my windows one where I tested it out ('cuz my mac Python installation is
keyed to work and doesn't like wx) on accident.


-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 14, 11:08 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
snip

 Does not perform to spec. Quote, Inside of A, there are four items in a
 vertical line. The bottom which takes up half of the total vertical
 space, and the top three share the rest.

No problem, check this out...

import Tkinter as tk
app = tk.Tk()
app.geometry('400x400+20+20')
# Left
tk.Label(app, text='C', bg='red', width=20).place(rely=0.0,
relheight=0.1667, width=200)
tk.Label(app, text='D', bg='blue', width=20).place(rely=0.1667,
relheight=0.1667, width=200)
tk.Label(app, text='E', bg='green', width=20).place(rely=0.,
relheight=0.1667, width=200)
tk.Label(app, text='F', bg='white', width=20).place(rely=0.5,
relheight=0.5, width=200)
# Right
tk.Label(app, text='G', bg='purple').place(x=200, rely=0.0,
relheight=0.333, relwidth=1)
tk.Label(app, text='H', bg='orange').place(x=200, rely=0.,
relheight=0.777, relwidth=1)
app.mainloop()


However *your* code does not perform to your own spec! You said
this...
 Inside of B, G is one third the size of H.

If you mean that G should be one-third the height of H then your
code (and yes i have the new version that does not blow chunks!) does
not follow this spec! Better re-check my friend. ;-)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: safer ctype? (was GUIs - A modest Proposal)

On 6/12/10 8:26 PM, Gregory Ewing wrote:
 On Jun 12, 6:05 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
 
 A programming goof, oversight or unexpected event causes an exception.
 It doesn't cause a buffer overflow.
 
 The important thing here isn't so much the exception as
 the *traceback*.
 
 When you've been programming in Python for a while, it's
 easy to forget how much help the traceback is in tracking
 down bugs. Suddenly being faced with having to do without
 one comes as a rude shock.

Oh, agreed absolutely.

The exception just gets things started. If its something you're prepared
for, you can recover just fine.

Worst case scenario, you get a traceback.

And you pity those people who have to have gdb running before hand and
get a stack trace ;-)


-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: safer ctype? (was GUIs - A modest Proposal)

On 6/12/10 8:42 PM, Gregory Ewing wrote:
 Stephen Hansen wrote:
 
 Its one thing for Python to make available foot-shooting tools(this is
 good! I love ctypes, with care) for the developer, its another thing
 entirely for it to shoot at the ground in the normal course of its
 operation and hope it doesn't blow off any big toes. :)
 
 I would hope that a module included in the stdlib was written
 by a sufficiently skilled marksman that it can successfully
 carry out ground-targeting without loss of appendages. And I'd
 better stop before this metaphor undergoes a sudden catastrophic
 stress fracture.

Wow, I had difficulty taking the metaphor as far as I did. I bow to you,
sir! :)

 Seriously, though, if you can't trust someone to write safe
 ctypes-using code, can you trust them to write safe C code any
 better? Especially considering that the equivalent C code is
 much longer and more tedious to write, with attendant risk of
 the author losing concentration and making a mistake.

I don't disagree at all; in fact I consider the use of ctypes entirely
fine, if the devs doing it take sufficient care.

But I do get the point of the policy, even though in certain cases --
namely, win32 api access -- it pains me and I wish there could be a
middle-way which gave me the best of both worlds.

If ctypes is in place, then anything can use ctypes. Clearly, that stuff
which may make it into the stdlib will be best of breed from a safety
stand point, and they're using ctypes just as a maintenance relief and
not due to lack of ability or knowledge.

But now -everything- has access to ctypes. And that's sort of dangerous.
I've been in environments where corporate / security interests were such
that they'd like to /not/ have ctypes, as the safety of Python was a key
selling point. Removing ctypes preserves that safety. But you can't have
the stdlib breaking then, with only certain parts working.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On 6/12/10 8:34 PM, Gregory Ewing wrote:
 lkcl wrote:
 
  * in neither gtk nor qt does there exist an auto-layout widget
 that's equivalent to putting some span / DOM objects into a div /,
 to flow widgets that wrap around.
 
 You essentially seem to be complaining here that pqyqt and
 pygtk are not HTML. They have their own auto-layout mechanisms
 that do what they're designed to do well enough -- they just
 happen to be based on a different model from HTML.
 
 I'm far from convinced that HTML and CSS are the One True Way
 to design GUIs these days, that web apps are about to take over
 the world, etc. There is still a place for GUI toolkits that
 are not based on the DOM, or whatever the W3C technology of
 the month is.

Agreed. While web interfaces have a certain appeal, and definite
strengths, they have difficulties as well.

Although I have never used gtk directly, I do use wxWidgets/wxPython
extensively, and its Linux-port is GTK based. Its a serious learning
curve, I do freely admit. But once I began to think in wx, it works well.

And all of my wxPython apps use dynamic / auto-layout sort of
orientation and sizing without any sort of explicit management. So its
clearly -possible-. Maybe its entirely done in wx, and wx does all the
pain that lkcl went through trying to get gtk to do it. But that seems
unlikely.

But I don't actually know, one way or the other.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On 6/12/10 8:22 PM, Gregory Ewing wrote:
 Terry Reedy wrote:
 
 Would it be possible to write a program that converts a module that
 uses ctypes to interface to a dll to a corresponding C extension
 program that would compile to a drop in replacement extension module?
 
 Probably, but I don't see how that could be done automatically
 in a way that ensured the result would be any safer than the
 original ctypes-using version. If you preserve the semantics of
 the Python code, you also preserve any bugs it might have.

I dunno. This is exactly what Cython does. I have exactly one extension
module in Cython that uses it, and so very limited experience-- but it
seems very solid and very safe, from my admittedly limited attempts at
breaking it.

True, Cython != Python. But its close enough that Python programmers can
do it without knowing the pain of C, just following a certain limited
Python subset. Its very doable, very accessible, and *seems* to address
this very issue.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-13 Thread Jeremy Sanders

lkcl wrote:

  * in neither gtk nor qt does there exist an auto-layout widget
 that's equivalent to putting some span / DOM objects into a div /,
 to flow widgets that wrap around.  yes, you can put words into a
 Label and get them to flow, but not _widgets_.

I'm pretty sure in PyQt4 that you can derive your own layout class from 
QLayout to get what you want. No C++ is required. You can easily extend PyQt 
without using C++.

There is even an example in the PyQt examples which does something similar 
to what you want: see examples/layouts/flowlayout.py

Personally I find the Qt layout to be much better than anything provided by 
CSS and HTML. Personally I'd rather be writing complex C++ templates that 
those, though it does give you a feeling of achievement when you get what 
you want with CSS.

Jeremy

-- 
Jeremy Sanders
http://www.jeremysanders.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-13 Thread lkcl

On Jun 13, 3:34 am, Gregory Ewing greg.ew...@canterbury.ac.nz wrote:
 lkcl wrote:
   * in neither gtk nor qt does there exist an auto-layout widget
  that's equivalent to putting some span / DOM objects into a div /,
  to flow widgets that wrap around.

 You essentially seem to be complaining here that pqyqt and
 pygtk are not HTML.

 no, i'm not complaining - i'm pointing out that in my meandering
experiences to pick suitable technology, i found, very simply, that
both pyqt and pygtk didn't cut it.  that's not a complaint.  so i'm
stating/implying that from the experience that i had with both
toolkits, pyqt and pygtk were not as easy to create layouts or widgets
with (but caveat: jeremy kindly points out that in pyqt there is
examples/layouts/flowlayout.py)

 another way to put that: i'm stating that, in my search for suitable
technology to implement W3C-standards-like behaviour, such that i
could map an existing widget set API on top of it, i found both pygtk
and pyqt4's bang per buck as far as both extensibility and existing
functionality was concerned to be below an acceptable threshold *for
me*.

 statement of personal experience. not complaint.

 They have their own auto-layout mechanisms
 that do what they're designed to do well enough -- they just
 happen to be based on a different model from HTML.

 one which turns out to be sufficiently different from HTML as to make
it beyond my time and patience to implement one in terms of the
other.  again - that's not a complaint, just a statement that i
prefer to leverage technologies where the bang per buck or better
bang per line-of-code is way above average.


 I'm far from convinced that HTML and CSS are the One True Way
 to design GUIs these days,

 if you have HTML the fileformat and CSS the fileformat in mind
when saying that, i can tell you right now that they're not.
fortunately, with the W3C DOM functions exposing properties and style
attributes, it's possible to manipulate the exact same attributes that
CSS and HTML files provide access to, using a declarative
programming style.

 so with pyjamas you get the best of both worlds.  (and i've found
that the combination of the advanced features of python, and
declarative DOM manipulation, is _definitely_ worthwhile exploring,
and i definitely find it to be far more powerful than pyqt4 or pygtk
programming).

 it's the exact same thing for SVG image file-format.  i'm
_definitely_ not convinced that SVG the image fileformat is The One
True Way to design images - but i'm equally definitely convinced of
the power of SVG manipulation libraries which allow for the creation
SVG images using declarative programming.

 but, all that having been said, and returning to HTML and CSS (the
fileformats), there's a lot to be said for convincing people who are
stuck in those worlds of the benefits and freedom of declarative
programming... _without_ having to get involved directly in
javascript.

 that web apps are about to take over
 the world, etc. There is still a place for GUI toolkits that
 are not based on the DOM,

 that there definitely are.

 or whatever the W3C technology of the month is.

 :) don't underestimate how much time and money is going into the W3C
standards!  and remember, someone's got to implement them, so the
actual proof of the pudding is not what the W3C thinks but whether the
technology ends up actually in the hands of users and is successful
_for users_.

 l.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-13 Thread lkcl

On Jun 13, 9:01 am, Jeremy Sanders jeremy
+complangpyt...@jeremysanders.net wrote:
 lkcl wrote:
   * in neither gtk nor qt does there exist an auto-layout widget
  that's equivalent to putting some span / DOM objects into a div /,
  to flow widgets that wrap around.  yes, you can put words into a
  Label and get them to flow, but not _widgets_.

 I'm pretty sure in PyQt4 that you can derive your own layout class from
 QLayout to get what you want. No C++ is required. You can easily extend PyQt
 without using C++.

 really?  drat.  i could have done with knowing that at the time.
hmmm, perhaps i will return to the pyqt4 port after all.

 There is even an example in the PyQt examples which does something similar
 to what you want: see examples/layouts/flowlayout.py

 excellent!  that actually makes it worthwhile carrying on.  the only
other thing that needs solving is that RichText is forced to have its
width and height set.  but it mayyy be possible to create an
appropriate QLayout derivative: i'll have to see.


 Personally I find the Qt layout to be much better than anything provided by
 CSS and HTML. Personally I'd rather be writing complex C++ templates that
 those, though it does give you a feeling of achievement when you get what
 you want with CSS.

 i didn't point this out at the time (and have done so to graham's
post, but it's worth reiterating briefly here): remember that you're
not _entirely_ stuck with CSS the file-format - you _can_ do
declarative DOM manipulation (from python):

 self.element.style.backgroundColor = #ffcc00

 that's python _not_ javascript :)

 so, now you can create **kwargs jobbies, you can store properties in
xml fileformats, read them and then apply them using **kwargs to the
stylesheets; you can create functions which set multiple CSS
properties at once, based on some calculations and so on.

 so, yah - when you're stuck with just CSS the fileformat, it's a
complete dog.  joy.  lovely.  you can set the width and the
background.  wow, big deal.  but when you start combining it with
python, you've opened up a completely new dimension.

 it's in fact how the entire pyjamas UI widget set is created, by
doing nothing more than direct manipulation of bits of DOM and direct
manipulation of the style properties.  really really simple.

 l.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On 6/13/10 4:29 AM, lkcl wrote:
  it's in fact how the entire pyjamas UI widget set is created, by
 doing nothing more than direct manipulation of bits of DOM and direct
 manipulation of the style properties.  really really simple.

Did you just call DOM manipulation simple with a straight face? I don't
think I've ever seen that before.

HTML+CSS have some very strong advantages. Simplicity is not one of
them. Precision web design these days is a dark art. (Go center an image
vertically and horizontally in an arbitrary sized field!)

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-13 Thread Michael Torrie

On 06/13/2010 05:29 AM, lkcl wrote:
  really?  drat.  i could have done with knowing that at the time.
 hmmm, perhaps i will return to the pyqt4 port after all.

We're now wandering well off-topic here, but then again this thread was
never really on any particular topic.

I have to say I'm really confused as to your issues with GTK and Qt.
I've seen and done all kinds of fancy widget layouts in Qt and have
*never* had to subclass layout.  If you think you need to subclass
QLayout, most of the time you're doing it wrong.  You are familiar with
how the vertical and horizontal layouts and spacers work in Qt, aren't
you?  Sometimes you need a grid for a table or the specialized form
grid.   But other than that you want a dynamically-sizing layouts most
of the time.  And Qt's Vertical and Horizontal layouts do that.

I'm also confused by your claim that GTK lacks the layout widgets you
need as well.  GTK has the GtkHBox layout class which acts much like
your span tag.  Anything to pack in the hbox is automatically layed
out in a dynamicially-resizing way.  Any GTK dialog or window is a
combination of different layouts, nested to get the desired layout.
Works extremely well.

  excellent!  that actually makes it worthwhile carrying on.  the only
 other thing that needs solving is that RichText is forced to have its
 width and height set.  but it mayyy be possible to create an
 appropriate QLayout derivative: i'll have to see.

Again I'm confused here.  I just created a little Window in Qt Designer
and was able to get my RichText (There isn't a Rich Text widget in Qt;
Just TextEdit with Rich text enabled) widget to resize automatically
just fine as I resized the window.  I'm obviously missing something.



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-13 Thread Arndt Roger Schneider


lkcl schrieb:


[snip]

it's the exact same thing for SVG image file-format.  i'm
_definitely_ not convinced that SVG the image fileformat is The One
True Way to design images - but i'm equally definitely convinced of
the power of SVG manipulation libraries which allow for the creation
SVG images using declarative programming.

 



You rather severly underestimate the impact from SVG!
1. SVG is a complete visualization system and not an fancy way to create 
icons.

   SVG and SMIL are an extreme powerful environment. With it's
   possible to create(design) sophisticated graphical and interactive 
--resolution independent--

   applictions without resorting to javascript or direct DOM manipulations.
   Javascript or other languages are still necessary to feed data into 
an SVG

   visualization, but not for much more. Further more SVG and the GPU are
   a natural combination.

2. Many of CSS shiny new features --such as animation originate
  from SVG.
3. SVG-Print: Printing is one of the biggest problems in
  the current IT-landscape. I do not want to install printer
  drivers on each telephon I own, neither on any other device --mobile
  or not. The printer must contain a computer running an OS and has to
  handle an agreed upon page description language (Xml based)...


Using HTML/CSS/DOM/javascript for application building:
Well, yes can be done. HTML is however text oriented; each
application entirely based on this technology will be satured
with text. HTML works reasonable well with applications of the past
two decades, but the importance of text is dwindling and other
graphical means of communication become more and more relevant.


but, all that having been said, and returning to HTML and CSS (the
fileformats), there's a lot to be said for convincing people who are
stuck in those worlds of the benefits and freedom of declarative
programming... _without_ having to get involved directly in
javascript.

 



Any User Interface should be pre-determined;
this concept allows the consequent separation of
application logic and presentation. It's not only important
for Web-applications!


that web apps are about to take over
the world, etc. There is still a place for GUI toolkits 


that
are not based on the DOM,
   



that there definitely are.

 


or whatever the W3C technology of the month is.
   



:) don't underestimate how much time and money is going into the W3C
standards!  and remember, someone's got to implement them, so the
actual proof of the pudding is not what the W3C thinks but whether the
technology ends up actually in the hands of users and is successful
_for users_.

l.

 


The mony part is definitly important. Tk is actually a good example for
the working of money-politics (the absence thereof).

-roger


--
http://mail.python.org/mailman/listinfo/python-list

Re: safer ctype? (was GUIs - A modest Proposal)

2010-06-13 Thread Terry Reedy


On 6/12/2010 11:42 PM, Gregory Ewing wrote:


Seriously, though, if you can't trust someone to write safe
ctypes-using code, can you trust them to write safe C code any
better?


No, and I think you are missing the concern about ctypes. There are two 
issues of ctypes versus safety/security: competance and intention. In an 
environment where one is *not* allowed access to a C compiler, but is 
allowed (partial) access to Python, it may make sense to remove ctypes, 
alone with some other things. I am thinking of a website host, or Google 
apps, perhaps.


Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: WebBrowserProgramming [was: GUIs - A Modest Proposal]

2010-06-13 Thread Aahz

In article cf08e777-b98b-4b7c-96df-e7b127c02...@y4g2000yqy.googlegroups.com,
lkcl  luke.leigh...@gmail.com wrote:

 i'm recording all of these, and any other web browser manipulation
technology that i've ever encountered, here:

 http://wiki.python.org/moin/WebBrowserProgramming

Neat!  Why aren't you including Selenium/Windmill?
-- 
Aahz (a...@pythoncraft.com)   * http://www.pythoncraft.com/

If you don't know what your program is supposed to do, you'd better not
start writing it.  --Dijkstra
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-13 Thread lkcl

On Jun 13, 3:52 pm, Arndt Roger Schneider arndt.ro...@addcom.de
wrote:
 lkcl schrieb:

  [snip]

  it's the exact same thing for SVG image file-format.  i'm
 _definitely_ not convinced that SVG the image fileformat is The One
 True Way to design images - but i'm equally definitely convinced of
 the power of SVG manipulation libraries which allow for the creation
 SVG images using declarative programming.

 You rather severly underestimate the impact from SVG!

 no - i kept things brief, so as not to dominate the postings here:
you've very kindly filled in the blanks, and given far more
information than even i was aware of, which is great.

 1. SVG is a complete visualization system and not an fancy way to create
 icons.

 ... all of which is accessible via DOM manipulation, via the W3C-DOM-
specified functions through the canvas / element.   use of which has
resulted in the creation of a very powerful _python_ library which re-
presents those SVG Canvas functions.  fillRect. saveContext.
translate.

 demo of end-result usage can be seen here:
   http://pyjs.org/examples/gwtcanvas/output/GWTCanvasDemo.html
   http://pyjs.org/examples/asteroids/output/Space.html

 Using HTML/CSS/DOM/javascript for application building:
 Well, yes can be done.

 yes, it could.  personally i wouldn't recommend the javascript bit.
it's too dreadful. :)

 HTML is however text oriented; each
 application entirely based on this technology will be saturated
 with text.

 ah - no, it won't.  isn't.  pyjamas apps are the proof that that
isn't the case.  pyjamas applications contain, at the absolute basics,
_one_ HTML file comprising... about eight lines, the most important
two bits being a meta tag naming the pre-compiled application, and a
script tag with bootstrap.js which knows about the aforementioned
meta tag.  that's _it_.  the rest can be done _entirely_ using
declarative-style programming.

 but... if you _want_ to, that loader file can be a full-blown PHP
app: just as long as that meta tag is there, and the bootstrap.js is
there, the pyjamas app can be initiated on top of the PHP page.
just like any other javascript can be run and can begin to manipulate
the DOM.  so it's just a matter of degree.  you can either specify
almost everything in text HTML/CSS or you can do entire DOM-
manipulation or anything in between, to suit _your_ personal
preference.

 i must not be explaining this very well, for which i apologise.

 or whatever the W3C technology of the month is.

  :) don't underestimate how much time and money is going into the W3C
 standards!  and remember, someone's got to implement them, so the
 actual proof of the pudding is not what the W3C thinks but whether the
 technology ends up actually in the hands of users and is successful
 _for users_.

  l.

 The mony part is definitly important. Tk is actually a good example for
 the working of money-politics (the absence thereof).

 :)  yehhs... and then people complain when it doesn't look good.
interesting neh?

 hence a reason why i'm advocating to leverage the incredible power
of the technologies which _have_ had vast amounts of money/effort
poured into them, with very little effort spent on the leveraging
bit.

 l.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-13 Thread Terry Reedy


On 6/13/2010 7:20 AM, lkcl wrote:


I'm far from convinced that HTML and CSS are the One True Way
to design GUIs these days,


  if you have HTML the fileformat and CSS the fileformat in mind
when saying that, i can tell you right now that they're not.
fortunately, with the W3C DOM functions exposing properties and style
attributes, it's possible to manipulate the exact same attributes that
CSS and HTML files provide access to, using a declarative
programming style.


With all the glamour hoopla over html/css/xml, it took me a while to 
realize that the really important thing is the underlying object model 
that the serialization formats communicate. I know this is a bit like 
saying words are important because of the thougths they express (which 
is not to say that beauty of expression is unimportant), but my point is 
that in explaining pyjames, you are sometimes running up against a 
fascination with the surface layers. Pyjamas requires a different 
orientation.


Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-13 Thread Mark Lawrence


On 12/06/2010 14:44, lkcl wrote:

On Jun 6, 10:49 pm, Kevin Walzerk...@codebykevin.com  wrote:

- Pythonic
- The default GUI (so it replaces Tkinter)
- It has the support of the majority of the Python community
- Simple and obvious to use for simple things
- Comprehensive, for complicated things
- Cross-platform
- Looks good (to be defined)
- As small as possible in its default form


These goals are not all complementary. In fact, some of them, such as
small and comprehensive, are mutually exclusive.


  that's not quite true - you can create a simple core which is easily
extensible with third party contributions to create more comprehensive
widgets.

  in the GWT arena, you have gwt-g3d, gwt-incubator, gwt-gchart and so
on, all of which were created very easily thanks to the power of the
underlying GWT core codebase, _none_ of which are actually included
into GWT by default, _all_ of which can be installed by users and
simply imported just like the core.

  now s/GWT/pyjamas and you have the exact same thing, and all the
satisfiable requirements are met.

  l.


I'd just like to say thanks for opening up this thread. I've never yet 
written any GUI in Python, but should I need to do so this your comments 
and the responses will certainly stick in my mind.


Kindest regards.

Mark Lawrence.

--
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-12 Thread Mark Lawrence


On 12/06/2010 03:34, Steven D'Aprano wrote:

On Sat, 12 Jun 2010 14:13:44 +1200, Gregory Ewing wrote:


Steven D'Aprano wrote:

This
reminds me of time-travellers suffering from time lag in the
wonderful novel To Say Nothing Of The Dog by Connie Willis.


One of the many excellent reasons why Guido keeps tight control over the
keys to his time machine. Time-lagged joyriding teenagers careening
around the space-time continuum can be quite a hazard.


Imagine the havoc if RantingRick accidentally goes back in time and
deactivates the Timbot.



Not a chance, if Dr Who can take on baddies like the daleks, yetis and 
cybermen Ranting Rick would be a piece of cake. :)  My 13 year old will 
be glued to BBC1 tonight at 18:45 BST to see his hero (Dr Who that is) 
in action.


Down with baddies.

Mark Lawrence.

--
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-12 Thread Martin v. Loewis


Yeah. I get the policy in general, a proliferation of ctypes stuff could
be very bad -- but if code is very careful with type-checking and stuff,
it should be possible to get an exception, I'd hope.


Only if you can live with the respective module not being available all
the time.

The issue is not that you may mistakes in the ctypes code, thus allowing
users to crash Python. The issue is that if users remove ctypes (which
they may want to do because it's not trustworthy), then your module will
stop working (unless you have a fallback for the case that ctypes is
unavailable).

In general, it's undesirable that absence of some module causes a 
different module to stop working in the standard library, except that

absence of Tkinter clearly causes IDLE and turtle to stop working.


Otherwise it makes certain windows-workarounds very problematic. You
basically /have/ to write a C extension :|


That's not problematic at all, for the standard library. Just write that 
C extension.


Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list

safer ctype? (was GUIs - A modest Proposal)

2010-06-12 Thread Martin P. Hellwig


On 06/12/10 08:21, Martin v. Loewis wrote:
cut

The issue is not that you may mistakes in the ctypes code, thus allowing
users to crash Python. The issue is that if users remove ctypes (which
they may want to do because it's not trustworthy), then your module will
stop working (unless you have a fallback for the case that ctypes is
unavailable).

cut
Got me thinking, is it perhaps doable to have a 'safe' ctype that is 
guaranteed to be in the stdlib? Perhaps crippling it in a sense that it 
only allows a known set of functions to be called?
My gut feeling is that you open a can of worms here but I would 
appreciate your opinion.


--
mph
--
http://mail.python.org/mailman/listinfo/python-list

Re: safer ctype? (was GUIs - A modest Proposal)

2010-06-12 Thread Martin v. Loewis


Got me thinking, is it perhaps doable to have a 'safe' ctype that is
guaranteed to be in the stdlib? Perhaps crippling it in a sense that it
only allows a known set of functions to be called?


In some sense, a C module wrapping a selected number of functions
(like the win32 extensions) is exactly that.

Notice that it's not (only) the functions itself, but also the 
parameters. It's absolutely easy to crash Python by calling a function 
through ctypes that expects a pointer, and you pass an integer. The
machine code will dereference the pointer (trusting that it actually is 
one), and crash.


Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list

Re: safer ctype? (was GUIs - A modest Proposal)

2010-06-12 Thread Bryan

Martin P. Hellwig wrote:
 Martin v. Loewis wrote:
 cut The issue is not that you may mistakes in the ctypes code, thus 
 allowing
  users to crash Python. The issue is that if users remove ctypes (which
  they may want to do because it's not trustworthy), then your module will
  stop working (unless you have a fallback for the case that ctypes is
  unavailable).

 cut
 Got me thinking, is it perhaps doable to have a 'safe' ctype that is
 guaranteed to be in the stdlib? Perhaps crippling it in a sense that it
 only allows a known set of functions to be called?
 My gut feeling is that you open a can of worms here but I would
 appreciate your opinion.

Perhaps instead of restricting what functions ctypes can use, we could
restrict what modules can use ctypes. For example, maybe only modules
in certain directories should be allowed to import ctypes.


--
--Bryan Olson

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: safer ctype? (was GUIs - A modest Proposal)

2010-06-12 Thread Martin v. Loewis


Perhaps instead of restricting what functions ctypes can use, we could
restrict what modules can use ctypes. For example, maybe only modules
in certain directories should be allowed to import ctypes.


And that's indeed the case. The test suite may use ctypes.

Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[ye gods, i think this is the largest thread i've ever seen, but i
still feel compelled to wind back to the beginning and spew forth
words.]

On Jun 6, 2:22 am, ant shi...@uklinux.net wrote:

 I get the strong feeling that nobody is really happy with the state of
 Python GUIs.

 yep.  that's why i ported pyjamas, which was a web-only/browser-only
UI toolkit, to the desktop.  it's a _real_ eye-opener to try to use
the failed ports of pyjamas to both pygtk2 and pyqt4, which you can
still get at http://github.com/lkcl/pyjamas-desktop - see pyjd-pyqt4
and pyjd-pygtk2

 these failed ports give you the clearest and bluntest indication of
the failings of pyqt4 and pygtk2.  after using those two top
mainstream python GUI widget sets, i didn't try any others.

 Whether or not we like graphics programming, it's not going to go
 away.

 no you're right, it's not.

 ... but as web browser technology development continues to
accelerate, the top mainstream GUI technology (not just python GUI
technology) is going to look more and more archaic in comparison.

 I ask the group; should we try to create a new GUI for Python, with
 the following
 properties?:

 - Pythonic
 - The default GUI (so it replaces Tkinter)
 - It has the support of the majority of the Python community
 - Simple and obvious to use for simple things
 - Comprehensive, for complicated things
 - Cross-platform
 - Looks good (to be defined)
 - As small as possible in its default form

 i invite anyone considering starting a new python GUI project to
consider these questions:

 * how much effort has been and is being spent, right now, on
developing and debugging each of the python GUI widget sets, as
compared to the efforts on web browser technology (MSHTML, KHTML ok
maybe not kHTML, WebKit, XulRunner)?  (put another way: how long have
web browsers existed and how much user-market-share do web browsers
have, compared to GUI and python GUI widget sets?)

 * are python GUI widget sets easy to compile cross-platform, as
compared to web browser technology which is _definitely_ cross-
platform?

 * how easy is it to extend the existing python GUI widget sets with
new or custom widgets, as compared to web browser technology where
you can manipulate bits of DOM?  if you're not sure of how simple/
complex each task is, read and compare these:

   http://www.learningpython.com/2006/07/25/writing-a-custom-widget-using-pygtk/
   http://pyjd.sourceforge.net/controls_tutorial.html

 * how easy is it, using the new or custom widget extension
methodology of existing python GUI widget sets, to extend that widget
set to keep up with modern GUI advancements and user expectations,
as compared to enhancing web browser technology?

   actually, this is a deliberately misleading question, but it at
least illustrates that it's damn hard for GUI widget set developers to
keep up.  in fact, many GUI widget set developers are actually
embedding web browser technology as a widget in order to avoid the
problem! (pywebkitgtk, pyqtwebkit etc.)

 * better question: how much time and money by large corporations with
their associated vested interests is being invested into python GUI
widget sets, as compared to how much by those same corporations into
the W3C DOM Standards process and the resultant improvements and
advances in web browser technology?

 * final question: how easy is it to create python wrappers around
DOM browser technology, thus leveraging and riding on the back of the
_vast_ amounts of effort and money being poured into web browser
technology?

 answer for MSHTML (aka Trident Layout Engine): using python-comtypes
- 3 weeks.

 answer for WebKit: using glib/gobject and pygobject codegen to
augment pywebkitgtk - 12 weeks

 answer for XulRunner: using python-hulahop and python-xpcom - 2
weeks.

 answer for Opera's engine: unknown, because the developer hasn't
responded yet. (it's qt-based, so it would be estimated around 12
weeks, if they haven't already done the work).

 so can you see where this is at?  and that's why pyjamas/pyjamas-
desktop exists.  a _completely_ non-corporate-funded, _tiny_ team is
riding on the back of the vast amounts of money and resources
available to google, apple, nokia, microsoft, mozilla foundation and
so on, and we're sitting back and offering it as free software to
people to create applications that are as powerful as the underlying
web technology on which the pyjamas UI toolkit is based.

and with the addition of WebGL (3D SVG) and HTML5 (Video etc.), web
technology is becoming pretty powerful.

so this is why it can be claimed that pyjamas competes with
silverlight and with adobe AIR/Flash, and it's not to do with pyjamas
per se: pyjamas is just a leveraging technology to get at the
underlying power of the web engines.  (the claim _does_ however grate
against a lot of egos, somewhat understandably, and with a non-
existent marketing dept there's not a lot that can be done about
that).

so let me go over these points again, now wrt pyjs/pyjd

Re: GUIs - A Modest Proposal

On Jun 6, 10:49 pm, Kevin Walzer k...@codebykevin.com wrote:
  - Pythonic
  - The default GUI (so it replaces Tkinter)
  - It has the support of the majority of the Python community
  - Simple and obvious to use for simple things
  - Comprehensive, for complicated things
  - Cross-platform
  - Looks good (to be defined)
  - As small as possible in its default form

 These goals are not all complementary. In fact, some of them, such as
 small and comprehensive, are mutually exclusive.

 that's not quite true - you can create a simple core which is easily
extensible with third party contributions to create more comprehensive
widgets.

 in the GWT arena, you have gwt-g3d, gwt-incubator, gwt-gchart and so
on, all of which were created very easily thanks to the power of the
underlying GWT core codebase, _none_ of which are actually included
into GWT by default, _all_ of which can be installed by users and
simply imported just like the core.

 now s/GWT/pyjamas and you have the exact same thing, and all the
satisfiable requirements are met.

 l.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 6, 10:55 pm, ant shi...@uklinux.net wrote:
 On Jun 6, 2:22 pm, ant shi...@uklinux.net wrote: I get the strong feeling 
 that nobody is really happy with the state of
  Python GUIs.

 snip...

 What an interesting set of responses I got!
 And - even more interesting - how few of them actually seem to think
 there is a problem, let
 alone make any attempt to move the situation forward.
 I appreciate that there are proponents of many different GUIs. I am
 asking that all step back
 from their particular interests and - for example - try to see the
 situation from the viewpoint of
 - say - a Python newbie, or an organisation that is thinking of
 switching from (example only!) Visual Basic.

 I obviously didn't make my main point clearly enough; I'll restate it
 with a different emphasis:
 The default GUI shipped with Python is Tkinter.
 Few people seem to like it much. This has several consequences.
 - It has not blossomed, like Python has.
 - There are not hundreds of talented programmers making rapid and
 impressive improvements to it.
 - Books about Python use it in examples (because it IS the default),
 but imply that one should move on.

 The result that our hypothetical new recruit has to make a choice for
 the new, big project. Remember that
 GUIs have hundreds (sometimes thousands) of classes, functions and
 constants. Let alone idioms and design
 patterns. That is what I meant by 'Our resources are being
 dissipated'; the effort of learning, remembering
 and relearning a workable subset of these is substantial.
 So it would be good to be able to use One Right Way, not try several
 (as I have - I will admit I didn't try PyQt;
 GUI fatigue was setting in by then).

 If we are to make progress, I can see two obvious approaches:
 1) Improve Tkinter to the point where it is supportable and supported
 by a good fraction of Python programmers
 or
 2) Drop Tkinter as the default and use something else.

 If we choose 2) then we have a new set of possibilities:
 2a) Use one of the 'major' GUIs, pretty much as is, but presumably
 with a lot more people supporting it if it is the default.
 2b) Use one of the 'minor' GUIs, and get a lot of people working on it
 to make it really good.
 2c) Start from scratch. With a project supported by the Community as a
 whole, with the agreed objective of being the default.

 None of these is easy. All require strong leadership and great
 committment.

 What surprises me is the apparent willingness of the Python community
 to let this issue slide.

 ah - i think... i believe you may be confusing realism with
fatalism.  experienced python developers are also experienced,
specialist c programmers (amongst other things) and experienced
software engineers.  they've been around a while (10+ years).  they
_know_ how much effort is involved in creating a major project such as
a GUI widget set (and you can get a wildly-wrong but nevertheless
useful answer from ohloh.net statistics, by going to http://ohloh.net/p/gtk
for example)

 so, spec'ing it out, we _know_ that to create a decent GUI widget
set, from scratch, in c (to make it fast enough) would be... ye
gods... 50 man-years of effort, minimum?  you _might_ be able to
reduce that by using somebody else's library (libcairo, libpango)
but... just... _why_??

 so this was why i went f*** that! and leveraged web browser
technology, jumping from virtually nothing (an abandoned python-to-
javascript compiler project) to a world-class GUI toolkit, in under 18
months of _part time_ effort.

 My concern is simple: I think that Python is doomed to remain a minor
 language unless we crack this problem.

 ah. take a look at that chart that keeps cropping up every now and
then: python is _not_ a minor programming language.  most likely due
to django, it's rated about 7th with about ... i think it was 6%
share.  perl is now _under_ 4%!

 so i don't believe there are any concerns there: python has enough
alternate uses other than as a GUI toolkit to keep it going :)

 l.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 7, 9:25 pm, Arndt Roger Schneider arndt.ro...@addcom.de
wrote:
 Terry Reedy schrieb:
 Forget postscript!
 Generate SVG from  a tk canvas or --better-- from tkpath.
 Jeszra (from me) generates SVG. There is also a SVG export

 ... orr, you use a modern web browser engine such as XulRunner 1.9
(the engine behind FF 3+), or webkit (the engine behind arora, midori,
safari, android, chrome, palm's webos, adobe AIR, iphone, ipad,
appcelerator, nokia S60 browser, the IE chrome plugin, blackberry 4
OS's web browser, and god knows what else).

 and you create python bindings to that modern web browser engine, and
you can then use DOM manipulation (like javascript, only in python) to
get at those SVG functions, and much much more.

 ... how does that sound?


 Will any big GUI-Framework work on those devises?

 No!

 yes.  called a web browser.  most likely a modern webkit-based
engine.

 Will SVG run on thoses devices?

 yes.  in the webkit-based web browser.  or the opera mini browser.
etc. etc.

 l.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-12 Thread Kevin Walzer


On 6/12/10 9:44 AM, lkcl wrote:

  that's not quite true - you can create a simple core which is easily
extensible with third party contributions to create more comprehensive
widgets.


That's exactly the design philosophy of Tk: a small core widget set 
(recently expanded somewhat with the ttk widgets) and an API that is 
easily extensible, either at the script level (megawidgets, cf. using an 
entry widget and a listbox to build a combobox) or at the C level (more 
complex, but hardly impossible).


I've used a browser-based app before (Adobe AIR app running in IE) and 
while it wasn't horrible, I certainly did not prefer it to a native 
desktop app: I got sick of waiting for the app to reload because of a 
slow network connection.


--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 9, 5:12 am, rantingrick rantingr...@gmail.com wrote:
 But you know i think it boils down to fear really. He is comfortable
 in his life and wishes to keep it as cookie cutter as he can. Any
 outside influence must be quashed before these meddling forces can
 take hold of him. He is so fearful of seeing the light in an opposing
 argument that blinding himself from reality is easier than facing
 reality.

 a very wise person told me a phrase which he'd heard, and i believe
it's relevant and hope you won't mind me quoting it:

 stress is where the mind compares the internal world with the
external, cannot cope with the discrepancy, and places blame on the
*external* world.

 there's food for thought in that, for all concerned.  nobody's
actions, here, are wrong, they just are.

 l.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 9, 8:45 am, Lie Ryan lie.1...@gmail.com wrote:
 On 06/09/10 08:20, Martin P. Hellwig wrote:

  I do think it is technically possible to have your own window manager in
  python on x11 but I have no idea if you have equal possibilities on mac

 Doesn't Mac uses an X server as well?

not by default, no.  you have to install it (from the XCode bundle/
package).

l.

p.s. i skipped replying to the other message but yes there is actually
an implementation of x11 directly in pure python.  you can use it to
write window managers in it.  but it's _not_ an x11 server
implementation, it's just equivalent to... ooo... probably libx11:
i.e. it connects to e.g. KDE, GDM, Fvwm and sends and responds to
events.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 9, 11:16 am, ant shi...@uklinux.net wrote:

 And who are the beginning programmers going to turn into? If we do our
 stuff right, Python programmers. If not,
 Java or PHP or Visual Basic programmers. Or website designers. Or
 worse (is there a worse?).

 yes - Java programmers who use COM under Win32 to connect to a OCX
browser plugin written in Visual Basic, in a website written in PHP.

 no - wait: Java programmers who use COM under Win32 to connect to a
Silverlight .NET application written in Visual Basic, in a website
written in PHP.

 yeeehawww.  got all the god-awful trite crap which has driven people
nuts for years, and into the welcoming and consoling arms of the
python community, alll into one gory sentence.

 :)

 l.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

2010-06-12 Thread Stephen Hansen

On 6/12/10 12:21 AM, Martin v. Loewis wrote:
 Otherwise it makes certain windows-workarounds very problematic. You
 basically /have/ to write a C extension :|
 
 That's not problematic at all, for the standard library. Just write that
 C extension.

Come now, of course it is. It may not be problematic for *you*, but it
*is* problematic for a lot of people.

The pool of people competent to write solid, Pythonic, capable Python
code and contribute it-- then add a few lines of ctypes for a
windows-specific workaround-- is surely larger then the pool of people
competent to write a safe C extension.

I know I only *barely* fit into the latter category.

Maybe Cython'll be mature enough eventually that the stdlib could accept
Cython-based C extensions for such cases.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

On Jun 9, 5:16 pm, Ethan Furman et...@stoneleaf.us wrote:
Gregory Ewing wrote:
Kevin Walzer wrote:
PyGUI ... certainly is *not* a lightweight GUI toolkit that could
easily be incorporated into the Python core library--it instead has
rather complex dependencies on both other GUI toolkits and Python
wrappers of those toolkits.

I don't see how the dependencies could be regarded as complex.
There's more or less only one on each platform, and they're
pretty standard accessories for the platform concerned. You could
say there are two on Linux if you count gtk itself, but you almost
certainly already have it these days if you're running any
kind of desktop at all.

*Alert* Potentially dumb question following: On the MS Windows
platform, Gtk is not required, just win32?

by using python-comtypes and python-ctypes, you can pretty much
control absolutely anything that's installed, and access just about
anything: any win32 dll, any function. some of the function
parameters you might have to guess, but it's doable.

in this way you can actually access the win32 GDI (graphics driver
interface) which is a serrriously low-level GUI toolkit built-in to
the win32 API, and can implement much higher-level APIs on top of it.
GDI is somewhat at the level of the X11 protocol.

as it's so low-level, the number of applications which actually do
this is _extremely_ small. the only reason i got involved at all was
to do the bsolute minimum amount of work required to embed _one_
single object instance into a GDI window, taking up the entire width
and height: an IWebBrowser2 OCX control, lifted straight out of
MSHTML.DLL.

you can look at what i did, here:
http://pyjamas.git.sourceforge.net/git/gitweb.cgi?p=pyjamas/pyjamas;a=tree;f=pyjd;hb=master

see windows.py and pyjd.py. windows.py is lifted straight out of a
library by henk punkt; pyjd.py is a mish-mash amalgam of various bits
of code i found by googling for 3 weeks solid on variations of python
MSHTML IWebBrowser2 and so on. much of the work that i found i had
to go back _years_, to older versions of python and older python
libraries that have long since been retired because nobody bothered
with the techniques that were offered.

so, yah. thanks to henk punkt's little windows.py module, it's
possible to appear to have direct access to win32 functions such as
CreateWindowEx, and thanks to python-comtypes it's possible to get
access to the COM interface of DLLs and then you're off (in this case,
with the fairies).

l.
--
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

On Jun 9, 5:38 pm, rantingrick rantingr...@gmail.com wrote:

 Yes we need a leader. Someone who is not afraid of the naysayers.
 Someone with Guido's vision. When the leader emerges, the people will
 rally.

 ... Mahh?  Whey'rus ma guuhhn? haww haww

 :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

 That's the reason why it won't happen. Everybody asking for change is
 not willing to lead the effort. Everybody who would be able and might be
 willing to lead the change fails to see the need for change.

 *lol*.  i don't know why, but i think that's so hilarious i might
make it my .sig.  it must be because it's so beautifully zen and
circular.

 there are foools who aren't confident and know it;
 there are foools who _are_ confident, and experienced enough to not
try it.

 that just leaves the foools who are confident enough to try it, but
whom nobody will follow :)

 it's a bloody wonder anything gets achieved at all in free software
ha ha :)


 l.
-- 
http://mail.python.org/mailman/listinfo/python-list

Python ctypes / pywin32 [was: GUIs - A Modest Proposal]

On Jun 10, 6:26 pm, Martin v. Loewis mar...@v.loewis.de wrote:

  or PyGui would need to be implemented in terms of ctypes (which then
  would prevent its inclusion, because there is a policy that ctypes
  must not be used in the standard library).

  Is there? I wasn't aware of that. What's the reason?

 ctypes is inherently unsafe.

 that's ok.  only the sanest and most careful of programmers are going
to use it.  and all they're going to do is crash their application if
they get it wrong.  or, on an OS which is _known_ to be so unstable
that it will fall over with the slightest provocation, crash the OS
and require a press of that little button which was moved to the front
_just_ to deal with that OS's instability, once again.

 just because a library has a means for programmers to shoot
themselves in the foot doesn't mean that the programming language
should come with kevlar-reinforced bullet-proof vests.


 It must be possible to remove it
 from a Python installation,

 as long as that's not an official policy statement that ctypes will,
at some point in the future, be removed from python, i'm happy.

 the last thing i want to have to do is to have to include and
maintain, as part of the pyjamas download, a complex python-ctypes
library in order to get at the win32 functions CreateWindowEx; the
second last thing i want to have to do is rewrite pyjd's MSHTML port;
the third last thing i want to have to do is state that a 2nd and
_much_ larger library dependency/download is required: pywin32.

 one of the really nice things about having chosen ctypes and a copy
of henk punkt's windows.py file is that the only dependency required
is one single 350k download: python-ctypes.  last time i looked,
pywin32 was a whopping 6mb, and there's _nothing_ in pywin32 that pyjd
actually needs.

 i deliberately bypassed python-win32com for exactly the same reason:
it turns out that direct ctypes access to Variant and all other OLE /
COM types is perfectly sufficient.

 removal of ctypes would be a big, big mistake.  i trust that i have
misinterpreted the implication of what you're saying, martin.

 l.
-- 
http://mail.python.org/mailman/listinfo/python-list

WebBrowserProgramming [was: GUIs - A Modest Proposal]

On Jun 10, 6:56 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:

 For example: if you want to embed a CSS-capable web-browser into your
 app? PyQT is actually your best option-- albeit a commercial one if
 you're not open source.. wx/Python haven't yet finished WebKit
 integration(*).

 there are _lots_ other options that i know of.  here are three of the
best:

 * python-comtypes and wrap an IWebBrowser2 instance (out of MSHTML) -
you can get a win32 GDI handle id out of this: if you know what
you're doing, you could likely embed that into a gtk or qt app, just
in the same way as you can embed X11 windows into pygtk apps, by
knowing the X11 window handle id.

 * python-xpcom and python-hulahop on top of xulrunner.  hulahop is
the python magic glue between GTK and the XPCOM access interface
to the xulrunner web engine.  hulahop allows the xulrunner engine to
be embedded as a python gtk widget, whilst also giving you a handle
to the xpcom interface.

 * pywebkitgtk - in its current released/stable form, it gives you
juuust enough to embed a web browser, but you can't actually get
access to any of the DOM functions (unlike hulahop/xpcom and comtypes/
MSHTML).

 i'm recording all of these, and any other web browser manipulation
technology that i've ever encountered, here:

 http://wiki.python.org/moin/WebBrowserProgramming

 l.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: safer ctype? (was GUIs - A modest Proposal)