GUIs - A Modest Proposal
in [Python]
|
From: Stephen Hansen on 14 Jun 2010 15:30 On 6/14/10 11:47 AM, lkcl wrote: > On Jun 14, 4:17 pm, Stephen Hansen <me+list/pyt...(a)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/
From: lkcl on 14 Jun 2010 17:05 On Jun 14, 7:30 pm, Stephen Hansen <me+list/pyt...(a)ixokai.io> wrote: > On 6/14/10 11:47 AM, lkcl wrote: > > > On Jun 14, 4:17 pm, Stephen Hansen <me+list/pyt...(a)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. :) _that's_ a long story - a brief insight into 8 months of hell i posted in another message on this thread... > > 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. :) oh i haven't mentioned the javascript-to-python converter yet, have i? *lol*. am still looking for a good BNF / parser in python, for that one. > Well, yes. I have some experience with extjs (and making some pretty > fantastic real-world seeming apps on the web with it), and yeah, > 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. ooh. ouch. we've had people wanting to wrap extjs in pyjamas. i told them NO don't for god's sake do it. it's _hundreds_ of thousands of lines of javascript; looking at the GWT-EXTJS wrapper, the "startup" code in javascript is a whopping 8,000 lines (which was more than the entire pyjamas codebase at the time!) and the rest of the "wrapper" code i believe is some 80,000 lines of java. then there's the issue that, apart from all that code to maintain, you now have a whopping great 2.5mbyte javascript dependency, where you'd need, if there was a bug in that, an expert javascript programmer... so whilst pyjamas UI widgets are somewhat at the level of "extjs 0.000001", at least there is http://puremvc.org (which yes, that _does_ compile to javascript cleanly!) which you can combine with e.g. the Grid Widget and a few more prettifying widgets, in order to create the kinds of looveliness that is extjs. > Maybe on its next iteration I'll look > into pyjamas. mmm, that leaves you with an all-or-nothing approach. there's a trick you could do, which involves using a pyjamas ui Frame widget, where you could convert the site one bit at a time. that's been done before now. if you're already using an AJAX approach in the back-end server (which it sounds like you are) then you'll be much much further ahead than many pyjamas converts: all you'd need to do is reimplement page- by-page the front-end widgets. ok gotta go, baby's dragging me away. l
From: rantingrick on 14 Jun 2010 18:44 On Jun 14, 2:30 pm, Stephen Hansen <me+list/pyt...(a)ixokai.io> wrote: Stephan speaking of Wx geometry managers... > 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) Oh Stephan i strongly disagree with that assessment. Tkinter blows Wx away with it's simultaneousness powerful AND elegantly simplistic geometry managers, grid, pack, and place. If you have not used them to any extent i strongly encourage you do so before boasting on the superiority of Wx geometry management. It's like night and day really. Wx is very ugly in this respect, again due to fact it has a C base developer pool.
From: rantingrick on 14 Jun 2010 18:53 On Jun 14, 2:16 pm, lkcl <luke.leigh...(a)gmail.com> wrote: > 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. Hmm, we have a Python API already worked out. I wonder how much trouble it would be to get pyjamas into this API. The SketchUp folks are just busting at the seems for a more developer friendly web dialog environment and SketchUp WebDialogs just ain't cutting the mustard (more like the cheese!). Let me know if you may interested in spearheading this endeavor as i can offer my motivational skills to push the product and help you work out a friendly API!
From: Stephen Hansen on 14 Jun 2010 19:27
On 6/14/10 3:44 PM, rantingrick wrote: > On Jun 14, 2:30 pm, Stephen Hansen <me+list/pyt...(a)ixokai.io> wrote: > > Stephan speaking of Wx geometry managers... > >> 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) > > Oh Stephan i strongly disagree with that assessment. Tkinter blows Wx > away with it's simultaneousness powerful AND elegantly simplistic > geometry managers, grid, pack, and place. If you have not used them to > any extent i strongly encourage you do so before boasting on the > superiority of Wx geometry management. It's like night and day really. > Wx is very ugly in this respect, again due to fact it has a C base > developer pool. I am familiar with grid, pack and place. Are you arguing from an API point of view, or a functionality point of view? I have no interest in debating the Pythonisity of Tkinter's API to wxPython's -- its pointless, neither are particularly Pythonic, and I've never argued wx does not have an API difficulty and learning curve. From a functionality perspective, "pack" and "grid" are both distinctly less capable then wx sizers. In the simpliest of interfaces, they achieve similar goals in similar ways: but the lack of proportional sizing kills it for me, unless I've been long mistaken in pack not having a proportional option. A combination of "fill/expand" and "anchor" do most of everything else, though, that wx's flags and alignment options. I've no interest in talking about "place"; absolute positioning is simply pointless to me. Now, from an API perspcetive? I'll not debate the merits of which is better, except that your conclusion of 'why' its 'ugly' and difficult that its a C based tool, is wrong. The API difficulty comes from the fact that "sizers" are separate from containers, and that individual items added to them don't actually have any internal knowledge of their sizer environment. This creates some cumbersome interactions. However, this can be largely made easier (And vastly more Pythonic) by simply basing wx.lib.sized_controls as the base. Then, instead of explicit sizer tweaking, you do things like: import wx.lib.sized_controls as sc class MyPanel(sc.SizedPanel): def __init__(self): sc.SizedPanel(self, -1) self.SetSizerType("horizontal") b1 = wx.Button(self, -1, "OK") b2 = wx.Button(self, -1, "Cancel") b1.SetSizerProps(expand=True) b2.SetSizerProps(expand=True) You can rewrite something very similar in Tkinter, sure. And you'll have shorter names, and maybe you can argue 'pack' is more pythonic then 'SetSizerProps', but debating API pythonicity is just uneventful. My original comments were about function, not form. I mean, we're discussing the DOM here. There's never been a more hideous designed API in the history of API's. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ |