GUIs - A Modest Proposal

[lkcl]

On Jun 14, 4:17 pm, Stephen Hansen <me+list/pyt... at 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 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 :)


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

 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.