GUIs - A Modest Proposal

[Stephen Hansen]

On 6/14/10 7:15 AM, lkcl wrote:
> On Jun 13, 2:34 pm, Stephen Hansen <me+list/pyt... at 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 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/

-------------- 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/de98756a/attachment-0001.sig>