GUIs - A Modest Proposal
in [Python]
|
From: Stephen Hansen on 14 Jun 2010 12:17 On 6/14/10 7:15 AM, lkcl wrote: > On Jun 13, 2:34 pm, Stephen Hansen <me+list/pyt...(a)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/
From: Ricardo Aráoz on 14 Jun 2010 14:37 On 14/06/2010 02:57 p.m., rantingrick wrote: > On Jun 14, 11:17 am, Stephen Hansen<me+list/pyt...(a)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 !!!!
From: lkcl on 14 Jun 2010 14:47 On Jun 14, 4:17 pm, Stephen Hansen <me+list/pyt...(a)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.
From: lkcl on 14 Jun 2010 14:53 On Jun 14, 5:57 pm, rantingrick <rantingr...(a)gmail.com> wrote: > On Jun 14, 11:17 am, Stephen Hansen <me+list/pyt...(a)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: Im curious, have you ever googled anybody? Do you use Google? > BUSH: Occasionally. One of the things Ive used on the Google is to > pull up maps. Its very interesting to see Ive 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.
From: lkcl on 14 Jun 2010 15:16
On Jun 14, 5:57 pm, rantingrick <rantingr...(a)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. |