Re: UI toolkits for Python
Kenneth McDonald [EMAIL PROTECTED] wrote: I'd have to agree with this. Unfortunately, the only way to use Swing (in a reasonable manner) from Python is to use Jython, and Jython has other shortcomings that make me not want to use it. What shortcomings? -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Mike Meyer [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Alex Martelli) writes: Mike Meyer [EMAIL PROTECTED] wrote: What surprises me is that marketing types will accept turning away - what's the current internet user base? 200 million? - 10 million potential customers without a complaint. Or maybe they just don't get told that that's what's going on. In firms where marketing has lots of power, they may indeed well decide to pursue those 10 millions by demanding an expenditure of effort that's totally out of proportion What makes you think that the expenditure of effort is totally out of proportion? In my experience, that isn't the case - at least if you go into it planning on doing things that way. Retrofitting a site that was built without any thought but make it work in my favoriter browser in my favorite configuration can be a radically different thing. Why, of course -- coding a site to just one browser would be foolish (though there exist sites that follow that strategy, it's still despicable). What I'm talking about is sites that are _supposed_ to be able to support a dozen browsers, in three or four versions each, not to mention a dozen features each of which the user might have chosen to disable (for a total of 2**12 == 4096 possibilities). Of course, the site's poor authors cannot possibly have tested the 4096 * 12 * 3.5 possibilities, whence the _supposed_ to be. We ARE talking about moving from supporting 95% to supporting (*supposedly*!) 100%, after all -- very much into the long, *LONG* tail of obscure buggy versions of this browser or that, which SOME users within those last centiles may have forgotten to patch/upgrade, etc. And THAT is what makes the effort totally out of proportion (differently from the effort to go from 60% to 95%, which, while far from negligible, is well within sensible engineering parameters). Maybe that's part of the explanation for the outstanding success of some enterprises founded by engineers, led by engineers, and staffed overwhelmingly with engineers, competing with other firms where marketing wield power...? You mean like google? Until recently, they're an outstanding example of doing things right, and providing functionality that degrades gracefully as the clients capabilities go down. I'm not sure what you mean by until recently in this context. AFAIK, we've NEVER wasted our efforts by pouring them into the quixotic task of supporting *100%* of possible browsers that may hit us, with the near infinite number of combinations of browsers, versions and disabled feature that this would require. One may quibble whether the target percentage should be, say, 93%, 95%, or 97%, and what level of degradation can still be considered graceful around various axes, but the 100% goal which you so clearly imply above would, in my personal opinion, be simply foolish now, just as it would have been 3 years ago. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
[EMAIL PROTECTED] (Alex Martelli) writes: You mean like google? Until recently, they're an outstanding example of doing things right, and providing functionality that degrades gracefully as the clients capabilities go down. I'm not sure what you mean by until recently in this context. AFAIK, we've NEVER wasted our efforts by pouring them into the quixotic task of supporting *100%* of possible browsers that may hit us, with the near infinite number of combinations of browsers, versions and disabled feature that this would require. The non-graphics-oriented Google services like search, news, and groups, have worked perfectly well with lynx until recently. No javascript required, no image display required, and no cookies required. -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Alex Martelli wrote: Mike Meyer [EMAIL PROTECTED] wrote: [... browser audience discussion ...] What makes you think that the expenditure of effort is totally out of proportion? In my experience, that isn't the case - at least if you go into it planning on doing things that way. Retrofitting a site that was built without any thought but make it work in my favoriter browser in my favorite configuration can be a radically different thing. Why, of course -- coding a site to just one browser would be foolish (though there exist sites that follow that strategy, it's still despicable). What I'm talking about is sites that are _supposed_ to be able to support a dozen browsers, in three or four versions each, not to mention a dozen features each of which the user might have chosen to disable (for a total of 2**12 == 4096 possibilities). Of course, the site's poor authors cannot possibly have tested the 4096 * 12 * 3.5 possibilities, whence the _supposed_ to be. We ARE talking about moving from supporting 95% to supporting (*supposedly*!) 100%, after all -- very much into the long, *LONG* tail of obscure buggy versions of this browser or that, which SOME users within those last centiles may have forgotten to patch/upgrade, etc. And THAT is what makes the effort totally out of proportion (differently from the effort to go from 60% to 95%, which, while far from negligible, is well within sensible engineering parameters). Maybe that's part of the explanation for the outstanding success of some enterprises founded by engineers, led by engineers, and staffed overwhelmingly with engineers, competing with other firms where marketing wield power...? You mean like google? Until recently, they're an outstanding example of doing things right, and providing functionality that degrades gracefully as the clients capabilities go down. I'm not sure what you mean by until recently in this context. AFAIK, we've NEVER wasted our efforts by pouring them into the quixotic task of supporting *100%* of possible browsers that may hit us, with the near infinite number of combinations of browsers, versions and disabled feature that this would require. One may quibble whether the target percentage should be, say, 93%, 95%, or 97%, and what level of degradation can still be considered graceful around various axes, but the 100% goal which you so clearly imply above would, in my personal opinion, be simply foolish now, just as it would have been 3 years ago. In mine, too. It's often useful to remember the so-called 80/20 rule which, in software terms, I often state as you can get 80% of the functionality for 20% of the cost. Among other things I theorise that this accounts for the vast numbers of abandoned open source projects lurking on the Internet (but let's not follow that red herring any further). Of course, if the final 20% of a project's functionality accounts for 80% of the cost then the stark arithmetical truth would be that each functionality percentage point costs sixteen times what the first eighty points did. In practice the situation is never linear, and the truth is that there is a situation of diminishing returns which rarely justifies supporting those final additional hold-outs with obsolete platforms. This is as much an economic decision as a marketing one, but a good engineer knows instinctively that there is a desirable cut-off point beyond which adding further functionality is a waste of engineering effort. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Claudio Grondi wrote: Steve Holden [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] Claudio Grondi wrote: [...] Do I miss here something? While you are correct in saying (I paraphrase) that HTML interfaces nowadays can offer a rich graphical interface, it can be quite difficult to manage state maintenance between the two components (web server, web client) in the system. The cause of confusion here is, that HTML interfaces don't necessary need a web server and HTTP to work. I mean, that Internet Browsers have an API which allow access to them directly, so they can be used without a server as a kind of GUI library supporting widgets programmed in HTML and JavaScript (I haven't used them yet in this form, but I think it should be no problem - right or not?). You are perfectly correct that interfaces can be programmed in the browser. As has already been said, with the adoption of standards like CSS2, it's even possible to make such stuff run across multiple browser platforms (at the moment, though, just try writing an interface that makes table rows appear and disappear in a cross-browser fashion: you'll find the stylesheet techniques you need to use for Mozilla and IE are very different). But this doesn't help you at all if you are trying to interface to Python logic. A proper GUI runs all functionality inside a single process, and allows much easier control over complex interactions, creation of dynamic dialogues, and so on. Complex and dynamic is in my eyes possible with HTML and JavaScript, so I still don't see where is a problem with this approach. I have programmed already a HTML and JavaScript driven server platform and know about (the solvable) problems with the back-button and sessions (it is sure not the easiest way of programming a GUI). The only disadvantage of not using plugins or Java is, that real time interactions are not possible, but this is in my eyes usually not the requirement for a standard kind of GUI with no gaming, no Virtual Reality and no timing of user response down to milliseconds (but consider, that with a good speed of connection it is even possible to play blitz chess over the Internet). So, back to the subject: with an HTML/Javascript interface, how do you propose to bolt Python logic into the same process? Or do you admit that the application that interacts with such an interface either has to be all JavaScript or in a separate process? I haven't used it in such configuration yet, but I mean, that it is not a bad idea to use local DHTML files (i.e. HTML with JavaScript) combined with a Python driven HTTP server like e.g. Karrigell which makes it possible to access local files by executing Python scripts triggerred by demand raised by submitting to it DHTML form data resulting from user input. So mixing JavaScript in local DHTML files for performing what can be done with JavaScript inside HTML and a HTTP server capable of executing Python scripts will do the job which JavaScript alone can't because of lack of access to the local file system and another parts of the computer system on which such kind of UI is executed. Indeed. But this again partitions the problem into client functionality and server functionality residing in two separate processes, albeit on the same computer, with the previously-mentioned state maintenance problems. This issue isn't new, you know. Another possible scenario I have in mind is to control the Internet browser directly from a Python script using DHTML as a language for definition of appearance and specification of necessary data processing of in the browser displayed UI. This way the Internet browser and HTML with JavaScript can be considered an UI toolkit for use in Python. Hope with this above to have got Python back on topic. That is, I suppose, a possibility, but you certainly can't claim it would be platform-independent. Unless you know of some common control interface respected by both Internet Exploder and Firefox ;-) regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Another possible scenario I have in mind is to control the Internet browser directly from a Python script using DHTML as a language for definition of appearance and specification of necessary data processing of in the browser displayed UI. This way the Internet browser and HTML with JavaScript can be considered an UI toolkit for use in Python. Hope with this above to have got Python back on topic. That is, I suppose, a possibility, but you certainly can't claim it would be platform-independent. I haven't seen any really platform-independent software yet and I don't expect to see any in the future. It is simply not possible to have one, even if much progress was done lately in many areas in order to try to approach it as close as possible. Claudio Steve Holden [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] Claudio Grondi wrote: Steve Holden [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] Claudio Grondi wrote: [...] Do I miss here something? While you are correct in saying (I paraphrase) that HTML interfaces nowadays can offer a rich graphical interface, it can be quite difficult to manage state maintenance between the two components (web server, web client) in the system. The cause of confusion here is, that HTML interfaces don't necessary need a web server and HTTP to work. I mean, that Internet Browsers have an API which allow access to them directly, so they can be used without a server as a kind of GUI library supporting widgets programmed in HTML and JavaScript (I haven't used them yet in this form, but I think it should be no problem - right or not?). You are perfectly correct that interfaces can be programmed in the browser. As has already been said, with the adoption of standards like CSS2, it's even possible to make such stuff run across multiple browser platforms (at the moment, though, just try writing an interface that makes table rows appear and disappear in a cross-browser fashion: you'll find the stylesheet techniques you need to use for Mozilla and IE are very different). But this doesn't help you at all if you are trying to interface to Python logic. A proper GUI runs all functionality inside a single process, and allows much easier control over complex interactions, creation of dynamic dialogues, and so on. Complex and dynamic is in my eyes possible with HTML and JavaScript, so I still don't see where is a problem with this approach. I have programmed already a HTML and JavaScript driven server platform and know about (the solvable) problems with the back-button and sessions (it is sure not the easiest way of programming a GUI). The only disadvantage of not using plugins or Java is, that real time interactions are not possible, but this is in my eyes usually not the requirement for a standard kind of GUI with no gaming, no Virtual Reality and no timing of user response down to milliseconds (but consider, that with a good speed of connection it is even possible to play blitz chess over the Internet). So, back to the subject: with an HTML/Javascript interface, how do you propose to bolt Python logic into the same process? Or do you admit that the application that interacts with such an interface either has to be all JavaScript or in a separate process? I haven't used it in such configuration yet, but I mean, that it is not a bad idea to use local DHTML files (i.e. HTML with JavaScript) combined with a Python driven HTTP server like e.g. Karrigell which makes it possible to access local files by executing Python scripts triggerred by demand raised by submitting to it DHTML form data resulting from user input. So mixing JavaScript in local DHTML files for performing what can be done with JavaScript inside HTML and a HTTP server capable of executing Python scripts will do the job which JavaScript alone can't because of lack of access to the local file system and another parts of the computer system on which such kind of UI is executed. Indeed. But this again partitions the problem into client functionality and server functionality residing in two separate processes, albeit on the same computer, with the previously-mentioned state maintenance problems. This issue isn't new, you know. Another possible scenario I have in mind is to control the Internet browser directly from a Python script using DHTML as a language for definition of appearance and specification of necessary data processing of in the browser displayed UI. This way the Internet browser and HTML with JavaScript can be considered an UI toolkit for use in Python. Hope with this above to have got Python back on topic. That is, I suppose, a possibility, but you certainly can't claim it would be platform-independent. Unless you know of some common control interface respected by both Internet Exploder and Firefox ;-) regards Steve
Re: UI toolkits for Python
Claudio Grondi [EMAIL PROTECTED] wrote: I haven't seen any really platform-independent software yet and I don't expect to see any in the future. It is simply not possible to have one, even if much progress was done lately in many areas in order to try to approach it as close as possible. Java + Swing is probably as good as it gets when the goal is to write platform independent software. -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Mark Roseman wrote: What I'm suggesting is taking the effort you'd put to the 5%, and applying that effort instead to making the 95% even better. If that extra effort would affect conversion rates, it's a justifiable option. Yes, but isn't this where the 90/10 rule kicks in? In other words, you transfer the effort from the 5% of users you don't care about, but then just end up adding polish to the majority solution which doesn't significantly improve conversion rates, all because you've done the most effective work to convert those users already. In this case it's even more perilous: adding polish could quite easily eliminate parts of your audience, resulting in an only slightly more plush red carpet being offered to significantly fewer people. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Steve Holden wrote: [80/20 rule] This is as much an economic decision as a marketing one, but a good engineer knows instinctively that there is a desirable cut-off point beyond which adding further functionality is a waste of engineering effort. But Mike Meyer's point was that the Web standards are designed to allow fancy functionality where it's available but for the experience to degrade gracefully where such functionality isn't available. For example, you have all the events module attributes in XHTML, but take away the events capability in the browser and there's a decent chance for the semantics of the application to remain the same: no, you don't get instant updates of the page when you select some menu item, but the user can still have a similar experience which involves slightly more inconvenience - they have to submit the page and get back an updated version from the server. It's misleading to claim that designing in such a way requires huge additional development, especially since the standards are constructed in such a way to facilitate such designs. It goes without saying that implementing advanced functionality on Netscape 3.x and NCSA Mosaic would be a costly and ultimately non-viable burden, but that isn't the issue for many Web applications and wasn't the point being made. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
[EMAIL PROTECTED] (Alex Martelli) writes: Mike Meyer [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Alex Martelli) writes: Mike Meyer [EMAIL PROTECTED] wrote: What surprises me is that marketing types will accept turning away - what's the current internet user base? 200 million? - 10 million potential customers without a complaint. Or maybe they just don't get told that that's what's going on. In firms where marketing has lots of power, they may indeed well decide to pursue those 10 millions by demanding an expenditure of effort that's totally out of proportion What makes you think that the expenditure of effort is totally out of proportion? In my experience, that isn't the case - at least if you go into it planning on doing things that way. Retrofitting a site that was built without any thought but make it work in my favoriter browser in my favorite configuration can be a radically different thing. We ARE talking about moving from supporting 95% to supporting (*supposedly*!) 100%, after all -- very much into the long, *LONG* tail of obscure buggy versions of this browser or that, which SOME users within those last centiles may have forgotten to patch/upgrade, etc. I'm talking about supporting standards instead of clients, which is how you get interoperability. You clearly can't support all the buggy browsers that exist, especially not when even commercial browsers are releasing betas to the public. Reality is that you *have* to support the most popular browser(s) - except for the betas, anyway. Other browsers that have bugs - well, you can patch around them if it's trivial enough, and identify where the browser is out of spec otherwise in hopes the author will fix it. Unless you're out of spec, in which case you fix your code. Maybe that's part of the explanation for the outstanding success of some enterprises founded by engineers, led by engineers, and staffed overwhelmingly with engineers, competing with other firms where marketing wield power...? You mean like google? Until recently, they're an outstanding example of doing things right, and providing functionality that degrades gracefully as the clients capabilities go down. I'm not sure what you mean by until recently in this context. AFAIK, we've NEVER wasted our efforts by pouring them into the quixotic task of supporting *100%* of possible browsers that may hit us, with the near infinite number of combinations of browsers, versions and disabled feature that this would require. Google's sites have been very good about working with many browsers and configurations, especially when compared with the run of the mill on the web. If that's unintentional - well, that's simply a shame. One may quibble whether the target percentage should be, say, 93%, 95%, or 97%, and what level of degradation can still be considered graceful around various axes, but the 100% goal which you so clearly imply above would, in my personal opinion, be simply foolish now, just as it would have been 3 years ago. I never meant to imply that you should try and support 100% of all browsers, merely that they should try and support every browser that follows the specifications (and IE). I can see how what I said might be construed to mean the latter, and I'm sorry about that. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
I'd have to agree with this. Unfortunately, the only way to use Swing (in a reasonable manner) from Python is to use Jython, and Jython has other shortcomings that make me not want to use it. Sigh. Ken On 19-Oct-05, at 9:59 AM, Ed Jensen wrote: Claudio Grondi [EMAIL PROTECTED] wrote: I haven't seen any really platform-independent software yet and I don't expect to see any in the future. It is simply not possible to have one, even if much progress was done lately in many areas in order to try to approach it as close as possible. Java + Swing is probably as good as it gets when the goal is to write platform independent software. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
[Ken] Web interfaces are missing a lot more than this. Here are just a few things that cannot be done with web-based interfaces (correct me where I'm wrong): 1) A real word processor. http://www.writely.com/ http://www.goffice.com/ 2) Keybindings in a web application http://rememberthemilk.com/ Google Keys (but what happened to it? It's disappeared!) 3) Drag and drop http://www.walterzorn.com/dragdrop/dragdrop_e.htm http://qooxdoo.oss.schlund.de/demo/release/public/test/user/Index.html (pick Drag and Drop N from the dropdown on the right hand side of the top bar) 4) Resizable windows (i.e. not the browser window) within the application. http://qooxdoo.oss.schlund.de/demo/release/public/test/user/Index.html (pick Window N from the dropdown on the right hand side of the top bar) http://www.bindows.net/ (click Click for a quick DEMO) 5) Anything other than absolutely trivial graphical programs. Not sure what you mean by this... Google maps? web interfaces are still basically forms that can contain buttons, checkboxes, text fields, and a few other basic controls. I wish it were otherwise. It *is* otherwise. You should follow the Ajaxian weblog here: http://www.ajaxian.com/ -- Richie Hindle [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Paul Rubin http://[EMAIL PROTECTED] wrote: Torsten Bronger [EMAIL PROTECTED] writes: Because everybody is capable of running a JS engine, even on computers on which you don't have rights to install something. I don't think using JS so heavily without a compelling reason is really in the WWW spirit. Lots of browsers don't have JS. And lots of JS is so annoying that some users like to turn it off even in browsers that have it. I don't have the exact numbers, and I'm pretty certain they'd be confidential if I did, but I believe the factors you mention (browsers completely lacking JS, and users turning JS off), *combined*, still allow JS-rich interfaces to run for well over 95% of visitors to our sites. Maybe that's the key difference between the mindset of a mathematician and that of an engineer -- I consider reaching over 95% of visitors to be _quite good indeed_, while you appear to disagree because of WWW spirit issues. Is making a rapidly responsive site (not requiring roundtrips for every interaction) a compelling reason? It seems to me that it is -- and why else would one use ANY Javascript, after all? My one issue with the JS/AJAX mania is that I really dislike JS as a language, particularly when you take the mixed mongrel dialect that you do need to reach all the various browsers and releases needed to make that 95% goal. But, alas, there is really no alternative!-( Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
[EMAIL PROTECTED] (Alex Martelli) writes: Maybe that's the key difference between the mindset of a mathematician and that of an engineer -- I consider reaching over 95% of visitors to be _quite good indeed_, Oh? So you'd consider an SMTP/IMAP/POP/DNS/NFS/etc server that rejected 5% of the systems connecting to be _quite good indeed_? I think I'm glad that the internet wasn't built by people who agreed with that. If you know what you're doing, you can have the best of both worlds for a lot of web applications. Yes, it won't be as rich or functional for the five percent who worry about security (or whatever), but it'll still work. And yes, you can't do it for every application. For those, anyone vaguely competent will add a warning. What surprises me is that marketing types will accept turning away - what's the current internet user base? 200 million? - 10 million potential customers without a complaint. Or maybe they just don't get told that that's what's going on. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Mike Meyer [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Alex Martelli) writes: Maybe that's the key difference between the mindset of a mathematician and that of an engineer -- I consider reaching over 95% of visitors to be _quite good indeed_, What surprises me is that marketing types will accept turning away - what's the current internet user base? 200 million? - 10 million potential customers without a complaint. Or maybe they just don't get told that that's what's going on. Obviously we all agree the effort to support both is significant. The question is not so much do we turn away 5% as do we use the effort we do have to provide a better experience for the 95%, or to provide a slightly worse experience for the 95%, and an ok experience for the 5%. If you're a business, the question then becomes, does the incrementally better experience produce a higher conversion rate (i.e. more sales), in which case it may well be a better investment to focus there and ignore the 5%. It's but one perspective, but depending on your goals, can be a reasonable choice to make. Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Mike Meyer a écrit : [EMAIL PROTECTED] (Alex Martelli) writes: Maybe that's the key difference between the mindset of a mathematician and that of an engineer -- I consider reaching over 95% of visitors to be _quite good indeed_, Oh? So you'd consider an SMTP/IMAP/POP/DNS/NFS/etc server that rejected 5% of the systems connecting to be _quite good indeed_? I think I'm glad that the internet wasn't built by people who agreed with that. If you know what you're doing, you can have the best of both worlds for a lot of web applications. Yes, it won't be as rich or functional for the five percent who worry about security (or whatever), but it'll still work. And yes, you can't do it for every application. For those, anyone vaguely competent will add a warning. What surprises me is that marketing types will accept turning away - what's the current internet user base? 200 million? - 10 million potential customers without a complaint. Or maybe they just don't get told that that's what's going on. mike Last time I checked, it was only 60% of the users with Javascript enabled. Not sure about the current ratio but with the various locked down IE installs it doesn't surprise me too much. -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Mike Meyer a écrit : [EMAIL PROTECTED] (Alex Martelli) writes: Maybe that's the key difference between the mindset of a mathematician and that of an engineer -- I consider reaching over 95% of visitors to be _quite good indeed_, Oh? So you'd consider an SMTP/IMAP/POP/DNS/NFS/etc server that rejected 5% of the systems connecting to be _quite good indeed_? I think I'm glad that the internet wasn't built by people who agreed with that. If you know what you're doing, you can have the best of both worlds for a lot of web applications. Yes, it won't be as rich or functional for the five percent who worry about security (or whatever), but it'll still work. And yes, you can't do it for every application. For those, anyone vaguely competent will add a warning. What surprises me is that marketing types will accept turning away - what's the current internet user base? 200 million? - 10 million potential customers without a complaint. Or maybe they just don't get told that that's what's going on. mike Last time I checked, it was only 60% of the users with Javascript enabled. Not sure about the current ratio but with the various locked down IE installs it doesn't surprise me too much. -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Paul Rubin wrote: All this extreme use of JS misses the point, it's client side programming all over again This is so true, although I don't expect those people relentlessly hyping AJAX to either realise the significance of that observation or to necessarily make an accessible Web site for those people who, for whatever reason, can't use the mountains of JavaScript that perform the fancy fades and colour flashes that seem de rigeur in their Web 2.0 applications. Here's an interesting perspective from outside the AJAX clique: http://aseigo.blogspot.com/2005/10/web-office-suites-rofl.html (It even has a Monty Python reference, too.) Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Mike Meyer [EMAIL PROTECTED] wrote: ... What surprises me is that marketing types will accept turning away - what's the current internet user base? 200 million? - 10 million potential customers without a complaint. Or maybe they just don't get told that that's what's going on. In firms where marketing has lots of power, they may indeed well decide to pursue those 10 millions by demanding an expenditure of effort that's totally out of proportion (to the detriment of the other 190 millions, of course, since there IS a finite amount of development resources to allocate). Maybe that's part of the explanation for the outstanding success of some enterprises founded by engineers, led by engineers, and staffed overwhelmingly with engineers, competing with other firms where marketing wield power...? Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Mark Roseman [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Alex Martelli) writes: Maybe that's the key difference between the mindset of a mathematician and that of an engineer -- I consider reaching over 95% of visitors to be _quite good indeed_, What surprises me is that marketing types will accept turning away - what's the current internet user base? 200 million? - 10 million potential customers without a complaint. Or maybe they just don't get told that that's what's going on. Obviously we all agree the effort to support both is significant. The question is not so much do we turn away 5% as do we use the effort we do have to provide a better experience for the 95%, or to provide a slightly worse experience for the 95%, and an ok experience for the 5%. You elided the paragraph where I pointed out the third alternative: provide a better experience for the 95%, and an ok experience for the 5%. WWW technologies are designed to degrade gracefully - it's easy to take advantage of that. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
[EMAIL PROTECTED] (Alex Martelli) writes: Mike Meyer [EMAIL PROTECTED] wrote: What surprises me is that marketing types will accept turning away - what's the current internet user base? 200 million? - 10 million potential customers without a complaint. Or maybe they just don't get told that that's what's going on. In firms where marketing has lots of power, they may indeed well decide to pursue those 10 millions by demanding an expenditure of effort that's totally out of proportion What makes you think that the expenditure of effort is totally out of proportion? In my experience, that isn't the case - at least if you go into it planning on doing things that way. Retrofitting a site that was built without any thought but make it work in my favoriter browser in my favorite configuration can be a radically different thing. Maybe that's part of the explanation for the outstanding success of some enterprises founded by engineers, led by engineers, and staffed overwhelmingly with engineers, competing with other firms where marketing wield power...? You mean like google? Until recently, they're an outstanding example of doing things right, and providing functionality that degrades gracefully as the clients capabilities go down. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
You elided the paragraph where I pointed out the third alternative: provide a better experience for the 95%, and an ok experience for the 5%. WWW technologies are designed to degrade gracefully - it's easy to take advantage of that. What I'm suggesting is taking the effort you'd put to the 5%, and applying that effort instead to making the 95% even better. If that extra effort would affect conversion rates, it's a justifiable option. -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Steve Holden [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] Claudio Grondi wrote: Steve Holden [EMAIL PROTECTED] schrieb im Newsbeitrag [...] [Claudio] I don't fully understand your attitude here. The Web Browser interface has all I can imagine is required for a GUI, so what is missing when you consider, that you can generate custom images on the fly on the server and let the user shape the page without requesting CPU power from the server using JavaScript. In this case then, I'm afraid the failure is in your imagination :-) Any useful hints towards enlightenment except criticism? Perhpas the mistake I made was bearing in mind the title of the thread, and the fact that this is a Python newsgroup. I don't even name here the not really beeing itegral part of Internet Browsers JavaApplets and any other kind of plugin stuff. The only issue I can see with this approach is the speed of responding to user interactions, but for really optimize this one needs a compiled language anyway. What is that complex, that it can't be solved using an Internet Browser as a GUI? Do I miss here something? While you are correct in saying (I paraphrase) that HTML interfaces nowadays can offer a rich graphical interface, it can be quite difficult to manage state maintenance between the two components (web server, web client) in the system. The cause of confusion here is, that HTML interfaces don't necessary need a web server and HTTP to work. I mean, that Internet Browsers have an API which allow access to them directly, so they can be used without a server as a kind of GUI library supporting widgets programmed in HTML and JavaScript (I haven't used them yet in this form, but I think it should be no problem - right or not?). You are perfectly correct that interfaces can be programmed in the browser. As has already been said, with the adoption of standards like CSS2, it's even possible to make such stuff run across multiple browser platforms (at the moment, though, just try writing an interface that makes table rows appear and disappear in a cross-browser fashion: you'll find the stylesheet techniques you need to use for Mozilla and IE are very different). But this doesn't help you at all if you are trying to interface to Python logic. A proper GUI runs all functionality inside a single process, and allows much easier control over complex interactions, creation of dynamic dialogues, and so on. Complex and dynamic is in my eyes possible with HTML and JavaScript, so I still don't see where is a problem with this approach. I have programmed already a HTML and JavaScript driven server platform and know about (the solvable) problems with the back-button and sessions (it is sure not the easiest way of programming a GUI). The only disadvantage of not using plugins or Java is, that real time interactions are not possible, but this is in my eyes usually not the requirement for a standard kind of GUI with no gaming, no Virtual Reality and no timing of user response down to milliseconds (but consider, that with a good speed of connection it is even possible to play blitz chess over the Internet). So, back to the subject: with an HTML/Javascript interface, how do you propose to bolt Python logic into the same process? Or do you admit that the application that interacts with such an interface either has to be all JavaScript or in a separate process? I haven't used it in such configuration yet, but I mean, that it is not a bad idea to use local DHTML files (i.e. HTML with JavaScript) combined with a Python driven HTTP server like e.g. Karrigell which makes it possible to access local files by executing Python scripts triggerred by demand raised by submitting to it DHTML form data resulting from user input. So mixing JavaScript in local DHTML files for performing what can be done with JavaScript inside HTML and a HTTP server capable of executing Python scripts will do the job which JavaScript alone can't because of lack of access to the local file system and another parts of the computer system on which such kind of UI is executed. Another possible scenario I have in mind is to control the Internet browser directly from a Python script using DHTML as a language for definition of appearance and specification of necessary data processing of in the browser displayed UI. This way the Internet browser and HTML with JavaScript can be considered an UI toolkit for use in Python. Hope with this above to have got Python back on topic. Claudio -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Claudio Grondi wrote: Steve Holden [EMAIL PROTECTED] schrieb im Newsbeitrag [...] [Claudio] I don't fully understand your attitude here. The Web Browser interface has all I can imagine is required for a GUI, so what is missing when you consider, that you can generate custom images on the fly on the server and let the user shape the page without requesting CPU power from the server using JavaScript. In this case then, I'm afraid the failure is in your imagination :-) Any useful hints towards enlightenment except criticism? Perhpas the mistake I made was bearing in mind the title of the thread, and the fact that this is a Python newsgroup. I don't even name here the not really beeing itegral part of Internet Browsers JavaApplets and any other kind of plugin stuff. The only issue I can see with this approach is the speed of responding to user interactions, but for really optimize this one needs a compiled language anyway. What is that complex, that it can't be solved using an Internet Browser as a GUI? Do I miss here something? While you are correct in saying (I paraphrase) that HTML interfaces nowadays can offer a rich graphical interface, it can be quite difficult to manage state maintenance between the two components (web server, web client) in the system. The cause of confusion here is, that HTML interfaces don't necessary need a web server and HTTP to work. I mean, that Internet Browsers have an API which allow access to them directly, so they can be used without a server as a kind of GUI library supporting widgets programmed in HTML and JavaScript (I haven't used them yet in this form, but I think it should be no problem - right or not?). You are perfectly correct that interfaces can be programmed in the browser. As has already been said, with the adoption of standards like CSS2, it's even possible to make such stuff run across multiple browser platforms (at the moment, though, just try writing an interface that makes table rows appear and disappear in a cross-browser fashion: you'll find the stylesheet techniques you need to use for Mozilla and IE are very different). But this doesn't help you at all if you are trying to interface to Python logic. A proper GUI runs all functionality inside a single process, and allows much easier control over complex interactions, creation of dynamic dialogues, and so on. Complex and dynamic is in my eyes possible with HTML and JavaScript, so I still don't see where is a problem with this approach. I have programmed already a HTML and JavaScript driven server platform and know about (the solvable) problems with the back-button and sessions (it is sure not the easiest way of programming a GUI). The only disadvantage of not using plugins or Java is, that real time interactions are not possible, but this is in my eyes usually not the requirement for a standard kind of GUI with no gaming, no Virtual Reality and no timing of user response down to milliseconds (but consider, that with a good speed of connection it is even possible to play blitz chess over the Internet). So, back to the subject: with an HTML/Javascript interface, how do you propose to bolt Python logic into the same process? Or do you admit that the application that interacts with such an interface either has to be all JavaScript or in a separate process? regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
With OS X compatibility you tend to come across with the fact that many OS X compatible things are actually X11 things. X11 certainly looks different from Aqua (the native interface). But imho, Gnome _does_ look and feel quite Mac-ish in the sense that its ergonomics has certain things in common with the Mac, even more with the old MacOS classic than with the pretty gadget-ish Aqua interface. For example, with its hierarchical multi-column listview, Nautilus looks and feels perfectly like the old MacOS classic Finder, something that lots of long-time Mac users miss a lot on MacOS X. Another example is MDI (or windows inside windows), which is a no-no on the Mac (and afaik not supported by GTK), or multi-pains (sic!). As a long-time Mac user (since system 6.0.x), I did like a lot the GUI of WingIDE (which uses GTK) because it allows me to switch from a multi-pain layout to a multi-window layout. GTK is an example of this. There is an Aqua version of GTK, but it seems to be rather outdated. There's a new effort for a aqua-native implementation: http://micke.hallendal.net/archives/2005/10/gtk-macosx.html The newer versions run on X11 but installing them may be just laborious or then plain pain depending on your luck. And you still need the X11 installed. One advantage of an X11 application is, obviously, the possibility to use it from a different computer without the requirement to install it there. Hey, my Mac can do that for free, while your Windows needs an expensive Server license.! ;- Shhh, don't tell them about Cygwin... So, if you are looking for something that looks like Mac and works like Mac, do not touch anything with X11. As a long-time Mac user, I somewhat disagree, see above. :-) To me, a GTK application with a really well-thought ergonomic user interface is a lot more Mac-ish than a pile of aqua-native visual gadgetry. Sincerely, Wolfgang Keller -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Web interfaces are missing a lot more than this. Here are just a few things that cannot be done with web-based interfaces (correct me where I'm wrong):1) A real word processor.2) Keybindings in a web application3) Drag and drop4) Resizable windows (i.e. not the browser window) within the application.5) Anything other than absolutely trivial graphical programs.State is a very small part of the whole thing. Progress is being made, but web interfaces are still basically forms that can contain buttons, checkboxes, text fields, and a few other basic controls. I wish it were otherwise.KenOn 16-Oct-05, at 5:04 PM, Mike Meyer wrote:Malte Clasen [EMAIL PROTECTED] writes: Claudio Grondi wrote: What is that complex, that it can't be solved using an Internet Browser as a GUI? Nothing, but session management isn't trivial with http interfaces. You have to deal with the back button of the browsers, bookmarks to pages that result from posted forms, users leaving the application without notice, etc.. This fact seems to have escaped the notice of most developers of web applications. They just fail and/or misbehave under all those conditions. -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
On Monday 17 October 2005 12:19, Kenneth McDonald wrote: 1) A real word processor. Difficult. Not necessarily impossible. Would require much cleverness. And it wouldn't be capable of everything Word can do. 2) Keybindings in a web application Not sure here, but JavaScript may be able to do something to accomplish some of this. A web-delivered XUL app can definitely do this. But that's pushing the limits of what can be considered a web application. 3) Drag and drop JavaScript can definitely do this. AFAIK Zimbra (http://www.zimbra.com) does this. DD w/ the desktop environment may not be supported though. 4) Resizable windows (i.e. not the browser window) within the application. Possible, but difficult. I believe that some great cleverness with JavaScript and absolutely-positioned DIV's can probably come pretty stinking close, and Flash can definitely do this (but that doesn't really count). Not tested. 5) Anything other than absolutely trivial graphical programs. Correct there. - Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
On Oct 17, 2005, at 12:19 PM, Kenneth McDonald wrote: Web interfaces are missing a lot more than this. Here are just a few things that cannot be done with web-based interfaces (correct me where I'm wrong): 1) A real word processor. 2) Keybindings in a web application 3) Drag and drop 4) Resizable windows (i.e. not the browser window) within the application. 5) Anything other than absolutely trivial graphical programs. State is a very small part of the whole thing. Progress is being made, but web interfaces are still basically forms that can contain buttons, checkboxes, text fields, and a few other basic controls. I wish it were otherwise. Drag-and-drop within a page can be done. Drag-and-drop between pages is the only thing on that list I think is outright impossible. Everything else is a matter of overcoming difficulty (well, 5 might be close enough to qualify as impossible, if you're thinking Photoshop.) Thing is, as Web applications continue to increase in complexity, they're going to resemble desktop apps more and more, not just on the front end but in back as well. So the advantage of Web apps being simpler to program will probably go away. Right now, they're only simpler because people are doing simpler things with them (and browsers only let you do so much.) The extra complexity you get with desktop app toolkits is overkill for many purposes. HTML is often good enough in a lot less time. But if we get to the point where browsers are implementing inter-page drag-and-drop (probably differently!) and so forth, some of us might well decide it's simpler to go back to wxPython, etc. Then again, maybe we'll live to see the W3C standardize the desktop environment... g -Jason -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Michael Ekstrand [EMAIL PROTECTED] writes: 2) Keybindings in a web application Not sure here, but JavaScript may be able to do something to accomplish some of this. A web-delivered XUL app can definitely do this. But that's pushing the limits of what can be considered a web application. All this extreme use of JS misses the point, it's client side programming all over again, not really what most of us think of as a web interface which puts all the hair on the server side. If you want to program on the client, why not use a reasonable language like Python instead of a monstrosity like JS? -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Hallöchen! Paul Rubin http://[EMAIL PROTECTED] writes: Michael Ekstrand [EMAIL PROTECTED] writes: 2) Keybindings in a web application Not sure here, but JavaScript may be able to do something to accomplish some of this. A web-delivered XUL app can definitely do this. But that's pushing the limits of what can be considered a web application. All this extreme use of JS misses the point, it's client side programming all over again, not really what most of us think of as a web interface which puts all the hair on the server side. If you want to program on the client, why not use a reasonable language like Python instead of a monstrosity like JS? Because everybody is capable of running a JS engine, even on computers on which you don't have rights to install something. (Not that I like those JS ideas though ...) Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Torsten Bronger [EMAIL PROTECTED] writes: Because everybody is capable of running a JS engine, even on computers on which you don't have rights to install something. I don't think using JS so heavily without a compelling reason is really in the WWW spirit. Lots of browsers don't have JS. And lots of JS is so annoying that some users like to turn it off even in browsers that have it. -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Claudio Grondi wrote: Kenneth McDonald [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED] Thanks for reminding me of Gtk. OK, add that to the list. The Web Browser interface is good for simple things, and will get better with CSS2's adoption, but they still don't have a good way for important things like interactive styled text, key bindings, etc. Good for simple things (for which I use them), not for more complex stuff. I don't fully understand your attitude here. The Web Browser interface has all I can imagine is required for a GUI, so what is missing when you consider, that you can generate custom images on the fly on the server and let the user shape the page without requesting CPU power from the server using JavaScript. In this case then, I'm afraid the failure is in your imagination :-) I don't even name here the not really beeing itegral part of Internet Browsers JavaApplets and any other kind of plugin stuff. The only issue I can see with this approach is the speed of responding to user interactions, but for really optimize this one needs a compiled language anyway. What is that complex, that it can't be solved using an Internet Browser as a GUI? Do I miss here something? While you are correct in saying (I paraphrase) that HTML interfaces nowadays can offer a rich graphical interface, it can be quite difficult to manage state maintenance between the two components (web server, web client) in the system. A proper GUI runs all functionality inside a single process, and allows much easier control over complex interactions, creation of dynamic dialogues, and so on. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Malte Clasen [EMAIL PROTECTED] writes: Claudio Grondi wrote: What is that complex, that it can't be solved using an Internet Browser as a GUI? Nothing, but session management isn't trivial with http interfaces. You have to deal with the back button of the browsers, bookmarks to pages that result from posted forms, users leaving the application without notice, etc.. This fact seems to have escaped the notice of most developers of web applications. They just fail and/or misbehave under all those conditions. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Steve Holden [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] Claudio Grondi wrote: Kenneth McDonald [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED] Thanks for reminding me of Gtk. OK, add that to the list. The Web Browser interface is good for simple things, and will get better with CSS2's adoption, but they still don't have a good way for important things like interactive styled text, key bindings, etc. Good for simple things (for which I use them), not for more complex stuff. I don't fully understand your attitude here. The Web Browser interface has all I can imagine is required for a GUI, so what is missing when you consider, that you can generate custom images on the fly on the server and let the user shape the page without requesting CPU power from the server using JavaScript. In this case then, I'm afraid the failure is in your imagination :-) Any useful hints towards enlightenment except criticism? I don't even name here the not really beeing itegral part of Internet Browsers JavaApplets and any other kind of plugin stuff. The only issue I can see with this approach is the speed of responding to user interactions, but for really optimize this one needs a compiled language anyway. What is that complex, that it can't be solved using an Internet Browser as a GUI? Do I miss here something? While you are correct in saying (I paraphrase) that HTML interfaces nowadays can offer a rich graphical interface, it can be quite difficult to manage state maintenance between the two components (web server, web client) in the system. The cause of confusion here is, that HTML interfaces don't necessary need a web server and HTTP to work. I mean, that Internet Browsers have an API which allow access to them directly, so they can be used without a server as a kind of GUI library supporting widgets programmed in HTML and JavaScript (I haven't used them yet in this form, but I think it should be no problem - right or not?). A proper GUI runs all functionality inside a single process, and allows much easier control over complex interactions, creation of dynamic dialogues, and so on. Complex and dynamic is in my eyes possible with HTML and JavaScript, so I still don't see where is a problem with this approach. I have programmed already a HTML and JavaScript driven server platform and know about (the solvable) problems with the back-button and sessions (it is sure not the easiest way of programming a GUI). The only disadvantage of not using plugins or Java is, that real time interactions are not possible, but this is in my eyes usually not the requirement for a standard kind of GUI with no gaming, no Virtual Reality and no timing of user response down to milliseconds (but consider, that with a good speed of connection it is even possible to play blitz chess over the Internet). Claudio regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Grant Edwards wrote: snip Aside from the look feel issue with Tk, the other objection sometimes heard is that Tk is integrated into Python by including Tcl as well (as opposed to doing an actual Tk binding the way some other languages have done). It's an eminently practical approach, but it sure makes you feel dirty. Dirty or not, it allows Python to utilitze any new features of Tk much faster than an actual Tk binding would. That is Perl/Tk's problem...it is slow to adopt new Tk features. Robert -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Claudio Grondi wrote: What is that complex, that it can't be solved using an Internet Browser as a GUI? Nothing, but session management isn't trivial with http interfaces. You have to deal with the back button of the browsers, bookmarks to pages that result from posted forms, users leaving the application without notice, etc.. And if you want to implement dialogs like the Photoshop image resizing with automatic calculation of some widget data based on other widgets (e.g. interlocked width and height), you have to rely on JavaScript which isn't as platform independent as it should be and sometimes deactivated due to security issues. But if that doesn't bother you, you might want to have a look at http://qooxdoo.sourceforge.net/ , an advanced open-source javascript based toolkit. Malte -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Kenneth McDonald schrieb: Is there any emerging consensus on the best UI for toolkit. Tk never quite made it but from what I can see, both qt and wxWin are both doing fairly well in general. I'm already aware of the licensing issues surrounding qt (fwiw, I think their license fee for commercial use is eminently reasonable), so aside from that, I was wondering if there was any feedback readers could provide on the following: [snip] As for my experience with Python-integrated GUI toolkits: I tried wxWidgets/Boa and had it crashing on me all over the place. I switched to GTK/glade2 and fought with it for a couple of days until I ran away screaming. Next, I tried Qt/Designer and the more I learned, the more I knew I'd keep loving it. Its Python bindings are not perfect, especially QStrings will annoy you. You will notice that it was originally designed for C++ and had to try hard to reimplement a lot of the batteries that Python has included, so it often uses its own concepts where Python concepts would feel a bit nicer. But once you accept that, you will really like its clean design that helps you with your work. A friend of mine switched to Mac-OS X recently and I told him to use Qt for one of his projects. He is a Debian developer and did all of his previous GUIs with GTK. It took him only a couple of hours to fall in love with it. He was especially mad about the fact that it looks completely like a Mac application on Mac-OS and like a Windows application on Windows. It even felt like a native app. Just try it, you'll see. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Kenneth McDonald wrote: Is there any emerging consensus on the best UI for toolkit. Tk never quite made it but from what I can see, both qt and wxWin are both doing fairly well in general. I'm already aware of the licensing issues surrounding qt (fwiw, I think their license fee for commercial use is eminently reasonable), so aside from that, I was wondering if there was any feedback readers could provide on the following Oh, one more thing with respect to web apps: There was the nufox announcement recently, which seems to support XUL driven interfaces in Python. http://trac.nunatak.com.au/projects/nufox Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
In article [EMAIL PROTECTED], Kenneth McDonald wrote: 4) Ease of installation/use on OS X? There are two questions which may restrict your choice rather a lot: #1 Should the UI look the same on each platform or should it look the same as all other apps on the platform? #2 Are you trying to make a simple installation package which includes everything needed? With OS X compatibility you tend to come across with the fact that many OS X compatible things are actually X11 things. X11 certainly looks different from Aqua (the native interface). Also, X11 is not always installed, and some unixish things require using Fink to install them. Not something Joe A. User usually has on his Mac. GTK is an example of this. There is an Aqua version of GTK, but it seems to be rather outdated. The newer versions run on X11 but installing them may be just laborious or then plain pain depending on your luck. And you still need the X11 installed. So, if you are looking for something that looks like Mac and works like Mac, do not touch anything with X11. OTOH, if you just need to get something working on your own OS X computer, then X11 is fine. --- I have tried using wxPython for Mac/Windows cross-platform GUIs. This far it seems to work fine, but I have not tried anything very fancy. Mac applications have the OS X looks, and Windows applications look Windowsish. Without having a single line of platform-dependent code. Making simple installation files (exe for Windows and dmg for OS X) seems to work, as well. So, the installation should be easy for the user. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
I find wxPython to pro fill my GUI needs from python in a pretty good way. To show off it's capabilities - I am building a GUI editor and it currently converts from windows forms (visual studio c# forms) to wxPython code. When I started programming this editor I thought I'd have major incompatibility problems, thinking wxPython is extremely weaker than the windows forms. However, coding the conversion between the two proved wxPython to be highly capable. BTW, this GUI editor can be found here: http://farpy.holev.com I believe this also provides an answer to gsteff's post about not having a normal GUI editor. -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
sure it is, but since this is a Python list, you'd also need PyQt to go along with it, and there's no version of PyQt yet compatible with Qt4. -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
I realy like developing PyQt applications using the Eric3 IDE. I find Qt really has a lot of high level functionality already available for you, I like the flexibility of the slot-signal system, I like that the Qt C++ maps very well into object-oriented Python though PyQt. You can just use the Qt C++ documentation. Just check out Eric3 itself as an example of what you can do in PyQt. It's not yet ported to Qt4 AFAIK, but I suppose it will not take long. In Qt4 the licencing is no issue for me as I'm only writing GPL code anyway. I don't know how it performs on OSX, I think it works fine, as Qt is available on OSX. I don't know what you want in a text widget, but the kTextEdit I use comes with functions like checkSpelling(), undo(), copy(), paste(), setFont(). Hooking these up to for example a fontRequestor is no more work as adding both to the form in QtDesigner (integrated in Eric3), and connecting the appropriate signal and slot. It could be some of these are only available if you have KDE installed. I realy like the Canvas allowing sprites, zooming, rotating, etc. I've never done much with TkInter, so I can't compare. I think it's easier as wxwindows, it's easier as VCL/CLX and MFC. (I'm comming from the Windows/Borland C++/Delphi world) The standard Python shell only has buildin support for the TkInter event loop AFAIK, I just heard ipython is more cross GUI toolkit in this regard. I don't think there's any consensus. I think any of a Tk, Wxwindows, GTK or Qt based solution might work for you, depending on what you are used to. Tk seems to be most traditional Python, but I think it's ugly, and I realy like the high level functionality that Qt provides. Adriaan Renting. Kenneth McDonald [EMAIL PROTECTED] 10/13/05 10:17 pm Is there any emerging consensus on the best UI for toolkit. Tk never quite made it but from what I can see, both qt and wxWin are both doing fairly well in general. I'm already aware of the licensing issues surrounding qt (fwiw, I think their license fee for commercial use is eminently reasonable), so aside from that, I was wondering if there was any feedback readers could provide on the following: 1) Which plays best with Python? Ideally, it would already have some higher-level python libraries to hide the grotty stuff that is almost never needed when actually implementing apps. 2) Reliability of each? 3) Useful external libraries for each? 4) Ease of installation/use on OS X? Something with a genuinely useful text widget would be nice, but I know that's too much to expect...ah, TkText widget, where are you when I need you. Thanks, Ken -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Something to consider when writing cross-platform applications with any gui toolkit is that it never works out of the box. Despite what they might promise you. If you have yourself access to a Windows, Linux and Mac OS X computer, you probably won't have any problem to make it fully cross-platform. If you work on Windows, but don't have a Mac, than you will have a hard time, if not almost impossible when you write complex applications. I've tried all python gui toolkits and my conclusion was for small applications that are distributed as python source use Tkinter, otherwise wxPython. Arguments are: - very supportive community (wxPython mailing lists, just ask a question and everybody helps you out in no time) - native, professional look feel - best licensing for all platforms (commercial use allowed) - very rich widget set, continuously extended by the community (see eg. widgets from Andrea Gavana http://xoomer.virgilio.it/infinity77/eng/freeware.html) - wxGlade makes GUI design really easy (http://wxglade.sourceforge.net/) Stani http://pythonide.stani.be (SPE - Stani's Python Editor) -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Adriaan Renting wrote: [which GUI toolkit?] Kenneth McDonald [EMAIL PROTECTED] 10/13/05 10:17 pm Is there any emerging consensus on the best UI for toolkit. Tk never quite made it but from what I can see, both qt and wxWin are both doing fairly well in general. I'm already aware of the licensing issues surrounding qt (fwiw, I think their license fee for commercial use is eminently reasonable), so aside from that, I was wondering if there was any feedback readers could provide on the following: 1) Which plays best with Python? Ideally, it would already have some higher-level python libraries to hide the grotty stuff that is almost never needed when actually implementing apps. 2) Reliability of each? 3) Useful external libraries for each? 4) Ease of installation/use on OS X? Something with a genuinely useful text widget would be nice, but I know that's too much to expect...ah, TkText widget, where are you when I need you. Hmm. The only real answer is to make a choice and stick with it until you have enough experience to determine whether it was a good decision or not - all platforms have advantages and disadvantages. For the record, having tried several toolkits and GUI builders I have recently decided to settle (for the moment) on wxPython and wxDesigner (the latter is a modestly-priced commercial product that represents very good value for money). While wxDesigner doesn't do everything you might want it seems to be better than anything else I've come across for building resizable dialogues and panels, which are readily used as components in other more complex windowed application structures. Just my 2c, though. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Adriaan Renting [EMAIL PROTECTED] writes: [On Qt] I don't know how it performs on OSX, I think it works fine, as Qt is available on OSX. Qt on OS X is halfway there. It looks - and acts - like an aqua application. However, to support the Command key, they hacked things so that it is reported to the upper layers as the Control key. This means that there's no way to get to use the control key in the UI for qt apps on OS X. This really rapes apps with configurable shortcuts. For instance, LyX comes with a couple of emacsish bindings. You can turn them on, but you have to use Command-key instead of Control-key, which pretty thoroughly defeats the purpose. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Mike Meyer [EMAIL PROTECTED] 10/14/05 5:39 pm $Adriaan Renting [EMAIL PROTECTED] writes: $[On Qt] $I don't know how it performs on OSX, I think it works fine, as Qt is $available on OSX. $ $Qt on OS X is halfway there. It looks - and acts - like an aqua $application. However, to support the Command key, they hacked things $so that it is reported to the upper layers as the Control key. This $means that there's no way to get to use the control key in the UI for $qt apps on OS X. $ $This really rapes apps with configurable shortcuts. For instance, LyX $comes with a couple of emacsish bindings. You can turn them on, but $you have to use Command-key instead of Control-key, which pretty $thoroughly defeats the purpose. $ $ mike I think to some extent it's a general problem with cross-platform toolkits, altough I agree that I think the way Trolltech solved it for OS X might be sub-optimal, depending on how the command key is supposed to work. You have the problem that some keyboard layouts have OS specific keys (Windows key, menu key on some PCs, Command key on apples) which you can't support in a cross-platform way. If using Command-Letter is the standard way of having keyboard shortcuts in OS X, then I think I can understand why they choose this implementation,. I suppose the Command key is more integrated into the OS as is the Windows key in Windows. I think it would be nice if you could choose the mapping. The basic problem is that a widget toolkit that supports control/shift/alt/command as meta-keys can not be cross-platform, as the command key has no equivalent in windows or linux. How do the other widget toolkits handle this, do they ignore the Command key? What does Linux PPC/YellowDog do with the Command key? Adriaan Renting. -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Mike Meyer [EMAIL PROTECTED] 10/14/05 5:39 pm #Adriaan Renting [EMAIL PROTECTED] writes: #[On Qt] #... #[mike on qt for Mac Os X] #... I've looked some more into this, and it seems that the confusion is because Qt on Mac maps: Command/Apple key - Qt::Key_Control Ctrl Key - Qt::Key_Meta Alt/Option Key- Qt::Key_Alt because the use of the Command/Apple key is similar to how in Windows and KDE the Ctrl key is used. This results in Command-S being Save, Command-A being Select All, which seems to be the way it's supposed on Apple, but it creates confusion if cross-platform documentation would say Ctrl-A is Select All, because this isn't true on Apple. Maybe the Apple GUI guidelines can answer how it should be. How do other widget sets handle this? do they use: Command/Apple key - Key_Meta Ctrl Key - Key_Control Alt/Option Key- Key_Alt Adriaan Renting. -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Adriaan Renting [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] 10/14/05 5:39 pm $Adriaan Renting [EMAIL PROTECTED] writes: $[On Qt] $I don't know how it performs on OSX, I think it works fine, as Qt is $available on OSX. $ $Qt on OS X is halfway there. It looks - and acts - like an aqua $application. However, to support the Command key, they hacked things $so that it is reported to the upper layers as the Control key. This $means that there's no way to get to use the control key in the UI for $qt apps on OS X. $ $This really rapes apps with configurable shortcuts. For instance, LyX $comes with a couple of emacsish bindings. You can turn them on, but $you have to use Command-key instead of Control-key, which pretty $thoroughly defeats the purpose. $ $ mike You have the problem that some keyboard layouts have OS specific keys (Windows key, menu key on some PCs, Command key on apples) which you can't support in a cross-platform way. If using Command-Letter is the standard way of having keyboard shortcuts in OS X, then I think I can understand why they choose this implementation,. I suppose the Command key is more integrated into the OS as is the Windows key in Windows. I think it would be nice if you could choose the mapping. It's quick and dirty and does the right thing for applications that follow the UI guidelines on Windows and OS X. Generally, Command-lumberjack on OS X does the same thing as Control-lumberjack does on Windows or other CUA platform. If you want to let users bind keystrokes, then they're out of luck. The basic problem is that a widget toolkit that supports control/shift/alt/command as meta-keys can not be cross-platform, as the command key has no equivalent in windows or linux. How do the other widget toolkits handle this, do they ignore the Command key? What does Linux PPC/YellowDog do with the Command key? I really can't say, but it seems like the obvious way to do it is to have the lower levels define the appropriate bucky bits for all platforms. No platform will generate all those bits, but so what? That just means youv'e got some symbols defined that won't be used on some platforms. Actually, since there undoubtedly exists systems that can't generate all the bucky bits for any given platform, that's some more symbols But I'm not a GUI designer, so there may be reasons for not doing it that way that I can't see. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Kenneth McDonald [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED] Thanks for reminding me of Gtk. OK, add that to the list. The Web Browser interface is good for simple things, and will get better with CSS2's adoption, but they still don't have a good way for important things like interactive styled text, key bindings, etc. Good for simple things (for which I use them), not for more complex stuff. I don't fully understand your attitude here. The Web Browser interface has all I can imagine is required for a GUI, so what is missing when you consider, that you can generate custom images on the fly on the server and let the user shape the page without requesting CPU power from the server using JavaScript. I don't even name here the not really beeing itegral part of Internet Browsers JavaApplets and any other kind of plugin stuff. The only issue I can see with this approach is the speed of responding to user interactions, but for really optimize this one needs a compiled language anyway. What is that complex, that it can't be solved using an Internet Browser as a GUI? Do I miss here something? Claudio -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Kenneth McDonald [EMAIL PROTECTED] writes: 1) Which plays best with Python? Ideally, it would already have some higher-level python libraries to hide the grotty stuff that is almost never needed when actually implementing apps. 2) Reliability of each? 3) Useful external libraries for each? 4) Ease of installation/use on OS X? The answer to each of those questions points to Tkinter. It comes with Python by default (the least installation hassles of any toolkit), is pretty reliable, has a reasonably Pythonic interface, and I don't understand the question about external libraries. However, Tkinter not most people's favorite, because the widgets look crude, they don't resemble the native widgets of any popular platform, and the widget set is somewhat limited. That suggests you're not asking the right questions. I use Tkinter because the Python gui's I've built so far have been for straightforward functionality purposes without being fancy. However, if I were doing something for wide distribution and wanted it to look sharp, at this point I think I'd go for PyGtk despite the preference of many for wxpython. Finally, don't overlook the possibility of embedding a basic web server in your app, and having the user communicate with it through a web browser. That turns HTML into your gui, which is very easy to program. It also lets you easily handle remote clients, multiple concurrent clients, etc, and gives users a familiar and intuitive interface. -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Thanks for reminding me of Gtk. OK, add that to the list. The Web Browser interface is good for simple things, and will get better with CSS2's adoption, but they still don't have a good way for important things like interactive styled text, key bindings, etc. Good for simple things (for which I use them), not for more complex stuff. As for Tkinter, well, sigh, I have to go into a semi-rant, semi- eulogy right now. Tk was, IMHO, the hands-down award winner for UI toolkit farthest ahead of its time. I used it for years and years and years. Tcl, on the other had, wasn't the _worst_ scripting language of all time, but it was sure down in the bottom ten percent. How John Ousterhout could come up with Tk on one hand and the other at the same Tcl boggles my mind. Unfortunately, while Tkinter did provide in theory full access to Tk, it was in practice never finished. I wrote quite a bit of code to try to add a true pythonic interface to Tk via Tkinter (I'm happy to give it away if anyone wants--some of it is actually in pretty good shape). But it's a big job, and it became clear to me that Tk is going the way of the dinosaurs, so I abandoned it. Ddevelopment on the advanced features of Tk--what really made it worth using--has languished. Both marks and tags in the Text widget have been fundamentally broken forever (not buggy, I mean broken in the sense that their semantics destroys a great deal of their real potential), and I don't see they'll ever be fixed. Same thing with tags in the Canvas widget. Plus the lack of well-thought-out new widgets, and various other sins of omission and comission, and I decided that Tkinter was clearly in the last of its days. That said, if I was one of the founders of Google, Tk would be one of the projects I'd hire a lot of people to get on to and actually realize its potential. But I don't even buy lottery tickets :-) Now I'm just waiting until one of the other kits becomes mature enough (if ever) to start using it. So this is a query about that :-) On 13-Oct-05, at 3:21 PM, Paul Rubin wrote: Kenneth McDonald [EMAIL PROTECTED] writes: 1) Which plays best with Python? Ideally, it would already have some higher-level python libraries to hide the grotty stuff that is almost never needed when actually implementing apps. 2) Reliability of each? 3) Useful external libraries for each? 4) Ease of installation/use on OS X? The answer to each of those questions points to Tkinter. It comes with Python by default (the least installation hassles of any toolkit), is pretty reliable, has a reasonably Pythonic interface, and I don't understand the question about external libraries. However, Tkinter not most people's favorite, because the widgets look crude, they don't resemble the native widgets of any popular platform, and the widget set is somewhat limited. That suggests you're not asking the right questions. I use Tkinter because the Python gui's I've built so far have been for straightforward functionality purposes without being fancy. However, if I were doing something for wide distribution and wanted it to look sharp, at this point I think I'd go for PyGtk despite the preference of many for wxpython. Finally, don't overlook the possibility of embedding a basic web server in your app, and having the user communicate with it through a web browser. That turns HTML into your gui, which is very easy to program. It also lets you easily handle remote clients, multiple concurrent clients, etc, and gives users a familiar and intuitive interface. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
On Thursday 13 October 2005 15:17, Kenneth McDonald wrote: 1) Which plays best with Python? Ideally, it would already have some higher-level python libraries to hide the grotty stuff that is almost never needed when actually implementing apps. wxPython plays reasonably well. I've just started playing with PyGTK+glade, and am highly impressed with that. 4) Ease of installation/use on OS X? Ease of installation and use, wxPython is good. General OS X goodness, wxPython has been exhibiting highly weird behavior. Plus some useful widgets don't work well (if at all) on Mac. wxWidgets also feels very old-Windows-ish. For example, it's built around having 1 toolbar for a window; for my application, that's not going to work so well, and I'm also having issues with some things related to dynamically creating toolbars and changing the toolbar. - Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Paul Rubin http://[EMAIL PROTECTED] wrote: However, Tkinter not most people's favorite, because the widgets look crude, they don't resemble the native widgets of any popular platform, and the widget set is somewhat limited. People should probably be more aware of work that has been going on with Tk recently (after a fairly long hiatus) in terms of greatly improving its appearance, adding theming, and more. It's worth checking out, and of course, if there's a way to help get some of these changes into Tkinter, the Tk folks would I'm sure be helpful. Here's a portion of a note that Jeff Hobbs posted to the Ruby group recently, on a similar topic: From: Jeff Hobbs [EMAIL PROTECTED] Subject: Re: The definitive GUI for Ruby Date: Wed, 05 Oct 2005 11:02:46 -0700 Newsgroups: comp.lang.ruby Message-ID: [EMAIL PROTECTED] Eustaquio Rangel de Oliveira J wrote: Tk is still too ugly for make programmers that are migrating. :-) Tk is only ugly if that's the way you like it. You have a full set of themed widgets available now that give you native look and feel, with all the same dynamic control and general ease of use that Tk has always provided. All this on Aqua, Win32 and X11 (even Windows/CE). Some screenshots of Tk apps that try not to be ugly: The Perl Dev Kit and Tcl Dev Kit UIs: http://aspn.activestate.com/ASPN/docs/PDK/6.0/PerlApp_gui.html#perlapp_gui_configuring_perlapp_build_parameters http://aspn.activestate.com/ASPN/docs/Tcl_Dev_Kit/3.2/TclVFSE.html Tk on Win/CE (I know that the Perl/Tcl::Tk use this too): http://wiki.tcl.tk/8442 Coccinella: http://hem.fyristorg.com/matben/ http://hem.fyristorg.com/matben/examples/index.html An installer builder: http://installbase.sourceforge.net/screenshots.shtml An example of improving a Tk app by going native: http://wiki.tcl.tk/14522 -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
On 2005-10-13, Paul Rubin wrote: The answer to each of those questions points to Tkinter. It comes with Python by default (the least installation hassles of any toolkit), is pretty reliable, has a reasonably Pythonic interface, and I don't understand the question about external libraries. However, Tkinter not most people's favorite, because the widgets look crude, they don't resemble the native widgets of any popular platform, and the widget set is somewhat limited. Aside from the look feel issue with Tk, the other objection sometimes heard is that Tk is integrated into Python by including Tcl as well (as opposed to doing an actual Tk binding the way some other languages have done). It's an eminently practical approach, but it sure makes you feel dirty. -- Grant Edwards grante Yow! Hey!! Let's watch at the' ELEVATOR go UP and visi.comDOWN at th' HILTON HOTEL!! -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
This improved appearance has been a nice thing to see, but looks were never really the reason I decided to leave Tkinter. It's much more the fundamental issues of Tk, plus the fact that Tkinter was never really "completed" (not a comment on the original author--there's only so much one person can do) that has made me decide to leave Tk behind.As an example of the worst Tk issues (at least for what I was doing):1) Marks screw up when they come to occupy the position. For example, let's say { symbolizes a text mark with right gravity, and } a text mark with left gravity. Remember that marks all have names, so they can all be referred to uniquely. Now construct some text like this: {here} is {some} marked {text}. Delete all the text. The marks still exist. Now, try to recreate the original text by inserting the appropriate words at the appropriate marks. It won't work for two reasons, the worst of which is that marks that come to occupy the same index in the text can actually change their relative order.2) There are no abstract references; everything is referred to by its string name. This causes serious problems with name clashes and code abstraction. Tkinter hides some of this, but not enough.3) Window nesting is completely determined by window naming, which only compounds the problem mentioned in (2).I don't really mean to diss Tk, I just get so frustrated when I think of what it could have been...Thanks,KenOn 13-Oct-05, at 4:02 PM, Mark Roseman wrote:People should probably be more aware of work that has been going on with Tk recently (after a fairly long hiatus) in terms of greatly improving its appearance, adding theming, and more. It's worth checking out, and of course, if there's a way to help get some of these changes into Tkinter, the Tk folks would I'm sure be helpful. Here's a portion of a note that Jeff Hobbs posted to the Ruby group recently, on a similar topic: --
http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Kenneth McDonald [EMAIL PROTECTED] writes: [...] both doing fairly well in general. I'm already aware of the licensing issues surrounding qt (fwiw, I think their license fee for commercial use is eminently reasonable), so aside from that, I was wondering if [...] Qt 4 is available as GPL even on Windows. John -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
I've used wxpython and pygtk, and have a strong preference for pygtk. wxpython has some advantages: it has better OSX support (widgets look native, and it doesn't require the installation of the Fink x server), and better win32 support (a few gtk widgets, such as menus, don't look quite native on gtk, and multithreading with pygtk on win32 is problematic). But pygtk has better documentation, a MUCH cleaner api, integration with the Glade GUI designer (wxpython has wxglade, but its not in the same league), and a richer widget set. In addition, top itself is in the top tier of free software projects; wxwidgets is not as mature, and its development is not as active. So, if you're trying to choose between those two, go with wxpython if you need OSX support, or have specific issues with pygtk's win32 support. In all other cases, I'd reccomend pygtk. Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Er, meant to say In addition GTK itself is in the top tier of free software projects -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
However, Tkinter not most people's favorite, because the widgets look crude, they don't resemble the native widgets of any popular platform, and the widget set is somewhat limited. (given that the web interface is the new black, that's not much of an argument. tkinter with the right stylesheet can look anyway you want) Mark Roseman wrote: People should probably be more aware of work that has been going on with Tk recently (after a fairly long hiatus) in terms of greatly improving its appearance, adding theming, and more. It's worth checking out, and of course, if there's a way to help get some of these changes into Tkinter, the Tk folks would I'm sure be helpful. maybe this should be reposted to tkinter-discuss ? fwiw, I still use Tkinter for all UI:s I build, but these days, 80-90% of the visible widgets are based on this module: http://effbot.org/zone/wck.htm sometimes combined with: http://effbot.org/zone/draw-agg.htm /F -- http://mail.python.org/mailman/listinfo/python-list
