GUIs - A Modest Proposal

[Stephen Hansen]

On 6/14/10 11:47 AM, lkcl wrote:
> On Jun 14, 4:17 pm, Stephen Hansen <me+list/pyt... at 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 decisions, they are taking
into account various constraints. You can set minimum sizes, maximum
sizes, 'best' sizes, and these'll be taken into account when laying out
and 'flowing' the user interface.

The key comes in that you can nest sizers. So, you add two objects to a
Horizontal Box Sizer, and the second is a Vertical Box Sizer. If both
are set to share all available space, the right one will get half the
screen. But it then can have all kinds of objects added to it, and
they'll be lined up in a vertical line on 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)

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

Well, I got that much; I more meant the Pyjamas-Desktop thing. It makes
regular "seeming" application/client-based user interfaces, right? Are
those all entirely, once run, 100% JavaScript (post-compilation)?

If so, Desktop at least isn't useful to me. :( I can't access omniORB
with it :)

But for a web app, it might be.

-- 

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20100614/80ab1022/attachment.sig>