On 6/14/10 11:47 AM, lkcl wrote: > On Jun 14, 4:17 pm, Stephen Hansen <me+list/pyt...@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/
signature.asc
Description: OpenPGP digital signature
-- http://mail.python.org/mailman/listinfo/python-list
