GUIs - A Modest Proposal

[lkcl]

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.

 

[Stephen Hansen]

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/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJMFOxiAAoJEKcbwptVWx/lC+sH/2o4M5G0Hm2DkOP/c19LfjgR
waJnkNuP0/Bcv3EPu2GZTMzm/Xte8eFfDMBYr2Pz1OurPzzZHBvpucylO3helPxX
MT2LSA7g/PTmzPrHAM7akuz8raJ5QyCK8YfydLabD1SGyfKXSlE6j17E9+uu+oYZ
/CH2usK75j7LZOPwsPaJ4ie/cyZzYCkcGmSkdtRlP5EoQ03VouQp9NwMqSpvwH8g
11+3dCVGUfu/kwqxq4V4ybsHKgctyJ1M8brmdCp1qPt1X++Mf/5UiW73GKTNsZOp
qGOvUnlnF6Ke41giBFtLSH7BTT6AlVcs9VPOMd08NTlm/SolnlqARfRteJAA9U4=
=alqm
-----END PGP SIGNATURE-----

 

[Michael Torrie]

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.

 

[Arndt Roger Schneider]

[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 there definitely are.




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

 

[Terry Reedy]

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

 

[Aahz]

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?

 

[lkcl]

[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.

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.

 

[Terry Reedy]

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

 

[Mark Lawrence]

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.

 

[lkcl]

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

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

thanks aahz.

 

[lkcl]

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.

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.

ok - it resized, yes? so...

* what happens if you shrink the window to 50 px by 50px and it
_only_ contains RichText widgets, placed in any QLayout derivative
(horiz, vert, grid, doesn't matter) which has had "100% width" and
"100% height" placed on it?

* does the text "force" the QLayout-derivative to expand outwards to
allow all text to be displayed? or does the QLayout-derivative
"override" the displaying of text and thus only display the top left
portion of the text, cutting it off until, eventually, when that 100%
width and 100% height get close to zero, the entire text disappears.

* is there any way to get the behaviour where an effectively free-
form RichText widget's text determines the sizes of its containers,
_without_ having to set either the width or the height to specific
pixel values?

* is there a way to set RichText "percentage width" but still also
say "when that percentage goes below the minimum threshold required to
actually display all text, please ignore the percentage width" ?

additionally:

* how do you tell the RichText to not have a margin? i could not
find a way to specify the text to be hard against the edges of the
RichText container.

* can you insert widgets into the text? say, if i have two words
"menu here" can i place a QMenuBar widget in between those two words
*inside* the actual RichText widget?

from this latter, you can see: there are distinct advantages to using
something like DOM as the basis for a widget set. if the "Rich Text"
comprises the following: "menu <div id='menuplease'> here" then you
can use a widget (HTMLPanel) which has an "add by id" method, where it
will search through all child DOM using elem.getElementById, and then
add the widget as a child to the "Rich Text".

in fact, there's a demo of exactly this, here - page-down to
HTMLPanel: http://pyjs.org/examples/kitchensink/output/KitchenSink.html#Layouts

abstracting out the layouts and the widgets in this way, such that
they're constructed in terms of an underlying "display engine" can
therefore be seen to have real powerful advantages over "hard-coded"
layout classes which are solely and exclusively responsible for their
child widgets, with (as far as i am aware) virtually no interaction
"allowed" between their child widgets and *their* parent. please
correct me if i am wrong on this rather crucial last point, as it was
the whole reason why i stopped the pyjd-qt4 and pyjd-gtk2 ports: if it
_can_ be done i'll happily continue with them.

many thanks,

l.

 

[lkcl]

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 twwoooooo weeeeeeks 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 "yessss" -
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 existing python widget sets who believe that
anything that's based on web technology couldn't _possibly_ be up to
the job.

oh look - there's a common theme, there: "web technology equals
useless"

l.

 

[lkcl]

 oh look - there's a common theme, there: "web technology equals

useless"

this is getting sufficiently ridiculous, i thought it best to
summarise the discussions of the past few days, from the perspective
of four-year-olds:

http://pyjs.org/will_and_abe_guide_to_pyjamas.html

l.

 

[lkcl]

this is getting sufficiently ridiculous, i thought it best to
summarise the discussions of the past few days, from the perspective
of four-year-olds:

not, of course, to imply in _any way_, that anyone but myself on
comp.lang.python is juvenile and/or delinquent, and not of course, to
imply that any four-year-old is in any way juvenile and/or
delinquent. bring on the political correctness...

l.

 

[Stephen Hansen]

*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.

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.

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 twwoooooo weeeeeeks 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 "yessss" -
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 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).

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

[snip implementation]

It looks very interesting: don't get me wrong, pyjamas (and Desktop in
particular) look to be in some contexts a compelling sort of tool. I'm
not entirely sure I comprehend how it works underneath so don't yet know
if it'd ever be something I'd be able to use (I don't understand where
this py->js transition is happening and what the implications are).

But its interesting to be sure. Something to look more into.

--

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJMFlYtAAoJEKcbwptVWx/larIIAIOPy0DwsP3/xqTqEPKLpGD9
dV1g2CzmZ9EChxmkS92C4aZju8cy9jvuIKZbW5hIlaJD8IDBSbhjw92ayizxGTJM
4dEOvJRz3G/9VZmuPs4BLFp9kepiqxV4+zsEz18X94wgI9qUltyvqbQkIktPdxAE
l2f9aCsLBCNT/Pgrjbnrc9QbYJlFjBgfQ6czRmcPLPC2lB5xraM1bGLhshh2ZUn3
1tkxklJD+i9FaOQwOWPUYnvofY58EjZudGAS0DHOVMezgcoUG6oZeU/jO1SOysKy
UlRcZ0Bnmx8Xii5qPTKHb/rEa9TEzrC672sieDDo4pm5Qm1/J4YRRTrfJE+MLW4=
=b1Wb
-----END PGP SIGNATURE-----

 

[rantingrick]

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.

 

[Ricardo Aráoz]

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 !!!!

 

[lkcl]

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.

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 the twisting and recursive mode of DOM or have taught
yourself to. Its a mental model that not all will ever grasp.

mwahahahh osmosis. wonderful stuff. makes it damn hard to
explain the subject to other people, though...

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"

aww come onn, that example does more than.. ok, you've got a point

I'm not entirely sure you fully understood qt or gtk's layout
mechanisms.

i'll happily admit that i don't - and that i found them to be
exasperating. but then, at least two people have pointed out very
valuable directions in which i might actually be able to achieve what
i'm aiming for.

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.

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

[snip implementation]

It looks very interesting: don't get me wrong, pyjamas (and Desktop in
particular) look to be in some contexts a compelling sort of tool. I'm
not entirely sure I comprehend how it works underneath so don't yet know
if it'd ever be something I'd be able to use (I don't understand where
this py->js transition is happening

command-line tool. takes python as input, does "imports"; anything
it can "import" it also translates and adds to the output; total is
spewed forth as a pure javascript app.

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

and what the implications are).

no more JS Hell, and no more complicated DOM interaction, either:
just widgets and GUI-like event handling rules and method-name
callback conventions like "onClick" and "onMouseMove".

just like in aaanny good Desktop GUI Widget set.

thanks stephen.

l.

 

[lkcl]

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.

ohhhh, 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.

 

[lkcl]

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.