GUIs - A Modest Proposal
in [Python]
|
From: Michael Torrie on 13 Jun 2010 11:43 On 06/13/2010 05:29 AM, lkcl wrote: > really? drat. i could have done with knowing that at the time. > hmmm, perhaps i will return to the pyqt4 port after all. We're now wandering well off-topic here, but then again this thread was never really on any particular topic. I have to say I'm really confused as to your issues with GTK and Qt. I've seen and done all kinds of fancy widget layouts in Qt and have *never* had to subclass layout. If you think you need to subclass QLayout, most of the time you're doing it wrong. You are familiar with how the vertical and horizontal layouts and spacers work in Qt, aren't you? Sometimes you need a grid for a table or the specialized form grid. But other than that you want a dynamically-sizing layouts most of the time. And Qt's Vertical and Horizontal layouts do that. I'm also confused by your claim that GTK lacks the layout widgets you need as well. GTK has the GtkHBox layout class which acts much like your <span> tag. Anything to pack in the hbox is automatically layed out in a dynamicially-resizing way. Any GTK dialog or window is a combination of different layouts, nested to get the desired layout. Works extremely well. > excellent! that actually makes it worthwhile carrying on. the only > other thing that needs solving is that RichText is forced to have its > width and height set. but it mayyy be possible to create an > appropriate QLayout derivative: i'll have to see. Again I'm confused here. I just created a little Window in Qt Designer and was able to get my RichText (There isn't a "Rich Text" widget in Qt; Just TextEdit with Rich text enabled) widget to resize automatically just fine as I resized the window. I'm obviously missing something.
From: Arndt Roger Schneider on 13 Jun 2010 11:52 lkcl schrieb: > [snip] > > it's the exact same thing for SVG image file-format. i'm >_definitely_ not convinced that "SVG the image fileformat" is The One >True Way to design images - but i'm equally definitely convinced of >the power of SVG manipulation libraries which allow for the creation >SVG images using declarative programming. > > > You rather severly underestimate the impact from SVG! 1. SVG is a complete visualization system and not an fancy way to create icons. SVG and SMIL are an extreme powerful environment. With it's possible to create(design) sophisticated graphical and interactive --resolution independent-- applictions without resorting to javascript or direct DOM manipulations. Javascript or other languages are still necessary to feed data into an SVG visualization, but not for much more. Further more SVG and the GPU are a natural combination. 2. Many of CSS shiny new features --such as animation originate from SVG. 3. SVG-Print: Printing is one of the biggest problems in the current IT-landscape. I do not want to install printer drivers on each telephon I own, neither on any other device --mobile or not. The printer must contain a computer running an OS and has to handle an agreed upon page description language (Xml based)... Using HTML/CSS/DOM/javascript for application building: Well, yes can be done. HTML is however text oriented; each application entirely based on this technology will be satured with text. HTML works reasonable well with applications of the past two decades, but the importance of text is dwindling and other graphical means of communication become more and more relevant. > but, all that having been said, and returning to "HTML and CSS (the >fileformats)", there's a lot to be said for convincing people who are >stuck in those worlds of the benefits and freedom of declarative >programming... _without_ having to get involved directly in >javascript. > > > Any User Interface should be pre-determined; this concept allows the consequent separation of application logic and presentation. It's not only important for Web-applications! >>that web apps are about to take over >>the world, etc. There is still a place for GUI toolkits >> >>that >>are not based on the DOM, >> >> > > that there definitely are. > > > >>or whatever the W3C technology of the month is. >> >> > > :) don't underestimate how much time and money is going into the W3C >standards! and remember, someone's got to implement them, so the >actual proof of the pudding is not what the W3C thinks but whether the >technology ends up actually in the hands of users and is successful >_for users_. > > l. > > > The mony part is definitly important. Tk is actually a good example for the working of money-politics (the absence thereof). -roger
From: lkcl on 13 Jun 2010 13:08 On Jun 13, 3:52 pm, Arndt Roger Schneider <arndt.ro...(a)addcom.de> wrote: > lkcl schrieb: > > > [snip] > > > it's the exact same thing for SVG image file-format. i'm > >_definitely_ not convinced that "SVG the image fileformat" is The One > >True Way to design images - but i'm equally definitely convinced of > >the power of SVG manipulation libraries which allow for the creation > >SVG images using declarative programming. > > You rather severly underestimate the impact from SVG! no - i kept things brief, so as not to dominate the postings here: you've very kindly filled in the blanks, and given far more information than even i was aware of, which is great. > 1. SVG is a complete visualization system and not an fancy way to create > icons. ... all of which is accessible via DOM manipulation, via the W3C-DOM- specified functions through the <canvas /> element. use of which has resulted in the creation of a very powerful _python_ library which re- presents those SVG Canvas functions. fillRect. saveContext. translate. demo of end-result usage can be seen here: http://pyjs.org/examples/gwtcanvas/output/GWTCanvasDemo.html http://pyjs.org/examples/asteroids/output/Space.html > Using HTML/CSS/DOM/javascript for application building: > Well, yes can be done. yes, it could. personally i wouldn't recommend the javascript bit. it's too dreadful. :) > HTML is however text oriented; each > application entirely based on this technology will be saturated > with text. ah - no, it won't. isn't. pyjamas apps are the proof that that isn't the case. pyjamas applications contain, at the absolute basics, _one_ HTML file comprising... about eight lines, the most important two bits being a "meta" tag naming the pre-compiled application, and a "script" tag with bootstrap.js which knows about the aforementioned "meta" tag. that's _it_. the rest can be done _entirely_ using declarative-style programming. but... if you _want_ to, that "loader" file can be a full-blown PHP app: just as long as that meta tag is there, and the bootstrap.js is there, the pyjamas app can be initiated "on top of" the PHP page. just like any other javascript can be run and can begin to manipulate the DOM. so it's just a matter of degree. you can either specify almost everything in "text" HTML/CSS or you can do entire DOM- manipulation or anything in between, to suit _your_ personal preference. i must not be explaining this very well, for which i apologise. > >>or whatever the W3C technology of the month is. > > > :) don't underestimate how much time and money is going into the W3C > >standards! and remember, someone's got to implement them, so the > >actual proof of the pudding is not what the W3C thinks but whether the > >technology ends up actually in the hands of users and is successful > >_for users_. > > > l. > > The mony part is definitly important. Tk is actually a good example for > the working of money-politics (the absence thereof). :) yehhs... and then people complain when it doesn't "look good". interesting neh? hence a reason why i'm advocating to "leverage" the incredible power of the technologies which _have_ had vast amounts of money/effort poured into them, with very little effort spent on the "leveraging" bit. l.
From: Terry Reedy on 13 Jun 2010 13:22 On 6/13/2010 7:20 AM, lkcl wrote: >> I'm far from convinced that HTML and CSS are the One True Way >> to design GUIs these days, > > if you have "HTML the fileformat" and "CSS the fileformat" in mind > when saying that, i can tell you right now that they're not. > fortunately, with the W3C DOM functions exposing properties and style > attributes, it's possible to manipulate the exact same attributes that > CSS and HTML "files" provide access to, using a declarative > programming style. With all the glamour hoopla over html/css/xml, it took me a while to realize that the really important thing is the underlying object model that the serialization formats communicate. I know this is a bit like saying "words are important because of the thougths they express" (which is not to say that beauty of expression is unimportant), but my point is that in explaining pyjames, you are sometimes running up against a fascination with the surface layers. Pyjamas requires a different orientation. Terry Jan Reedy
From: Mark Lawrence on 13 Jun 2010 14:20
On 12/06/2010 14:44, lkcl wrote: > On Jun 6, 10:49 pm, Kevin Walzer<k...(a)codebykevin.com> wrote: >>> - Pythonic >>> - The default GUI (so it replaces Tkinter) >>> - It has the support of the majority of the Python community >>> - Simple and obvious to use for simple things >>> - Comprehensive, for complicated things >>> - Cross-platform >>> - Looks good (to be defined) >>> - As small as possible in its default form >> >> These goals are not all complementary. In fact, some of them, such as >> "small" and "comprehensive," are mutually exclusive. > > that's not quite true - you can create a simple core which is easily > extensible with third party contributions to create more comprehensive > widgets. > > in the GWT arena, you have gwt-g3d, gwt-incubator, gwt-gchart and so > on, all of which were created very easily thanks to the power of the > underlying GWT core codebase, _none_ of which are actually included > into GWT by default, _all_ of which can be installed by users and > simply "imported" just like the core. > > now s/GWT/pyjamas and you have the exact same thing, and all the > satisfiable requirements are met. > > l. I'd just like to say thanks for opening up this thread. I've never yet written any GUI in Python, but should I need to do so this your comments and the responses will certainly stick in my mind. Kindest regards. Mark Lawrence. |